iPhone SDK: économiser de grandes quantités de texte

Question

Je veux économiser de grandes quantités de texte puis les afficher (d'abord en vue de la table, puis en mode texte), mais je ne suis pas sûr de la méthode à le faire dans. Dois-je utiliser SQLite, ou l'une des méthodes d'archivage.

Answer 1

Votre déclaration de « grandes quantités de texte » est ambigu. Vous pourriez dire une des opérations suivantes:

• Un grand ensemble (par exemple 10.000 articles) de petits éléments de texte (par exemple 30 mots)
• Un petit ensemble (par exemple 50 éléments) du grand texte (par exemple 3000 mots) éléments
• Un grand nombre de grands éléments de texte ...

Je vais essayer de répondre à chacun de ces scénarios.

Si vous stockez un grand nombre d'enregistrements, je trouve une base de données est toujours une bonne idée. Cela signifie en utilisant soit SQLite ou CoreData. CoreData est un peu plus de travail pour y aller, mais il y a beaucoup d'exemples autour et cette approche sera rentable à long terme.

La raison principale une base de données est nécessaire pour les grands ensembles de données est que vous alors ne pas besoin de le charger à la fois. Vous ne voulez pas que vos utilisateurs assis pendant 30 secondes pendant que vos charges d'applications jusqu'à tous ses records (même en supposant qu'il sera tous être en mesure de charger en mémoire - ça va vite!). CoreData en particulier est conçu pour fonctionner avec cette « charge seulement les données, l'utilisateur a besoin de voir » modèle.

Toutefois, si vous avez un petit ensemble de données, même si chaque élément est relativement important, vous avez peu de chances de gagner beaucoup en les mettant dans une base de données. Si vous pensez que la quantité de données pourrait se développer dans l'avenir, il vaut la peine de le faire. Mais si elle est susceptible de ne jamais vous pousser peut probablement avec l'archivage - et peut-être même le plus facile de tous les mécanismes, coller directement un tableau ou dans un dictionnaire plist. Ceci est le moyen le plus rapide à mettre en œuvre, mais comme décrit ci-dessus est certainement une mauvaise idée dans un certain nombre de situations.

L'espoir qui aide!

Answer 2

Je dirais que si votre texte / données est juste quelques kilo octets, puis aller pour les méthodes d'archivage, sinon SQLite est là pour vous. Bonne chance.