Pourquoi est-ce que j'ai l'impression qu'Interface Builder me gêne?

Question

Je suis très novice dans Cocoa for MacOSX, mais je ne peux pas m'empêcher de penser que je me bats constamment contre Interface Builder.

Ma situation actuelle est que je construis une application qui comportera plusieurs contrôles et vues personnalisés. J'ai commencé à créer l'application dans Interface Builder car il était très facile au début de faire glisser des objets et de les placer aux emplacements appropriés avec les couleurs et les règles de redimensionnement automatique correctes. Cependant, le moment est venu de commencer à créer mes commandes et mes vues personnalisées - ce que je ne peux pas bien représenter dans Interface Builder sans passer par le travail de création d'un IBPlugin! La seule autre option que je connaisse consiste à créer un document Interface Builder qui inclut un ensemble de " vues personnalisées " partout avec seulement leur classe a changé. Il semble soudain inutile de se préoccuper de l’IB, en particulier du fait que ces commandes et ces vues auront des propriétés telles que la couleur qui doivent être définies, tout comme les autres vues et commandes déjà présentes dans le document de l’IB. Alors maintenant, les propriétés de visualisation sont définies à deux endroits déconnectés et semblent contrer l’un des avantages potentiels de IB, ce qui facilite relativement l’ajustement de l’UI de l’application sans fouiller dans le code.

Je suis également confronté à une situation dans laquelle quelques contrôles modifient les propriétés (telles que les couleurs) en fonction des données ou des sélections en cours. Alors maintenant, j'ai les couleurs par défaut initiales du contrôle spécifié dans Interface Builder, mais je dois spécifier les couleurs basées sur les données dans le code? Une fois encore, Interface Builder semble m'obliger à partager certains paramètres de présentation entre son monde et le code. Je suppose qu’il est possible de résoudre un peu ce problème avec un plugin complexe qui connaît mes données, mes états ou quoi que ce soit, mais il semblerait que j’aurais besoin de conserver une tonne de code de support qui existe pour que l’expérience d’Interface Builder reste correcte. "

Un autre aspect que je vois souvent mentionné est la facilité avec laquelle IB vous permet de définir des liaisons entre des composants. "Vous pouvez le faire sans écrire de code!" Encore une fois, il se peut que je manque quelque chose, mais la liaison d’une propriété à une autre correspond à une seule ligne de code, pour autant que je sache. Définir quelques propriétés dans une boîte dans IB est-il vraiment préférable à l'écriture d'une seule ligne de code? Et pourquoi est-il préférable de mettre ce qui revient à la logique d'application dans la spécification de la couche de présentation?

Comme je l’ai dit à l’ouverture, je suis plutôt novice dans ce jeu Cocoa, mais j’ai le sentiment qu’il me manque quelque chose de très important sur la façon d’utiliser Interface Builder, ou bien il est conçu principalement pour des applications de démonstration triviales avec une grande "wow" facteur.

Answer 1

Je trouve qu'Interface Builder est excellent pour obtenir la présentation générique d'une application. C'est aussi merveilleux pour les choses comme les reliures (sur le Mac). Cependant, il est impossible de créer une bibliothèque Delicious à l'aide d'Interface Builder. Plus votre interface est complexe, plus vous aurez de code à écrire.

Answer 2

Interface Builder peut prendre un peu de temps pour s'y habituer. Mais, comme cela a été dit précédemment, plus vous l'utilisez, mieux c'est. Bien sûr, les vues personnalisées peuvent être réalisées en code, mais IB est un standard pour une raison. Les applications Mac sont soumises à certaines normes de qualité de l'interface utilisateur par la communauté, qui sont beaucoup plus élevées que les normes de l'interface utilisateur pour d'autres plates-formes. IB facilite beaucoup la conformité à ces normes que de tout faire dans le code, sans référence visuelle.

Et vous n'avez pas à tout faire dans le code pour que votre interface utilisateur soit sous contrôle de version. Tous mes projets Cocoa résident dans leur propre référentiel git avec les fichiers nib / xib inclus.

Alors laissez une chance à IB. Cela devient plus facile à mesure que vous l'utilisez.

Answer 3

Jeff LaMarche (de la renommée du développement iPhone) a écrit un excellent article sur la raison pour laquelle IB est un bon choix à utiliser, même si cela ne semble pas être la bonne voie une fois que vous avez dépassé les didacticiels de base. J'avais abandonné IB pour des raisons similaires aux vôtres, mais l'article m'a inspiré pour continuer à travailler avec lui. Il s'avère vraiment être la bonne solution, même si cela va à l'encontre de la tendance geek à ne pas autoriser des abstractions trop perméables.

Answer 4

Mon premier programme iPhone, disponible à la vente, ainsi que mon deuxième programme en cours de développement, n’utilise pas Interface Builder. J'aime avoir tout cela dans le code pour pouvoir comprendre ce qui se passe et pour pouvoir utiliser le suivi de version pour suivre tous les changements.

Pour autant que je sache, il s'agit d'une question de préférence. Il existe des livres sur le cacao qui utilisent les deux styles (IB et no IB).