›

binder le numéro de version sur un Label depuis info.plist

APAP Membre
15:05 modifié dans API AppKit #1
Petite question qui je le pense est assez simple, comment simplement binder vers un label le numéro de version de l'appli contenu dans le info.plist?

Merci d'avance pour votre aide :)

Réponses

  • AliGatorAliGator Membre, Modérateur
    15:05 modifié #2 
    NSString* versionString = [[NSBundle mainBundle]<br />&nbsp; &nbsp; objectForInfoDictionaryKey:@&quot;CFBundleVersion&quot;];
  • APAP Membre
    15:05 modifié #3
    Merci. En effet c'est tout simple. Possible de le faire automatiquement depuis IB?
  • AliGatorAliGator Membre, Modérateur
    15:05 modifié #4
    Nop, je ne pense pas que NSBundle soit binding-compliant (si c'est par ce biais que tu voulais passer)
    Mais en même temps, une ligne de code, c'est trop pour toi ? ;)
  • APAP Membre
    15:05 modifié #5
    dans 1291592855:

    Nop, je ne pense pas que NSBundle soit binding-compliant (si c'est par ce biais que tu voulais passer)
    Mais en même temps, une ligne de code, c'est trop pour toi ? ;)

    Un ligne ca passe encore  ;)  C'était juste par curiosité, vu qu'info.plist est très proche d'un fichier préférences et que ceux-ci se bind sans problème sous IB
  • AliGatorAliGator Membre, Modérateur
    15:05 modifié #6
    Les préférences sont dans les NSUserDefaults, qui est une classe binding-compliant, qui sait écouter les modifications externes ou internes des fichiers de préférences, qui permet de synchroniser automatiquement ou manuellement les préférences et leurs clés de leur représentation en mémoire vers la représentation dans un fichier et vice-versa...
    NSBundle quand à  lui est une classe qui représente un bundle. Ce bundle a un "infoDictionary", qui contient des clés décrivant diverses métadonnées sur le bundle (son bundleIdentifier, sa version, ...) et certes ce infoDictionary est construit à  partir du contenu du fichier Info.plist, mais ça reste des métadonnées sur ton Bundle (métadonnées immuables, non modifiables au runtime, etc)

    Au final le seul point commun que ça a avec NSBundle c'est que les données que tu cherches sont dans un fichier au format PLIST, et encore tu n'as même pas à  le savoir pour NSUserDefaults (on sait tous que ce sont des plist les fichiers de prefs, mais ce n'est pas avec le PLIST que tu communiques, mais avec le singleton NSUserDefaults qui a une représentation mémoire des prefs, quelle que soit leur représentation sérialisée)

    Les NSUserDefaults devant pouvoir être modifiable par définition car ce sont des préférences, il est logique que ce soit KVO- et KVC-compliant, et que la classe soit à  l'écoute des modifications de ces données, permette les bindings en conséquence et informe les observeurs quand une valeur change, et modifie le fichier de préférences lors de la synchronisation. NSBundle lui n'est pas modifiable, son infoDictionary décrivant ses métadonnées est immuable, il n'y aurait pas de logique à  proposer dans une quelconque interface un moyen de modifier ces métadonnées... donc l'intérêt de les exposer sous forme de binding me parait largement limité. Le fait que ces données soient dans un PLIST dans le cas NSUserDefaults comme NSBundle n'a rien à  voir avec tout cela (les plist ne sont que des formats de sérialisation de données)
  • APAP Membre
    15:05 modifié #7
    dans 1291635067:

    Les préférences sont dans les NSUserDefaults, qui est une classe binding-compliant, qui sait écouter les modifications externes ou internes des fichiers de préférences, qui permet de synchroniser automatiquement ou manuellement les préférences et leurs clés de leur représentation en mémoire vers la représentation dans un fichier et vice-versa...
    NSBundle quand à  lui est une classe qui représente un bundle. Ce bundle a un "infoDictionary", qui contient des clés décrivant diverses métadonnées sur le bundle (son bundleIdentifier, sa version, ...) et certes ce infoDictionary est construit à  partir du contenu du fichier Info.plist, mais ça reste des métadonnées sur ton Bundle (métadonnées immuables, non modifiables au runtime, etc)

    Au final le seul point commun que ça a avec NSBundle c'est que les données que tu cherches sont dans un fichier au format PLIST, et encore tu n'as même pas à  le savoir pour NSUserDefaults (on sait tous que ce sont des plist les fichiers de prefs, mais ce n'est pas avec le PLIST que tu communiques, mais avec le singleton NSUserDefaults qui a une représentation mémoire des prefs, quelle que soit leur représentation sérialisée)

    Les NSUserDefaults devant pouvoir être modifiable par définition car ce sont des préférences, il est logique que ce soit KVO- et KVC-compliant, et que la classe soit à  l'écoute des modifications de ces données, permette les bindings en conséquence et informe les observeurs quand une valeur change, et modifie le fichier de préférences lors de la synchronisation. NSBundle lui n'est pas modifiable, son infoDictionary décrivant ses métadonnées est immuable, il n'y aurait pas de logique à  proposer dans une quelconque interface un moyen de modifier ces métadonnées... donc l'intérêt de les exposer sous forme de binding me parait largement limité. Le fait que ces données soient dans un PLIST dans le cas NSUserDefaults comme NSBundle n'a rien à  voir avec tout cela (les plist ne sont que des formats de sérialisation de données)


    Merci Ali pour ces informations très détaillées.
Connectez-vous ou Inscrivez-vous pour répondre.