Meilleure façon de conserver un fichier XML sur iPhone?

Question

J'utilise MonoTouch et aussi System.Data pour créer un DataSet (juste du xml pour ceux qui ne me sont pas familiers) pour une simple liaison de données. Les données sur mon application sont minimes, donc pas besoin de tout sortir avec SQLLite. L'utilisation de l'ensemble de données facilite le transfert via les services Web pour la synchronisation avec le cloud.

Je sérialiser le DataSet dans le dossier personnel lors de la sauvegarde et bien sûr lire ce fichier lorsque l'application démarre pour charger les données de l'utilisateur. J'ai eu des problèmes où ce fichier devient corrompu et je ne sais pas pourquoi. Je suppose que les E/S de fichiers peuvent être lentes sur ces appareils et cela pourrait en être la cause, je ne suis pas sûr, mais cela arrive.

Je suis également inquiet que peut-être iTunes passe ce fichier entre le PC/MAC lorsque l'utilisateur synchronise leurs appareils avec iTunes, ce qui peut être la cause de la corruption?

Je souhaite empêcher la synchronisation de ce fichier de périphérique avec iTunes et le conserver de manière fiable. J'utilise l'option NSFile.Save pour l'enregistrer sur l'appareil. Je pense que puisqu'il s'agit d'un fichier texte, peut-être que je pourrais le stocker en toute sécurité dans la zone des paramètres utilisateur standard à la place? Cela l'empêcherait d'être synchronisé par itunes, je présume?

Quelle est la manière la plus fiable et la plus sûre de gérer ce fichier d'e/s pour le stockage du jeu de données xml?

Merci.

Answer 1

Vous utilisez MonoTouch. N'est-il pas simplement question d'appeler DataSet.WriteXml() avec un objet FileStream prêt à écrire dans un document de votre dossier Documents?

Ce dossier Documents est sauvegardé sur iTunes. Ce n'est pas synchronisé, mais cela aide si votre utilisateur restaure son téléphone (parce qu'il l'a briqué, perdu, peu importe). Cela n'explique pas pourquoi c'est corrompu. La seule chose que je peux penser à pourquoi il est corrompu est parce que cela a pris trop de temps pour que votre application l'écrive. Il y a un temps limité entre le moment où l'utilisateur quitte l'application et sa fermeture, afin d'empêcher les applications de garder le système en otage et de détériorer l'expérience utilisateur.

Si l'écriture de l'ensemble de données prend trop de temps, vous voulez penser à minimiser cela. Peut-être que vous pouvez simplement stocker les données, et non le schéma. Ou vous pouvez trouver un moyen de stocker uniquement les deltas à la sortie et de les réconcilier lorsque l'utilisateur a de nouveau chargé votre application.

Vous pouvez également empêcher la perte complète de données en écrivant dans un second fichier, et lorsque cette opération est terminée, supprimez l'ancien fichier et renommez-le. Ainsi, la prochaine fois que vous démarrerez si l'opération d'écriture ne s'est pas terminée, l'ancien fichier sera toujours présent et l'utilisateur n'aura perdu que ses modifications les plus récentes.

Dans tous les cas, si vos données deviennent trop volumineuses pour une simple opération d'écriture, vous devez examiner différentes options telles que sqlite.

Answer 2

Beaucoup de cadres sont en lecture seule, mais j'ai trouvé que GDataXMLNode de http://code.google.com/p/gdata-objectivec-client/ fonctionne très bien en lecture/écriture. Cela dit, sur l'iPhone vous feriez vous-même une grande faveur en utilisant Core Data avec un backend SQLLite. :-) Apple a fait tout cela pour vous et optimisé plus qu'aucun d'entre nous tous sera

Vive

Nik

Answer 3

Pensez à utiliser SQLite, je vais quelque chose comme

• http://www.taimila.com/entify/ (pas encore essayé)
• catnap ORM
• ou Faks sqlite-net sur google code (en utilisant cela dans quelques applications

Entify - s'il fait ce qu'il dit qu'il peut faire - semble vraiment bon.

persister XML sur l'iPhone comme un moyen de stocker et d'accéder aux données est une nause que vous ne voulez pas entrer dans. J'ai écrit à ce sujet ici http://iwayneo.blogspot.com/2010/08/festival-star-history-serialization-as.html

Answer 4

Votre meilleur pari est probablement de simplement enregistrer le XML comme texte. C'est aussi simple que File.WriteAllText (...) - il n'y a aucune raison d'aller à NSFile pour cela. Cela fait partie de l'avantage de MonoTouch de

En ce qui concerne la synchronisation, voici la règle:

• Si vous gardez le fichier dans le dossier de l'utilisateur des documents (les Environment.SpecialFolder.MyDocuments et Environment.SpecialFolder.Personal DEUX points dans le dossier doc de l'utilisateur), il sera sauvegardé chaque fois que l'utilisateur se synchronisera avec iTunes.

Il n'y a rien de mal à cela. Il conserve les données entre les sessions et les rend récupérables en cas de problème avec le téléphone de l'utilisateur et qu'il doit restaurer à partir d'une sauvegarde. Depuis votre question est sur persistant un fichier XML sur le téléphone, c'est ce que vous voulez. En ce qui concerne la question iTunes, la vitesse et la synchronisation ne posent aucun problème, car votre application ne fonctionnera pas pendant la synchronisation du téléphone. Le fichier aura été enregistré ou non. Toute corruption qui se produit est en cours pendant que votre application est en cours d'exécution.

Raisons pour les fichiers corrompus se peut inclure:

• sauver Pas avant que l'utilisateur se ferme. Vous avez une chance de le faire.

• Traitement d'un appel téléphonique entrant sans succès. Le système vous en avertit également.

iTunes ne corrompt certainement pas votre fichier. Si c'était le cas, les applications iOS seraient toutes cassées. Cela pourrait arriver sur votre machine de développement pour une raison quelconque, mais je n'ai jamais vu cela se produire ailleurs, et j'ai fait pas mal de développement sur iOS.

Si vous souhaitez un tutoriel sur la lecture et l'écriture de fichiers, j'ai posté an answer in another question. C'est long, mais le but était de répondre à autant de questions que possible afin que personne ne reste suspendu ou confus.

Une bonne chose à propos des appareils iOS est que vous êtes de retour (pour la plupart des applications) dans le monde d'une personne à la fois. Vous écrivez des applications où vous n'avez pas à vous soucier de 5000 personnes qui essaient d'utiliser votre application web en même temps (ce n'est pas toujours vrai, mais ... vous comprenez bien).En conséquence, vous pouvez faire des choses que vous pourriez normalement considérer comme mauvaises pour la performance, mais vous ne verrez pas de problèmes de performance (tant que le fichier que vous enregistrez est suffisamment petit pour être sauvegardé rapidement ou que vous économisez en arrière-plan sur un autre thread - vous ne voulez jamais bloquer le thread principal (UI) avec une lourde opération d'E/S).

Si vous avez d'autres questions, n'hésitez pas à demander. Je souhaite que cela aide :)