sauvegarde des saisies avec un iphone
Bonjour à tous,
Je me pose une question sur le stockage de données que l'on peut être amené à saisir avec un Iphone, comment cela se passe
quand on fait une appli avec Swift, par exemple, on créé des enregistrements que l'on stocke sur le disque dur, quand est-il avec un Iphone, ou doit-on ranger les données saisies.
Est-ce que l'on crée des dossiers ?
En quelque sorte, peut-on utiliser un Iphone de la même manière qu'un MAC ?
Je ne sais pas si je suis dans le bon forum je parle de Swift et d'Iphone alors.
Bonne journée
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Bonjour,
Oui bien sûr et heureusement, il est possible d'enregistrer des fichiers avec une appli sur iPhone ou iPad.
Il est également possible de créer des dossiers.
Regarde "NSFileManager".
Chaque application posséde un espace mémoire sécurisé pour sauver ces données, ce qu'on appelle le "bac à sable". Contrairement au Mac où tous les dossiers sont accessibles, une application iOS ne peut accéder qu'à ses propres dossiers, sans pouvoir trifouiller dans les données de ces petits camarades. Comme le dis Eric, c'est l'objet NSFileManager qui s'occupe de gérer les dossiers et les fichiers d'une application.
Comme le disent mes camarades, on peut stocker les données dans des fichiers classiques. Si tu as peu de données, tu peux aussi considérer l'utilisation de NSUserDefaults.
Mais dès que le volume de données devient important, ou les relations entre les objets sont complexes, il faut considérer l'utilisation d'une base de données. Il existe alors plusieurs solutions: Core Data (évite), Realm ou l'accès direct à SQLite via GRDB.
Pourquoi faut-il éviter d'utiliser CoreData ?
X2
Apple conseille l'utilisation de NSUserDefaults pour le stockage des préférences utilisateurs de l'application. Mais si nous avons des datas qui ne sont pas forcément du paramétrage applicatif, il est déconseillé de l'utiliser ? Si oui pour qu'elle raison ? Question de performance ?
J'en ai déjà parlé, mais disons qu'il y a plein de galères qui t'attendent au tournant, qu'il est très difficile de régler à cause de l'aspect boite noire de Core Data. Et il y a d'autres aspects qui pourront te poser de gros problèmes à moyen terme: migrations, concurrence, lenteur.
Oui, pour des questions de performances. C'est assez basique, tout est enregistré sous forme de PList et chargé en mémoire.
Mais aussi parce que c'est prévu en principe pour enregistrer des préférences et ou réglages, pas autre chose. Il y a une zone grise ici: par exemple imagine que tu aies des dossiers que tu puisses nommer et leur donner des couleurs. Est-on dans les préférences ou dans le stockage de document ?
Pour finir, les migrations sont assez compliquées; il n'y a absolument rien de prévu.
Salut !
C'est d'un point de vue performance (rapidité, impact énergétique), par rapport à l'utilisation d'une base de données, c'est comment ?
Sachant que le fichier sera sans doute chargé entièrement en mémoire, ce sera sans doute le plus rapide et ce qui fera le moins d'allers-retours entre la RAM et la mémoire Flash. Donc meilleure rapidité et meilleur impact énergétique.
Cependant, ce n'est vrai que si le fichier est petit. S'il est gros, ça prendra du temps à charger en mémoire entièrement — alors que la BdD ne charge que ce qui est nécessaire.
Pour donner un ordre de grandeur, petit veut dire < 1 Mo; mais en pratique, il faudrait mesurer pour comparer.
Par ailleurs Il y a d'autres aspects à considérer: si l'appli plante ou est tuée, on perd toutes les dernières modifs.
Et les BdD permettent d'organiser les données et lancer des requêtes — ce n'est pas rien.