noob - fichier configuration de l'application
mushu
Membre
Bonjour,
juste une question de noob :P en rapport avec l'organisation de projet Xcode:
Où met-on généralement les données de configuration d'une application (par exemple le nom d'une base de donnée SQLite pour mon cas) ?
juste une question de noob :P en rapport avec l'organisation de projet Xcode:
Où met-on généralement les données de configuration d'une application (par exemple le nom d'une base de donnée SQLite pour mon cas) ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Si tu veux juste des infos pour toi en tant que dev, tu peux mettre ça dans un plist par exemple.
Sinon si c'est modifiable par l'user (ce que je ne pense pas être la meilleure solution) tu peux faire un fichier de config qui va par la suite apparaitre dans les préférences de l'iPhone au nom de ton appli...
A toi de voir
Je vais me renseigner sur comment accéder/modifier les données de ce fichier.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/PropertyLists/QuickStartPlist/QuickStartPlist.html
http://stackoverflow.com/questions/5354623/how-do-i-load-a-plist-file-from-disk-as-a-nsdictionary-on-ios
Voilà
Si ce sont des constantes que tu veux :
- soit tu prévois un fichier .h de constantes, éventuellement inclus dans le header précompilé (pch) pour ne pas avoir à l'inclure partout... quoique je suis pas fan (je préfère ne mettre dans le pch que quelques macros utilitaires)
- Soit tu répartis les constantes par catégorie dans tes différents headers, comme le fait Apple, genre les constantes de mon WebService comme l'URL de base ou la version ou quoi je les met dans MonWebService.h, les autres autre part selon leur usage, etc
- Soit tu te fais un singleton si c'est plutôt assimilable à un "service" te fournissant des "données"
- Si ce sont vraiment des données de configuration modifiables à la volée, en effet le PLIST est une bonne solution. NSUserDefaults est aussi à creuser, et n'est pas forcément limité aux préférences modifiables par l'utilisateur (pas d'obligation d'exposer dans l'IHM toutes les valeurs des NSUserDefaults)
Dans les 3 premiers cas c'est que ce sont des éléments pris en compte à la compilation (quoi que pour le service ça dépend du backend utilisé, il peut aller piocher les valeurs autre part aussi...), dans le dernier cas c'est pris en compte à l'exécution (donc tu peux les changer sans avoir à recompiler)
Ce que j'aimerais en fait, c'est centraliser le nom du fichier de base de donnée pour que quand je telechargerai une "mise à jour" de ce fichier en interne, le nom du nouveau fichier soit facilement modifiable...
Puis avec toutes les possibilités et descriptions d'Ali, tu devrais savoir quoi faire
Je ne comprends pas pourquoi tu veux changer le nom de ta base lors d'une mise à jour ?
1) Quand tu lances ton app pour la première fois, tu copies la base que tu as préparée dans le bundle de l'application dans le dossier Documents associé à ton app
2) Quand il y a une mise à jour, tu la télécharges dans le dossier Documents (sous un nom temporaire), puis pour mettre à jour bah tu supprimes juste l'ancienne base et renomme la base fraà®chement téléchargée pour qu'elle ait le même nom que l'ancienne que tu viens de supprimer
D'ailleurs si tu optes pour la solution du PLIST tu auras le même problème : même si le PLIST est un ficheir de données et n'est pas compilé comme des constantes, s'il reste à l'intérieur de ton bundle comme les bundles iOS sont signés et ne peuvent être modifiés tu ne pourras pas modifier ton PLIST. Il faudra donc à l'image de ta DB si tu veux pouvoir le mettre à jour que tu le mettes dans le dossier Documents (voire Library/AppSupport) de la sandbox de ton application pour qu'il soit modifiable de là . Et du coup arrivé là , autant utiliser NSUserDefaults (qui en plus sous le capot gère un PLIST générique) ça sera plus simple.
Mais de toute façon je vois pas trop l'utilité de pouvoir modifier le nom de ta base vu que lors d'une mise à jour c'est plus simple de remplacer l'ancienne par la nouvelle...
Cependant cette méthode à l'air de complexifier un peu trop le système.
Je vais donc choisir la méthode du NSUserDefault et me débrouiller autrement pour le check de version