›

Créer un Singleton sous Xcode

Alf1996Alf1996 Membre
dans API UIKit #1

Voila, je viens de comprendre en cherchant sur le forum que j'aurais dû utiliser un singleton pour les données que j'utilise ; il s'agit de données que je lis au début de mon application, dont j'ai besoin à  plusieurs endroits différents, et que je ne modifie jamais (pas de risque de problème avec du multi-threading). Jusqu'à  présent, je transmettais les données dont j'avais besoin au moment de l'instanciation de mes différentes vues. Oui, maintenant j'ai compris... c'est pas comme çà  qu'il faut faire !!


J'ai donc décidé de corriger tout çà  et de créer un singleton, mais évidemment, j'ai quelques questions :


- comment faire pour créer un Singleton sous Xcode ? dois-je créer une classe et faire les déclarations à  la main, ou existe-t-il un template (je n'en ai pas trouvé, mais...) ?


- j'ai plusieurs NSdictionnary qui sont concernés, dois-je créer un singleton par dictionnary, ou puis-je tout mettre dans le même singleton ?


 


Merci d'avance pour vos réponses.  o:)


Mots clés:

Réponses

  • klozenklozen Membre
    #2

    petit exemple : http://www.geckogeek.fr/creer-un-singleton-sur-iphone-en-cocoa-objective-c.html


    ou encore la dans un autre exemple plus ludique :P http://www.raywenderlich.com/3276/how-to-make-a-simple-multiplayer-game-with-game-center-tutorial-part-12


     


     


    Donc si j'ai bien compris un Signleton est un objet instancié en principe qu'une seule et unique fois au cours de l'utilisation de ton application et qui est partagé ou l'on veux pour accéder à  ses ressources. Etant donné que c'est un objet je pense que tu peut regrouper tes dictionnary à  l'intérieur.

  • CéroceCéroce Membre, Modérateur
    #3


    Jusqu'à  présent, je transmettais les données dont j'avais besoin au moment de l'instanciation de mes différentes vues. Oui, maintenant j'ai compris... c'est pas comme çà  qu'il faut faire !!




     


    Et pourquoi pas ?


    Cette méthode a l'avantage d'afficher clairement les dépendances entre classes. C'est un gros avantage pour la réutilisation du code.

  • AliGatorAliGator Membre, Modérateur
    #4

    Hello le melmacien


     


    Attention, je ne suis pas sûr que le singleton soit la solution, passer le modèle de proche en proche (voire uniquement la partie du modèle qui est utile) est même plutôt en général une meilleure solution.


     


    Personnellement j'utilise les sharedInstance plutôt pour tout ce qui est "service", c'est à  dire des classes métiers qui permettent de gérer les appels aux WebServices, ou les classes pour gérer mes préférences, pour connaà®tre la connectivité (Reachability)...


     


    Concernant le modèle, soit j'utilise CoreData (via MagicalRecord) et dans ce cas la question ne se pose pas, je ne me balade pas avec des singleton pour accéder à  mes données, je fais directement mes fetch CoreData quand j'en ai besoin (et je passe mes entités de proche en proche, de VC en VC, pour éviter de les refetcher quand cela convient), mais sinon si j'ai des vues qui correspondent à  peu près à  mes objets Modèle, je les passe aussi de proche en proche. Donc pas de singleton.


     


    Par exemple, pour une application de type Master/Detail où tu aurais disons une liste de personnes, et sur un tap dans la liste la fiche détail d'une personne, tu n'as pas à  te trimbaler tout le modèle partout : dans le VC "Master", tu as ton NSArray de Personnes, et quand tu tap sur une ligne tu passes juste l'objet Person qui est à  afficher.


    Bien sûr, si tu gères une application de généalogie, où chaque personne peut être liée à  d'autres personnes, etc, tu peux avoir besoin de tirer un peu plus sur le fil de la pelote de laine et passer un peu plus d'éléments de ton modèle... Mais dans ce cas si ton modèle est bien fait tout est déjà  relié : l'objet Person que tu passes a certainement déjà  des liens vers les autres objets Person liés (parents, enfants, etc) auxquels tu voudrais avoir accès pour afficher dans ton VC aussi, donc implicitement tu les as déjà  passés (si tu utilises CoreData pour ça ça se fait implicitement via les relationships). Au final on s'y retrouve en général plutôt bien.


     


    Il faut toujours penser MVC. Parfois tu peux penser à  tort que ton UI est fortement liée à  ton modèle, parce qu'il faut que tu passes toujours ton modèle entier pour avoir tout plein d'informations. Mais en général en vrai tu as déjà  un seul objet qui regroupe tout ton modèle si besoin et que tu peux passer.


     


    Par exemple si tu fais un jeu d'échecs, tu pourrais te dire "dans mon VC qui affiche le plateau, j'ai besoin de plein d'infos, je vais faire un singleton qui mémorise tout, l'état du plateau avec la position des pièces, le score, l'historique des coups, à  qui est le tour... et utiliser ce singleton dans mon VC pour afficher le plateau car j'aurai besoin d'un peu tout" mais ce n'est pas la bonne approche. Ton ViewController doit savoir afficher n'importe quel plateau. Qui te dit que plus tard tu ne vas pas rajouter à  ton appli la possibilité de sauver plusieurs parties et réutiliser le même VC pour afficher des parties que ce soit la partie en cours ou une partie sauvegardée... Faut toujours penser MVC et à  bien décorreler. En général plutôt que d'avoir un singleton qui regroupe tout (l'ensemble des pièces, le plateau, le nom des joueurs, l'historique des coups...) tu auras un objet qui représente une "Partie" et qui regroupera déjà  toutes ses infos. Bah cet objet, il n'a pas de raison d'être singleton, ça peut être un NSObject normal, que tu passes de proche en proche au besoin.


    Se contraindre à  un singleton ou une sharedInstance ici n'a aucun intérêt et va te mettre des bâtons dans les roues quand tu vas vouloir faire évoluer ton appli pour y afficher d'autres parties d'échec que la partie courante.


     


     


    Bref à  travers ces exemples réfléchis à  savoir si l'utilisation d'un singleton ou d'une sharedInstance est vraiment judicieuse. En général, à  part pour tout ce qui est aspect "service" genre briques qui fournissent des fonctionnalités transverses pas rattachées à  un objet, ou pour les trucs vraiment rattachées à  toute ton application ou le contexte d'exécution (les préférences le modèle de la machine courante, ...), le singleton n'est pas forcément justifié. En particulier pour stocker des informations côté modèle de données, à  mon avis ça ne l'est jamais (ou alors pas souvent)


  • samirsamir Membre
    mai 2013 modifié #5

    Bonjour,


    Vraiment pas évident de cerner toutes ces notions objets.


     


    Une question, j'ai dans mon application un objet comme suit :



    
@interface Book : NSObject 
    
property (nonatomic, strong) NSString *bookName;
    
....

    Et j'ai créer une autre classe ( pourquoi : je ne sais pas, juste en croyant bien faire) : BookManger qui n'est pas un singleton ni une shared instance, juste une class avec seulement des méthodes de class, comme suit :



    
@interface BooManager : NSObject 
    

    
+ (BOOL)bookExistsAtPath:(NSString*)path;
    

    
+ (BOOL)bookExistsWithID:(NSString*)ID;
    

    
+ (NSString *)booksStoragePath;
    

    
+ (NSString *)booksDownloadPath;
    
...

    Ma question est la suivante : peux on créer un singleton ( ou bien une Class  comme BooManager) pour gérer le modèle objet Book. c'est quoi le plus propre ? Peux etre vaut mieux rajouter tous les service de BookManager à  mon modèle objet Book pour qu'il puisse réponde lui meme aux demandes d'autre classes (bookExistsAtPath,....)


     


    Merci pour vos réponses.


     


    ps : je considère que je ne sors pas hors sujet par rapport à  la question de @Alf1996, puisque m'a question est en relation avec le MVC.


  • Am_MeAm_Me Membre
    mai 2013 modifié #6


     


    ps : je considère que je ne sors pas hors sujet par rapport à  la question de @Alf1996, puisque m'a question est en relation avec le MVC.




     


    Plop, Yop comme tu voudras


    Tu n'est pas totalement HS mais je te conseillerai de faire un nouveau topic au dessus de ton commentaire il y a des paves d'écriture 


    Donc rare les personnes qui verront ton messages c'est un conseil apres je suis nouveau, je suis un Eleveur de cacaoyers et toi un Cueilleur de cabosses xD


     


     mais bon 


     


    Ps: Dsl je suis HS 


  • Alf1996Alf1996 Membre
    #7

    Ouah... Que de réponses en si peu de temps ! 


     



    Hello le melmacien



     


    çà  fait tellement longtemps que je suis arrivée sur terre que je ne me souvenais même plus du nom de ma planète ! Alzheimer peut-être !  ::)


    Merci les terriens...


     


    Alors, apparemment c'est mieux si je laisse comme mon code en l'état... du moins pour ce point !


     


    Merci pour toutes ces explications, c'est bien plus clair pour moi maintenant. 


     


  • DrakenDraken Membre
    #8
    T'as déjà  oublié que Melmac a été détruite dans une guerre nucléaire entre les Melmaciens et les chats ?
Connectez-vous ou Inscrivez-vous pour répondre.