Concevoir l’interface iPhone en nib ou en code?

Question

Cela fait un moment que je réfléchis à cette question ...

D'une part, Interface Builder offre un moyen très simple de concevoir l'interface et de câbler les éléments avec des objets dans le code.

D'autre part, dans les grands projets, Interface Builder devient une tâche fastidieuse à gérer.

Toute suggestion serait grandement appréciée.

Answer 1

Une fois, j’étais très opposé à l’utilisation d’Interface Builder dans mes propres projets. Cela était dû à un certain nombre de facteurs. J'ai commencé à travailler avec les outils Xcode lorsque le SDK pour iPhone était de nouveau en version bêta (vers mars 2008), et comme je ne venais pas d'un environnement Mac Cocoa, je ne connaissais pas bien l'utiliser. Ce n’était pas le principal facteur dans mon rejet initial de IB pour le développement d’iPhone, cependant - Interface Builder pour le développement d’iPhone pendant la version bêta initiale du SDK pour iPhone était vraiment nul et l’utilisation était pénible.

Cependant, l’histoire est bien différente avec le SDK pour iPhone actuel. Bien qu'il existe encore certainement quelques bugs ennuyeux de l'IB, j'ai effectué une analyse presque complète de 180 & # 730; avec mon attitude envers l'utilisation d'Interface Builder. Le plus souvent, c'est une bonne idée d'utiliser Interface Builder dans vos projets, que j'ai trouvé. C'est un excellent outil maintenant, et vous devriez en profiter.

Maintenant, ne vous méprenez pas, je suis toujours fermement dans le camp qui croit que vous devriez pouvoir mettre en œuvre tout ce que vous faites dans Interface Builder en utilisant du code seul et je pense pouvoir faire est inestimable. N'utilisez pas Interface Builder comme une béquille - vous ne vous ferez que du mal (et votre productivité ou la qualité de vos produits) à la fin. Bien que les fonctions de glissement-déposer d'IB servent à 90% de ce que vous devrez faire, lorsque vous avez quelque chose de personnalisé à implémenter qui ne peut être effectué qu'en code, vous souhaiterez soit avoir suivi, soit être reconnaissant. pour suivre ce conseil. J'ai eu la chance de détester l'IB assez longtemps pour m'apprendre à tout faire en code, puis de lui appliquer ce savoir.

Modifier:
Pour remédier au manque de capacité de réutilisation (perçue ou réelle) des NIB par rapport au code ... vous n'allez probablement pas implémenter quelque chose censé être fortement réutilisé dans Interface Builder. Vous ne pouvez pas vraiment créer un contrôle personnalisé ou une vue dans IB, c'est donc exclu et, dans la plupart des cas, vous allez implémenter une sous-classe de contrôleur de vue conçue pour répondre à un objectif spécifique. Vous devez bien entendu toujours vous efforcer de rendre votre code et les ressources associées aussi réutilisables que possible. Cela pourrait inclure des considérations de conception pour vous assurer de ne pas dupliquer inutilement des sous-classes de contrôleur de vue très similaires.

Answer 2

L'utilisation de générateurs vous libère du code que vous auriez sinon besoin de maintenir et moins vous aurez besoin de maintenir, mieux ce sera.

Les dispositions conçues par IB nécessitent un peu de maintenance, mais il s'agit d'un outil standard doté de sa propre documentation et de son propre support en ligne (forums, listes, etc.). Si quelqu'un d'autre a besoin de plonger dans votre code, vous pouvez pratiquement garantir qu'il possède une expérience avec IB, mais pas nécessairement votre style de création de disposition particulier.

Answer 3

Cela dépend de vos préférences.

Je préfère l'écrire dans le code.

1. Je peux réutiliser le code.
2. L'utilisation d'un fichier XIB / NIB enfreint généralement la règle de définition unique (si vous effectuez une personnalisation).
3. La maintenance XIB / NIB est souvent plus fastidieuse et sujette aux erreurs (ODR). Je n'aime vraiment pas conserver les styles de boutons (exemple) pour chaque bouton.
4. les références circulaires sont plus probables.
5. Les instances code / objets / ib sont souvent moins réutilisables / modulaires. Bien que je sois du genre à éviter un objet d'interface utilisateur capable de tout faire.
6. Les ordres d'initialisation différés / ambigus créent un état plutôt effrayant pour les clients. Ils ne doivent jamais présumer qu'un objet est prêt à être utilisé ou entièrement initialisé (à moins que vous ne préfériez conserver ces vérifications, ce qui est un bon moyen de perdre du temps).
7. Si les performances sont importantes, devinez lequel est le plus rapide?
8. Gestion des ressources contre l'éditeur de liens ... sérieusement, j'ai écrit des sous-programmes et des tests pour vérifier l'existence de nibs dans le bundle.

IB est idéal pour le prototypage et les fonctionnalités et l'apparence des objets (je ne suis pas un concepteur graphique), bien que je pense qu'il est plus facile de l'écrire dans le code une fois que le prototype existe si vous en avez un. intention de le conserver ou de le réutiliser.

Ma recommandation: rédigez des bibliothèques de code hautement réutilisables et stables, et utilisez IB principalement pour le prototypage et les opérations uniques.

Réponses:

  

Sbrocket: Je suis curieux de savoir pourquoi vous affirmez que les références circulaires sont plus susceptibles de se produire à la suite de l'utilisation de NIB.

Bonjour Sbrocket: Je vais commencer par dire que j'ai utilisé Interface Builder depuis l'époque de Project Builder (prédécesseur de Xcode).

Manque de propriété structurée, d'identité et d'initialisation fiables. Je ne veux pas que ivars soient des connexions IB car cela rend difficile l'utilisation de nombreuses classes au-delà du "contexte actuel". En d'autres termes, cela lie le code à la ressource (plus souvent qu'idéalement). Étant donné que vous ne pouvez pas définir l'ordre d'initialisation ni définir les initialiseurs ou les arguments d'initialisation supplémentaires dans IB, vous devez alors informer les objets les uns des autres, en créant des dépendances circulaires et des références.

  

Sbrocket: ou pourquoi l’initialisation lente (en supposant que c’est ce dont vous parlez) est si effrayante quand il est relativement facile (ou même automatique dans de nombreux cas) de s’assurer que l’objet est initialisé et connecté.

Re: effrayant Je ne parlais pas d'initialisation paresseuse. Je parlais de l'ordre d'initialisation différé et ambigu.

L'initialisation de nib est semi-ordonnée. La commande / procédure réelle peut varier, et ceci ne peut pas être utilisé de manière fiable dans des programmes introspectifs réutilisables ... encore une fois, vous finiriez par écrire trop de code fragile, impossible à réutiliser, ne pouvant jamais être sûr de se comporter de manière prévisible, toujours valider l'état (encore une autre entrée pour la dépendance circulaire). Si ce n’est pas une implémentation ponctuelle, pourquoi s’embêter avec les complications?

Cette approche de la programmation est chaotique et les implémentations doivent (à leur tour) être prêtes à gérer n'importe quoi à tout moment. C’est une chose de se prémunir contre les collisions, mais d’écrire du code de niveau production, défensif dans ce contexte… impossible.

Il est beaucoup plus facile d’écrire un programme cohérent dont l’initialisation détermine la validité en contexte, et dont les implémentations peuvent alors savoir (si elle est initialisée) que l’objet est généralement préparé pour être utilisé. La complexité des cas spéciaux est réduite au minimum. Beaucoup de ces conceptions s'effondrent à mesure que la complexité du programme augmente, tandis que les rédacteurs de bibliothèques ajoutent des couches de «mesures de protection» juste pour garder les engrenages en mouvement - le threading est une excellente entrée pour de tels heisenbugs. Les ambiguïtés inutiles ne sont pas les bienvenues dans le code de niveau de production réutilisable; les humains ne devraient pas avoir à recouper tous les cas spéciaux d'un programme, et les complexités relatives au comportement défini et aux cas particuliers ne font que s'étendre ou sont ignorées (en supposant qu'elles soient correctement suivies et documentées, ce qui représente davantage d'effort combiné que d'écrire correctement dès le départ ). Je pense que nous pouvons tous convenir que les interfaces et les implémentations onéreuses devraient être évitées.

  

Sbrocket: Je serais également intéressé de voir des chiffres précis montrant que le chargement de NIB est plus lent - bien sûr, cela semblerait logique au premier abord, mais nous sommes toujours de très mauvais prédicteurs des goulots d'étranglement des performances sans certains essais difficiles.

Je n'ai jamais dit (explicitement) qu'il était plus lent:)

D'accord, en réalité, la désarchivage de la NIB était (pour moi) un processus étonnamment lent, bien que nos idées sur la lenteur et la désarchivage puissent varier considérablement.

Exemple: j'avais une application basée sur les documents et le chargement de la pointe était plusieurs fois plus lent que celui du document, lorsque la taille des documents était plusieurs fois supérieure à celle de la pointe. Déplacer l'implémentation vers le code a rendu le processus beaucoup plus rapide. Une fois le code défini et le contrôle de l'ordre d'initialisation terminé, j'ai supprimé plusieurs complexités du multithreading (points de contrôle, verrous, entrées de conditions de concurrence, etc.), ce qui accélérait encore le chargement des documents.

Maintenant que vous avez une réponse explicite, je vous rappelle que vous disposez de tous les outils dont vous avez besoin pour mesurer les performances.

N'oubliez pas que l'analyse des performances et les améliorations sont apprises .

Answer 4

Le constructeur d'interface est idéal pour un certain niveau de complexité. Pour les choses plus ou moins complexes, je préférerais le faire en code.

Si vous avez une interface qui ne sera pas utilisée de plusieurs façons, qui comporte plusieurs éléments, mais pas beaucoup, et qui ne nécessite aucune présentation complexe, alors IB est génial.

À long terme, je n’utilise presque jamais IB. C’est autant la nature des projets sur lesquels je travaille que mes préférences personnelles. Il y a certainement des interfaces pour lesquelles je me dirigerais directement vers IB, mais je n'ai pas eu besoin d'en créer une depuis un moment.