De l'utilisation d'Interface Builder

GreensourceGreensource Membre
00:12 modifié dans Xcode et Developer Tools #1
Je viens de lire un post d'Ali qui parlais de l'utilisation d'Interface Builder et ça m'a fait penser à  un truc. On utilise habituellement IB pour configurer ses interfaces graphiques, souvent on s'en sert donc notamment pour faire les liens entre les différents attributs.
Je me disais, pourquoi pas détourner cette utilisation pour faire les configurations de nos objets perso? Ca permet de déporter du code la configuration, et il suffit donc ensuite juste de modifier les XIB pour changer les configurations de nos objets.

Quelqu'un a déjà  fait ça? Ca semble intéressant?

Réponses

  • AliGatorAliGator Membre, Modérateur
    00:12 modifié #3
    Oui et non. C'est tout à  fait faisable... Mais ça reste vite limité.
    En effet, si ce n'est pas des éléments graphiques, il n'y aura rien dans les palettes d'IB pour configurer tes objets.
    Autant pour une UIImageView, IB sait ce que c'est donc te propose par exemple d'indiquer le nom de l'image à  utiliser.
    Autant pour un GreenSourceBidule, il sait pas ce que c'est ni ce qu'il peut re proposer comme propriétés à  modifier.

    D'ailleurs je trouve ça dommage qu'on puisse pas genre via un mot clé IBProperty ou quoi dans le .h, exposer certaines propriétés à  IB (genre une UIImage, une NSString, un BOOL qui serait représenté dans la palette par une checkbox, etc...) mais ce n'est pas (encore?) possible.
    Sous OSX, on peutcréer des IBPalettes / IBPlugins personnalisées ce qui nous permet de configurer des objets à  nous via ces palettes. Sous IB pour iPhone il me semble qu'on ne peut pas malheureusement. A moins que depuis les dernières évolutions de IB ils aient remis ça pour la version iPhone également ?

    Du coup tu peux dans ton XIB mettre des objets persos, pas forcément graphiques donc, mais tu ne vas pas aller bien loin. Tu pourras faire créer un objet Tata et un objet Toto, et affecter cet objet Tata à  la variable/IBOutlet "monTata" de l'objet Toto... mais tu ne pourras pas aller beaucoup plus loin...
  • GreensourceGreensource Membre
    00:12 modifié #4
    C****, c'est con parce que l'outil est là  il manque juste un moyen simple de l'étendre. Je vais aller voir le coup des palettes même que MacOSX ça peut-être intéressant en effet.
  • laudemalaudema Membre
    00:12 modifié #5
    Il y a quand même dans IB la possibilité de créer des Outlets ou de dériver/sous classer une classe existante puis lui ajouter des outlets ou des actions.
    Par contre je me demande encore à  quoi peut bien servir "User defined runtime attributes" qu'on a dans le dernier onglet de la palette (identity). Il n'y a aucun exemple dans la doc et je n'ai rien trouvé sur internet
  • AliGatorAliGator Membre, Modérateur
    août 2010 modifié #6
    Ouah mais t'as raison Laudema, j'avais jamais fait gaffe à  cette palette... mais elle a l'air de prévoir de faire exactement cela, en indiquant un keypath, son type, et sa valeur à  fixer pour l'objet en question !
    La doc à  ce sujet ici

    J'avais jamais vu et j'ai jamais testé encore, mais j'imagine que donc si on a un objet perso avec un attribut "BOOL toto", on peut rajouter dans ce tableau "User defined runtime attributes" de la palette IB une ligne pour le keypath "toto" de type "BOOL" et cocher ou non la case selon si on veut qu'il ait la valeur YES ou NO, etc.

    Bon j'aurais préféré qu'on ait un mot clé (du même accabit que le mot clé "IBOutlet" ou "IBAction") que IB irait lire dans le .h et nous permettant d'indiquer les variables d'instance qu'on veut exposer, car là  il faut connaà®tre le nom exacte des attributs que l'on veut affecter, il ne nous propose pas une liste toute faite, mais c'est un bon début...

    Par contre, je ne l'ai pas moi dans mon IB... du moins sur les projets que j'ai testé (projets iPhone)... j'ai l'impression que ce n'est que pour les projets Mac, encore une fois... mais pourquoi donc cette restriction ?!
  • GreensourceGreensource Membre
    00:12 modifié #7
    C'est pas une histoire de Bindings qu'on a pas sous iOS pour le moment?
  • laudemalaudema Membre
    00:12 modifié #8
    Merci pour la documentation, je me demande comment j'ai pu passer à  côté (à  rattacher au sujet sur la recherche dans la documentation mais là  c'est aussi une nouveauté, j'ai peut être regardé dans une vieille version de la doc IB)
  • AliGatorAliGator Membre, Modérateur
    00:12 modifié #9
    Bah non c'est juste lié au KVC vu que ça appelle setValue:forKeyPath: sur les propriétés qu'on met là -dedans d'après la doc, donc je vois pas pourquoi...
  • laudemalaudema Membre
    00:12 modifié #10
    Oui mais si c'est dans IB alors après c'est congelé dans des fichiers XML (si j'ai bien compris) et cette procédure n'est peut être pas au point pour l'iPhone dont les xib ont des vues et des contrôles bien différents de ceux de Mac OS et donc peut être une configuration qui ne permet pas facilement d'y intégrer cette technologie pour le moment
  • AliGatorAliGator Membre, Modérateur
    00:12 modifié #11
    Non ça change rien. Un XIB n'est rien d'autre qu'une  d'un arbre d'objets avec des propriétés, ça utilise d'ailleurs les NSArchiver. Il n'y a aucune raison technique à  cette restriction, ou en tout cas pas celle là  
  • sekaijinsekaijin Membre
    00:12 modifié #12
    en fait on peut aller un peu plus loin
    par contre je n'ai jamais vérifier l'intérêt de la faire mais pourquoi pas

    en imaginant qu'on ai développé un composant (sans IHM) qu'on réutilise de dev en dev et qui demande à  chaque fois de fixer certaine propriété.

    Utiliser parait être une bonne solution il permet d'instancier le composant, de fixer les paramètres voire même créer les liaisons avec le reste du code.

    pour y parvenir il faut créer un ibplugin

    en effet par le biais des ibplugin IB peux accéder au éléments du composant
    cela nécessite bien sur de revoir la façon dont on développe le composant à  réutiliser.

    IB à  prévu ce mécanisme pour permettre d'ajouter des composants graphique mais je n'ai rien vu qui empêche de faire un plugin pour un objet dans IHM
    Mais je n'ai pas tout vu sur le fonctionnement des ibplugin

    il nous faudrait pro de chez pro dans le domaine.

    A+JYT
  • AliGatorAliGator Membre, Modérateur
    00:12 modifié #13
    Oui mais qqun a déjà  essayé de créer un IBPlugIn pour un composant pour iPhone ?
    Car on en revient toujours à  ça, tout ça a l'air dispo pour quand on utilise IB pour un projet OSX, mais pas iOS :-(

    Je sais pas si ça a changé depuis, mais j'avais déjà  essayé de créer justement un IBPlugIn, mais quand j'ai voulu le faire pour iPhone, comme faut encapsuler le tout dans un framework perso (qui contient à  la fois la palette IB personnalisée, le composant graphique (XIB) et les fichiers de code) et que créer un framework pour iPhone c'est pas possible... bah tout de suite ça bloque d'entrée de jeu...

    Ca serait quand même top de pouvoir créer des sortes de "frameworks statiques", à  l'instar des librairies statiques... car si un framework est fait à  la base pour contenir à  la fois une librairie dynamique (dylib) et des ressources associées (images, bundles, ...) si on avait le même système pour des libs linkées à  l'exécutable à  la compilation ça permettrait d'avoir les avantages d'un framework mais pour iPhone aussi (puisque si Apple interdit l'utilisation des frameworks autre que ceux d'Apple sur iPhone, c'est bien parce que ça utilise des librairies dynamiques et que les permettre ouvrirait la porte à  une injection de code non vérifié par Apple... alors qu'avec des libs statiques y'aurait pas ce souci) et donc aussi permettrait d'avoir ces IBPlugins possibles, etc...
Connectez-vous ou Inscrivez-vous pour répondre.