Xcode: Éviter Interface Builder une bonne ou une mauvaise idée?

Mon expérience avec le développement et les avantages et les inconvénients de IB:

Commencez par laisser IB supprimer la complexité là où elle obscurcit l'apprentissage des concepts de base exprimables uniquement dans le code. Il y a beaucoup à dire pour le fait que IB dissimule des connections qui seraient autrement évidentes (et donc faciles à apprendre et à déboguer), mais généralement, il fait un bon travail de suppression de code étranger.

Il est utile d'en apprendre le plus possible sur la façon dont fonctionnent les hiérarchies de vue et les éléments de l'interface user sans avoir à utiliser IB une fois que vous vous sentez plus à l'aise avec Objective-C et le cacao. Je ne pense pas qu'il y ait quelque chose que vous ne pouvez pas faire dans IB mais il y a certainement beaucoup de choses qui sont plus flexibles et plus puissantes quand on les gère par programme.

À partir de ce moment, une fois que vous avez compris les fonctions sous-jacentes, vous pouvez revenir à IB et vous laisser gagner du time et de l'énergie que vous utiliseriez pour définir de nombreuses propriétés des éléments UIKit.

Pour répondre à vos préoccupations à propos de manquer. Je dirais qu'il faut prendre le time d'apprendre à la fois les Storyboards (une méthode collective de planification de l'interface user) et les files XIB / NIB (où un seul file d'interface user est associé à un seul controller de vue). Les storyboards sont plus récents et less bien compris par beaucoup de gens, y compris moi! Les NIB et les XIB sont plus puissants / less évidents mais restnt très importants car certaines choses ne fonctionnent pas très bien dans les Storyboards.

En termes de travail avec les autres, IB peut faire mal au contrôle de version car les files Plist / Backing de IB ne sont pas toujours sympas avec la fusion etc … Cependant, je dirais que si vous venez d'un point d'apprentissage code d'abord puis se déplaçant pour apprendre IB sera plus facile alors l'inverse. La règle la plus importante du travail en équipe est de ne pas avoir peur de poser des questions. Vos compétences en code aideront quelqu'un d'autre qui peut à son tour vous aider avec IB.

J'espère que cela pourra aider. Il y a de super tutoriels sur le site de Ray Wendlerlich, google lui.

Le sujet a déjà été bien couvert. Laissez-moi jeter dans mon sharepoint vue succinctement.

Dans les premiers jours du développement d'iOS, Interface Builder était très bogué et l'éviter complètement était un moyen légitime d'assurer less de bugs (et donc de gagner du time).

La même chose n'est plus vraie. Si vous faites tout à partir du code, vous passerez 3 fois plus de time à créer des interfaces user.

Les storyboards sont également un moyen facile d'expliquer le stream d'écran à d'autres.

Y a-t-il un moment où vous devez absolument utiliser Interface Builder? Y at-il quelque chose qui est impossible à réaliser sans cela? (Je sais que l'inverse est vrai.)

Pour autant que je sache, non.

Y at-il des pratiques que je peux utiliser pour m'aider à ne pas manquer les avantages qu'offre Tal Bereznitskey pour utiliser Interface Builder. Je pense spécifiquement aux points qu'il soulève sur le fait qu'il est plus facile à maintenir et plus facile de prototyper et de changer des choses.

Interface Builder a plusieurs avantages et inconvénients. Laissez-moi énumérer certains d'entre eux:

Avantage # 1: il est plus facile de find rapidement des interfaces moyennement complexes.

Avantage # 2: comme il est profondément embedded avec les outils de développement, vous pouvez être presque certain qu'il maintient la cohérence dans l'interface user de votre application. Par exemple, j'ai ressenti cela quand j'ai construit un controller de vue de table, j'ai manqué quelques légers détails dans le code, et il y avait un espace vide étranger au-dessus de la vue de la table. Cette erreur ne s'est pas produite lorsque j'ai utilisé IB.

Inconvénient # 1: Dans le cas de bibliothèques et d'applications opensource, les développeurs sans IB (par exemple, ceux qui utilisent une string d'outils non officielle et / ou ceux qui développent des appareils jailbreakés avec Theos par exemple) ne pourront pas utiliser pleinement votre code.

Inconvénient n ° 2: si vous êtes un débutant avec le développement iOS, vous pouvez facilement devenir «paresseux» et ne pas apprendre comment créer une interface user complète entièrement à partir du code. C'est une compétence très utile lors de la composition d'interfaces hautement dynamics avec beaucoup de petits détails.

Ignorer complètement l'Interface Builder me désavantage de toute façon pour build des applications dans le futur. Les applications complexes sur lesquelles j'espère travailler dans le futur seront-elles beaucoup plus difficiles à développer si je me contente d'écrire du code?

Le seul inconvénient que je peux voir est qu'au début, l'écriture du code à partir de zéro peut être plus lente que glisser-déposer les widgets, mais même cette différence devient faible avec le time.

Je suis actuellement en train de créer des Apps par moi-même, mais quand je commencerai à travailler avec d'autres développeurs, serai-je considérablement désavantagé car je n'ai jamais appris à utiliser Interface Builder ou serai-je capable d'écrire du code?

En général, être capable d'utiliser IB est une compétence attendue quand on travaille dans un groupe, mais mon expérience personnelle confirme que ce n'est pas un gros problème si vous ne pouvez pas / ne l'utilisez pas. L'été dernier, j'ai travaillé pour une entreprise sur une application professionnelle de services bancaires mobiles. Je ne suis pas très expérimenté avec IB et je ne l'utilise presque jamais, pourtant j'étais parmi les développeurs les plus productifs.