›

Partager un singleton dans un NSDocument

colas_colas_ Membre
dans API AppKit #1

Comment fait-on ?


 


J'ai procédé comme suit mais ça bugue !!


Réponses

  • colas_colas_ Membre
    #2

    ça marche, le bug était ailleurs (j'avais oublié un return self !)


  • mpergandmpergand Membre
    mai 2013 modifié #3

    B)


     


    [EDIT]


     


    C'est CoreData qui oblige à  ce micmac avec les singletons ?


  • colas_colas_ Membre
    #4

    Non, j'ai besoin d'un singleton pour balader mes constantes.


     


    J'ai choisi d'en faire une @property dans chaque instance de Document.


    Comme ça, j'y accède directement, sans devoir faire [[NSApp delegate] monSingleton].


     


    J'ai un NSArray constant qui doit peupler une NSTableView.


    J'ai besoin de faire des bindings avec ce NSArray.......


     


    ;)


  • jpimbertjpimbert Membre
    #5


    Non, j'ai besoin d'un singleton pour balader mes constantes.


     


    J'ai choisi d'en faire une @property dans chaque instance de Document.


    Comme ça, j'y accède directement, sans devoir faire [[NSApp delegate] monSingleton].




     


    Je trouve que c'est une idée bizarre de faire les deux à  la fois :


    - soit on a une propriété chaque fois que nécessaire, et alors cela ne coûte rien de l'initialiser par un appel au délégué d'application (pas besoin de singleton)


    - soit on a un singleton par définition disponible partout (par sharedInstance) et alors on n'a pas besoin de propriété

  • colas_colas_ Membre
    #6

    @jpimbert Je suis d'accord avec toi, mais vu que je compte faire un binding sur une @property de ce singleton, j'ai choisi de mettre ce singleton en @property de ma classe Document.


     


    Aurais-je pu mettre en binding (via IB) [MySingleton sharedInstance].myProperty ?


    Je ne pense pas. En le faisant sans IB, oui, je pense que ça aurait marché.


     


    Donc, il fallait que mon singleton soit une @property de Document.


    ça me paraissait plus logique qu'elle soit weak, donc il fallait qu'elle soit strong quel que part, en l'occurrence dans AppDelegate.


     


    Bon, après c'est clair que j'aurai pu faire plus simple :)


    Je me dis que faire comme ça est une sorte de pattern que je pourrai réutiliser dans d'autres programmes.


     


     


    En fait, je suis vraiment mal à  l'aise avec les variables globales.


    Je ne connais rien d'autre que les langages objet.


    Cette idée d'un singleton qui contient les constantes est plus facile pour moi.


    D'où l'idée d'un singleton avec les constantes accessibles via @property (car c'est plus facile d'y accéder si c'est une @property)


  • jpimbertjpimbert Membre
    #7


    Donc, il fallait que mon singleton soit une @property de Document.


    ça me paraissait plus logique qu'elle soit weak, donc il fallait qu'elle soit strong quel que part, en l'occurrence dans AppDelegate.




     


    Il suffit donc de créer une instance référencée par une propriété strong dans le délégué d'application. Pas besoin de singleton.


     


    Si tu n'avais pas de propriété strong dans le délégué d'application, un singleton se justifierait pour initialiser les propriétés liées ("bindées") avec IB.

  • mpergandmpergand Membre
    mai 2013 modifié #8


    En fait, je suis vraiment mal à  l'aise avec les variables globales.


    Je ne connais rien d'autre que les langages objet.


    Cette idée d'un singleton qui contient les constantes est plus facile pour moi.


    D'où l'idée d'un singleton avec les constantes accessibles via @property (car c'est plus facile d'y accéder si c'est une @property)




     


    S'il s'agit de constantes globales, on peut utiliser les enums, tableaux, structures du C.


     


    Voici un exemple de définition de la structure d'une base de données (extrait)



    
#import <sqlite3.h>
    

    
enum
    
{
    
ValueType_String,
    
ValueType_Text,
    
ValueType_Date,
    
ValueType_Int,
    
ValueType_Float,
    
ValueType_Image,
    
};
    

    
typedef struct
    
{
    
NSString*	displayName;
    
NSString*	name;
    
int			type;
    
}Col_Info;
    

    
typedef struct
    
{
    
NSString*	displayName;
    
NSString*	name;
    
Col_Info	colInfo[];
    
}Table_Info;
    

    

    
extern const Table_Info const* TableInfo[];
    
extern NSString* BookImageName[];
    

    

    

    

    
fichier .m
    

    
// CREATE TABLE localisation (nom TEXT PRIMARY KEY, commentaire TEXT);
    
Table_Info LocalizationTableInfo=
    
{
    
@Localization,@localisation,
    
{
    
{@Name,@nom,ValueType_String},							// text
    
{@Comment,@commentaire,ValueType_Text},
    
{NULL}
    
}
    
};
    

    
// CREATE TABLE langue (nom TEXT PRIMARY KEY, commentaire TEXT);
    
Table_Info LanguageTableInfo=
    
{
    
@Language,@langue,
    
{
    
{@Name,@nom,ValueType_String},							// text
    
{@Comment,@commentaire,ValueType_Text},
    
{NULL}
    
}
    
};
    

    
const Table_Info const * TableInfo[]=
    
{
    
&LanguageTableInfo,
    
&LocalizationTableInfo,
    
};
    

    

    
NSString* BookImageName[]=
    
{
    
@Front Image,
    
@Back Image,
    
@Side Image,
    
nil
    
};

  • berfisberfis Membre
    mai 2013 modifié #9


    En fait, je suis vraiment mal à  l'aise avec les variables globales.




    Moi aussi, c'est horrible, ça me rappelle les affres du FORTRAN77, où il fallait rechercher quelle ligne avait manipulé cette fichue variable qui n'avait jamais la bonne valeur au bon moment.


     


    D'un autre côté, justement, si tu veux programmer "objets", tu es en train de créer une liaison très forte entre tes classes, ce qui n'est pas souhaitable.


     


    1. "Aurais-je pu mettre en binding (via IB) [MySingleton sharedInstance].myProperty ?"


    Qu'est-ce qui t'empêche de faire un binding sur mySingleton.myProperty ?


     


    2. S'il s'agit de balader des valeurs entre documents, pourquoi ne pas utiliser les User Defaults?


     


    @mpergand : Core Data n'est pas la source de tous les maux  :)


    B.


  • mpergandmpergand Membre
    mai 2013 modifié #10

    Il existe déjà  un singleton dans toutes les applis Cocoa: NSApp et avec [NSApp delegate] on peut accéder au AppDelegate partout dans l'appli. Dans ce AppDelegate on ajoute toutes les variables globales que l'on veut et voilà  !


     



     


    S'il s'agit de balader des valeurs entre documents, pourquoi ne pas utiliser les User Defaults?

     



     


    Tout à  fait, une variable globale à  toute les chances de trouver sa place dans les préférences.


  • colas_colas_ Membre
    #11


    Il existe déjà  un singleton dans toutes les applis Cocoa: NSApp et avec [NSApp delegate] on peut accéder au AppDelegate partout dans l'appli. Dans ce AppDelegate on ajoute toutes les variables globales que l'on veut et voilà  !


     




     


    ça se discute !


    http://www.cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html

  • colas_colas_ Membre
    #12


    1. "Aurais-je pu mettre en binding (via IB) [MySingleton sharedInstance].myProperty ?"


    Qu'est-ce qui t'empêche de faire un binding sur mySingleton.myProperty ?


     




     


    Du coup, je dois créer une @property mySingleton pour chaque NSDocument ! 


    C'est aussi pour ça que je l'ai fait.

  • mpergandmpergand Membre
    #13



     


    Je n'utilise ni les singletons ni AppDelegate pour les variables globales  :P


     



     


    Singletons and top-level data should be used only when the data they contain truly belongs at the top level.

     


  • berfisberfis Membre
    mai 2013 modifié #14


    Non, j'ai besoin d'un singleton pour balader mes constantes.


     


    J'ai choisi d'en faire une @property dans chaque instance de Document.


    Comme ça, j'y accède directement, sans devoir faire [[NSApp delegate] monSingleton].


     


    J'ai un NSArray constant qui doit peupler une NSTableView.


    J'ai besoin de faire des bindings avec ce NSArray.......




     


    Pour en revenir à  ton problème de départ, tu parles de "constantes" et d'un "array constant". Je reviens sur les User Defaults: tu as, gratuitement, un contrôleur standard, accessible de partout, et dont toutes les valeurs sont "bindables". Pourquoi réinventer la poudre, surtout si celle de ton invention risque de faire sauter ton programme?


     


    Le titre même de ton sujet est suspect: un singleton ne se "partage" pas entre documents... Es-tu sûr que cette idée mérite le titre de "pattern"?


     


    Enfin, une dernière chose qui me turlupine... si tout cela sert à  binder des constantes, tu n'aurais pas avantage à  en faire des labels dans ton interface?


     


    @mpergand joli, le lien... et (ouf) rassuré de voir qu'on pense toujours autant de bien des variables globales 20 ans après  ^_^


  • colas_colas_ Membre
    #15


     


    Enfin, une dernière chose qui me turlupine... si tout cela sert à  binder des constantes, tu n'aurais pas avantage à  en faire des labels dans ton interface?


     


    @mpergand joli, le lien... et (ouf) rassuré de voir qu'on pense toujours autant de bien des variables globales 20 ans après  ^_^



     


     


    C'est pour remplir une NSTableView.


    C'est moi qui ai mis le lien :)


  • berfisberfis Membre
    mai 2013 modifié #16

    Ben à  plus forte raison alors! Si tu as lu le contenu, il donne raison à  mpergand... Mort aux variables globales!


     


    As-tu pensé à  un NSDictionary ? Tu remplis une plist, tu charges tes constantes et ton array, et tu bindes par ses clés/valeurs...


     


    Tu n'as pas l'intention d'éditer des constantes tout de même? C'est un "binding à  sens unique" dans une NSTableView non éditable alors?


     


    ... Variables Won't, Constants Aren't ...

  • mpergandmpergand Membre
    #17

     



    Tu n'as pas l'intention d'éditer des constantes tout de même? 



     



    Ben ouais, j'ai du mal à  suivre là  ...

  • colas_colas_ Membre
    #18

    Merci pour vos conseils !


    J'ai choisi les plist (que je connaissais pas !!!!)


Connectez-vous ou Inscrivez-vous pour répondre.