Sauvegarde de certaines propriétés d'un singleton
Flo
Membre
Bonjour à tous,
dans mon application j'ai un certain nombre de singletons (Managers) qui rendent des services partagés accessibles par divers controllers. Je souhaiterai sauvegarder certaines propriétés (NSArray, NSDictionary, ...) de ces singletons pour les restaurer au prochain lancement de l'application. J'aimerai également que seuls les singletons en question aient la connaissance des propriétés à sauvegarder et de celles à charger.
Dans cette optique, je pensais faire des méthodes communes à ces singletons déclarées dans un protocole du style :
En gros, au lancement de l'application, l'appDelegate construit le NSKeyedArchiver et le transmet à tous les singletons qui ont besoin des données qui s'y trouvent. Idem pour la sauvegarde.
Question 1 : Est-ce que ça choque quelqu'un ? Je ne sais pas si c'est super propre de trimbaler un NSKeyedArchiver comme ça.
Question 2 : Pourquoi ne pas implémenter le protocole NSCoding par chacun des singletons ? ça me semble impossible sur une architecture de type singleton où ces derniers sont créés dans un ordre aléatoire et où ils doivent partager la même source de récupération et de sauvegarde des données. Quel est votre avis ?
Merci d'avance
dans mon application j'ai un certain nombre de singletons (Managers) qui rendent des services partagés accessibles par divers controllers. Je souhaiterai sauvegarder certaines propriétés (NSArray, NSDictionary, ...) de ces singletons pour les restaurer au prochain lancement de l'application. J'aimerai également que seuls les singletons en question aient la connaissance des propriétés à sauvegarder et de celles à charger.
Dans cette optique, je pensais faire des méthodes communes à ces singletons déclarées dans un protocole du style :
<br /> - (void) saveData: (NSKeyedArchiver *)keyedArchiver;<br /> - (void) loadData: (NSKeyedArchiver *)keyedArchiver;<br />
En gros, au lancement de l'application, l'appDelegate construit le NSKeyedArchiver et le transmet à tous les singletons qui ont besoin des données qui s'y trouvent. Idem pour la sauvegarde.
Question 1 : Est-ce que ça choque quelqu'un ? Je ne sais pas si c'est super propre de trimbaler un NSKeyedArchiver comme ça.
Question 2 : Pourquoi ne pas implémenter le protocole NSCoding par chacun des singletons ? ça me semble impossible sur une architecture de type singleton où ces derniers sont créés dans un ordre aléatoire et où ils doivent partager la même source de récupération et de sauvegarde des données. Quel est votre avis ?
Merci d'avance
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Perso, je verrais bien chaque singleton totalement autonome pour la gestion de ses propres données.
Pour le chargement, c'est facile puisque qu'un singleton n'est initialisé qu'une seule fois.
Pour la sauvegarde, il suffit que chaque singleton s'enregistre pour recevoir la notification NSApplicationWillTerminateNotification.
Chacun s'occupe de ses affaires et tout le monde est content
c'est vrai que ça simplifie pas mal les choses tout en conservant le côté : "chaque singleton est le seul gestionnaire de la manipulation de ses données"
Ce qui m'embête un peu c'est que ça va multiplier les accès disque (un fichier par singleton) mais bon, j'ai l'impression que je ne vais pas pouvoir gagner sur tous les tableaux
On peut partir d'un unique singleton (AppDelegate ?) et celui-ci se chargeant d'instancier les différents managers et de gérer et distribuer les données de chacun de ces managers à partir d'un fichier unique.
Ce singleton se chargerait des accès disques et de la création des autres singletons avec les données sauvegardées.
Au moment où il faut sauvegarder, il collecte les donnés d'init.
Les données pourraient transiter sous la forme d'un dictionnaire.
Après la solution que tu décris de délocaliser la serialisation au niveau de chaque objet en passant un contexte de serialisation est possible aussi mais dans ce cas tu vas de toute façons avoir besoin d'une liste centrale de singleton.
Moi je reserverais ce pattern aux cas où le nombre et le type des objets à serialiser n'est pas connu a l'avance. Ca se traduit par :"je ne veux pas savoir qui vous êtes, juste déposer vos données dans ce panier et passez le au suivant".
Dans ce cas, le singleton n'est pas obligé de connaitre la techno de sauvegarde, le "panier" que tu passes doit faire abstraction du support de sauvegarde ( fichier, memoore, user default).
Il y a aussi la solution du chacun pour soi, chacun sauvegarde dans sn propre fichier. Cette solution te permet de réutiliser les singletons sans te préoccuper des dépendances à un objet externe pour la sauvegarde.
Dans l'absolu, il n'y a pas de solution meilleure qu'une autre.
Il faut juste choisir en fonction de tes besoin actuels, du temps dont tu disposes, des évolutions que tu envisages et des opportunités de réutilisation dans d'autres projets.
Je faisais comme ça avant de passer à une architecture singleton pour les services métier à une seule implémentation et partagés entre les différents controleurs de l'application. J'avais switché pour les raisons suivantes :
- trop de dépendances : une avec l'appDelegate et une avec le service pour chaque contrôleur
- la récupération qui se fait via [NSApp delegate] dans chaque contrôleur n'est pas souple, si ce n'est plus l'appDelegate qui distribue les instances de services il faudra implémenter un autre mécanisme de récupération (singleton).
Après il est vrai que l'utilisation de singletons pose d'autres problèmes du style, impossible d'utiliser le protocole NSCoding et iniWithCoder: pour instancier le singleton et donc nécessité de passer par un archiver partagé ou, comme le dit FKDEV, de faire un autre singleton dédié à l'archivage/désarchivage :
C'est vrai que ça permet également d'encapsuler la techno de manipulation des données ce qui est intéressant.
Tout à fait d'accord avec toi. Pour l'instant je suis partagé entre ta solution de data manager partagé qui offre des aspects intéressants et celle de mpergand qui est quand même radicalement plus simple et qui permettrait de repasser par le protocole NSCoding.