Lors de la rédaction d'une application pour MacOSX, à l'aide de Cocoa / Objective-C, j'aimerais pouvoir stocker les données saisies par les utilisateurs. Il n'y aura qu'un seul utilisateur par installation pour le moment; Cependant, j'aimerais avoir une idée de la modification des méthodes de stockage s'il s'agissait de plusieurs utilisateurs par installation.
Dans le cas d'un utilisateur par installation, devrais-je m'en tenir à SQLLITE pour un stockage persistant, ou quelle est la recommandation?
Si je pouvais autoriser plusieurs utilisateurs par installation, quelle méthode de stockage persistante serait préférée?
5 Réponses :
Quel type de données voulez-vous si sauvegarder? Bien sûr, vous pouvez toujours utiliser SQLite pour stocker des données pour plusieurs utilisateurs (par exemple, Firefox le fait).
Mais en fonction de vos données, vous pouvez le sauvegarder dans des fichiers / documents normaux? Jetez un coup d'œil au protocole NScoding abstrait nscoder classe. Ou consultez l'architecture de document ( nsdocumentController , nsdocument et nswindowcontroller ).
Vous pouvez utiliser des données de base et créer un magasin persistant par utilisateur (dans ~ / Bibliothèque / Données d'application / Mon application /)
Je développerais presque toujours une nouvelle application avec des données de base, à moins que je puisse trouver une assez bonne raison de ne pas le faire. Les données stockées dans le nuage me vient à l'esprit, mais même je pense que j'utiliserais probablement les données de base comme cache locale. En outre, les données de base sont rapides.
Si vous partagiez les données entre différents utilisateurs, cela pourrait compliquer les choses. Mais il y a toujours des données de base basées sur des documents ...
D'accord. Et comment je peux faire ça?
Il n'y aura qu'un seul utilisateur par installation pour le moment; Cependant, j'aimerais avoir une idée de la modification des méthodes de stockage s'il s'agissait de plusieurs utilisateurs par installation.
Le format n'est pas pertinent tant que vous ne sauvegardez que des données dans le répertoire de base de l'utilisateur par défaut.
Vos options incluent des listes de propriétés, des données de base (plus une décision architecturale, vous basez votre application sur les données de base ou ne l'utilisez pas), SQLite, NskeyDarchiver et votre propre format personnalisé.
Vous pouvez également envisager d'utiliser un NSDictionary comme mécanisme de stockage interne, puis écrivez-les aux fichiers de la liste de propriétés à l'aide de [NSDictionary WriteToFile: atomique:]. Un de mes amis aime faire référence à des dictionnaires en tant que structure de données de Dieu (langue dans la joue).
Si votre taille de données est modeste, il y a plusieurs avantages à cette taille: Lisible humain, écritable humain, modifiable.
L'utilisation de Nsdictionnaires comme objets de modèle entraîneront une douleur lorsque vous allez mettre en œuvre le support AppleScript. Mieux vaut que chaque objet soit capable de générer un dictionnaire représentant lui-même et de se transformer en soi d'un dictionnaire ainsi généré.
Je commencerais à stocker des données sur le nuage plutôt que de stocker localement. Maintenant que l'iPad sort, que si votre application est également utilisée sur l'iPhone et l'iPad. Si vous stockez les données sur le cloud, l'application iPhone et l'iPad peuvent utiliser les mêmes données. Si vous stockez localement, l'application iPhone et l'application iPad ne peut pas utiliser les mêmes données.
Les applications Mac OS X ne peuvent pas être exécutées sur l'iPhone / iPod Touch / iPad de toute façon. Application de cacao! = Application iPhone. ;)
MiPadi: Joo Park suggère ceci en considérant la possibilité que le questionneur puisse un jour de démarrage d'une version iPhone et / ou iPad de l'application. Je ne suggérerais pas de stocker des données entièrement dans le nuage, cependant; Les nuages ont un moyen d'évaporer. Utilisation de la version Mac en tant que concentrateur de synchronisation (au moins comme une alternative optionnelle au cloud) serait mieux.