Quelle est la meilleure façon de stocker des données statiques dans une application iOS ?

Question

J'ai dans mon application une quantité considérable de données auxquelles elle doit accéder, mais qui ne seront jamais modifiées par l'application. Actuellement, j'utilise ces données dans d'autres applications, dans des fichiers JSON et des bases de données SQL, mais ni l'un ni l'autre ne semble très simple à utiliser dans iOS.

Je ne veux pas utiliser CoreData, qui fournit des tonnes de fonctionnalités et de complexité inutiles.

Serait-ce une bonne idée de stocker les données dans un fichier PropertyList et de créer une classe d'accès ? Existe-t-il des moyens simples d'incorporer SQLite sans passer par CoreData ?

Answer 1

Vous ne pouvez utiliser la plist que si la quantité de données est relativement faible. Les plistes sont entièrement chargées en mémoire, de sorte que vous ne pouvez vraiment les utiliser que si vous pouvez maintenir tous les objets créés par la pliste en mémoire en même temps, aussi longtemps que vous en avez besoin.

Core Data a une courbe d'apprentissage mais, à l'usage, il est généralement moins complexe que SQL. Dans la plupart des cas, le SQL "plus simple" conduit à plus de codage parce que vous finissez par devoir dupliquer une grande partie de la fonctionnalité de Core Data pour insérer le SQL procédural dans l'API orientée objet. Vous devez gérer manuellement l'utilisation de la mémoire de toutes les données en suivant la rétention. Vous devez écrire beaucoup de code SQL chaque fois que vous voulez des données. J'ai mis à jour plusieurs applications de SQL à Core Data et dans tous les cas, l'implémentation de Core Data était plus petite et plus propre que SQL.

La mémoire ou le processeur ne sont pas plus importants. Core Data est hautement optimisé. Dans la plupart des cas, Core Data prêt à l'emploi est plus efficace qu'un système SQL paramétré à la main. Une sous-optimisation mineure dans SQL détruit généralement tout avantage théorique qu'il pourrait avoir.

Bien sûr, si vous êtes déjà très compétent dans la gestion de SQL en C, vous pourrez peut-être commercialiser l'application plus rapidement en utilisant SQL. Cependant, si vous vous demandez ce que vous devriez prévoir d'utiliser en général sur les plateformes Apple, Core Data est presque toujours la réponse et vous devriez prendre le temps de l'apprendre.

Answer 2

Vous pouvez utiliser SQLite directement, sans l'inconvénient de Core Data, à l'aide de l'option SQLite C API .

Ici est un tutoriel que j'ai trouvé sur votre cas d'utilisation - simplement charger des données à partir d'une base de données SQLite. J'espère que cela vous aidera.

Answer 3

En fonction du type de vos données, de leur taille et de la fréquence à laquelle elles changent, vous pouvez souhaiter rester simple et utiliser une liste de propriétés. Sinon, j'utiliserais SQLite (documenté dans la réponse de Jergason). Cependant, permettez-moi de dire que si vous avez un ensemble relativement petit (moins de deux cents) de types de base (tableaux, dictionnaires, nombres, chaînes) qui ne changent pas fréquemment, alors une liste de propriétés sera un meilleur choix à mon avis.

Par exemple, dans l'un de mes jeux, je crée les niveaux à partir d'une seule liste de propriétés par difficulté. Comme il n'y a qu'une poignée de niveaux par difficulté (99) et un petit ensemble de paramètres pour chacun (nombre d'éléments en jeu, leurs positions initiales, leur masse, etc), c'est logique, et j'évite d'avoir à traiter directement avec SQLite ou, pire encore, à mettre en place et à maintenir CoreData.

Answer 4

Qu'entendez-vous par "meilleur" ? Quel type de données ?

S'il s'agit d'un tas d'objets, JSON ou plist (binaire) ne sont pas des formats terribles, puisque vous voudrez que l'ensemble soit chargé en mémoire pour parcourir le graphe d'objets. Comparez l'efficacité de l'espace et les performances de chargement pour choisir lequel utiliser.

S'il s'agit d'un tas de blobs binaires, il faut stocker les blobs dans un gros fichier, mettre le fichier en correspondance avec la mémoire (NSDataReadingMapped a.k.a. NSMappedRead), et utiliser des index dans les blobs. Les frameworks iOS utilisent un mélange de ces méthodes (par exemple, il y a beaucoup de .pngs, mais aussi "other.artwork" qui contient juste des données d'image brutes).

Vous pouvez également utiliser NSKeyedArchiver et ses amis si vos classes implémentent le protocole NSCoding, mais il y a une surcharge de gestion du graphe d'objets et le format plist qu'il produit n'est pas vraiment agréable à travailler.