Storyboards vs l'ancienne méthode XIB
Je suis nouveau sur iOS et je me demandais lequel était le meilleur à apprendre. J'ai lu certaines des réponses ici et SO, mais certaines personnes disent que l'utilisation de Storyboards sera d'autres disent d'abord apprendre les XIB. Y a-t-il un réel avantage à apprendre les XIB? Les XIB sont-ils plus faciles à comprendre et aideront-ils avec les storyboards?
Il y a des choses que vous pouvez faire avec un storyboard que vous ne pouvez pas faire avec une plume. Un storyboard vous permet de créer des séquences entre les contrôleurs de vue, et il vous permet de concevoir des cellules de vue de tableau en place.
Il y a des choses que vous pouvez faire avec une plume que vous ne pouvez pas faire avec un storyboard. Dans une plume, vous pouvez créer des références à l'espace réservé Propriétaire du fichier. Vous pouvez créer plusieurs vues de niveau supérieur, les modifier et créer des connexions entre elles. Voir cette réponse pour un exemple de la raison pour laquelle vous souhaitez faire cela. Vous pouvez ajouter des espaces réservés aux objets externes (une fonctionnalité rarement utilisée).
Les storyboards ont l'inconvénient de collecter un tas d'objets différents et vaguement liés dans un seul gros fichier. Si vous travaillez sur un projet avec plusieurs développeurs, vous êtes beaucoup plus susceptible de rencontrer des conflits de fusion si vous utilisez un storyboard que si vous utilisez des fichiers xib.
Vous devriez certainement vous renseigner sur les plumes à un moment donné. Que vous souhaitiez commencer par eux ou commencer par un storyboard n'est probablement pas trop important. Trouvez simplement quelques tutoriels que vous aimez et parcourez-les avec le type de fichier (nib ou storyboard) qu'ils utilisent.
Il est avantageux d'apprendre les deux approches.
Outre la valeur historique de l'approche xib, les xib offrent également une modularité. Vous avez peut-être une bibliothèque de code ou souhaitez partager un widget utile que vous avez créé. L'adoption de l'approche xib faciliterait ce partage et cette réutilisation.
L'approche xib vous permet également une plus grande flexibilité en termes de votre propre code. Par exemple, iOS 5 contenait un bogue avec UITableView et la prise en charge de l'accessibilité/VoiceOver qui causerait -dequeueReusableCellWithIdentifier: pour retourner nil bien que cela soit documenté autrement (voir ce billet de blog pour plus de détails). Pour charger dynamiquement les cellules de vue de table à partir de xib, il était possible de contourner le bogue.
Bien que la prise en charge des tableaux et des cellules dans les story-boards soit merveilleuse et offre un support pour ce que la plupart des gens doivent faire dans un tableau, parfois vous devez colorer en dehors des lignes, vous pourriez avoir besoin de beaucoup de cellules différentes, et encore une fois, le chargement dynamique à partir de xibs peut être votre solution.
Un grand avantage de Storyboard est la possibilité de visualiser le flux GUI de votre application entière. Effectuez un zoom arrière et vous pouvez voir comment tout s'interconnecte et s'écoule. Avec xibs, bien que la modularité soit agréable, il est plus difficile d'imaginer comment tout se connecte et s'écoule ensemble. Cela peut être une fonctionnalité utile pour vous-même, ou si vous avez une équipe plus importante avec qui partager, pour permettre aux autres de voir le flux de l'application.
Les deux approches ont de la valeur et il est bon de les connaître pour pouvoir choisir le meilleur outil pour votre tâche à accomplir.
Mise à jour 2014-10-06 - Depuis que j'ai écrit ce qui précède, j'ai été impliqué dans plus de projets. Certains avec xib, certains qui pourraient utiliser des storyboards.
Les storyboards ont beaucoup mûri (nous sommes maintenant sur Xcode 6), et il y en a beaucoup avec eux, c'est tellement sympa. J'adore vraiment que l'on puisse faire beaucoup plus dans un storyboard un peu plus compliqué dans une approche xib. Quelques exemples:
L'une consiste à travailler avec UITableView ou UICollectionView dans quelle mesure vous pouvez travailler avec des cellules prototypes directement dans le storyboard. Beaucoup de configuration agréable et facile, la plupart des tâches lourdes peuvent être dans le storyboard, moins de code. C'est assez sympa. Essayer de le faire dans l'approche xib est certainement faisable, mais il reste beaucoup de travail pour y arriver.
Une autre est la facilité avec laquelle vous pouvez effectuer une transition entre UIViewControllers avec les séquences régulières, puis revenir en arrière avec les séquences de déroulement. Très bien là dans le storyboard, avec un code minimal. C'est tellement pratique.
Mais la seule chose qui tue encore les storyboards pour moi, c'est d'essayer de les utiliser dans des environnements collaboratifs. Ça ne va pas bien fusionner. Et à certains égards, ce n'est même pas si vous travaillez sur une équipe de> 1 personne. Si vous tirez vous-même parti du contrôle de version, utilisez un bon modèle de branchement et de fusion pour votre propre workflow personnel, il peut arriver un moment où des modifications devront être apportées dans une branche qui devra être introduite dans une autre branche, et oh la douleur. Pour moi, c'est ce qui tue les story-boards.
Comme le temps et le travail ont évolué, ce que je trouve pour moi-même, c'est que les storyboards sont parfaits pour le prototypage. La possibilité de faire avancer les choses rapidement est un énorme avantage des storyboards. Il y a beaucoup de vitesse pour les utiliser. Mais la vitesse a un prix. Quand il s'agit d'écrire le "vrai" code pour un projet, je vais juste m'en tenir aux xibs parce que même si cela peut être plus de travail, c'est un itinéraire plus flexible qui fonctionne mieux dans de plus grandes équipes ou au fil du temps.
Mise à jour 2015-04-07 Une autre mise à jour, parce que les projets des derniers mois m'ont forcé à utiliser des storyboards, ce qui a fourni plus d'informations.
Premièrement, certaines choses exigeront une approche ou une autre. Par exemple, apparemment, il y avait des bogues de cas Edge lors du travail avec des classes de taille dans xibs qui n'existaient pas en faisant la même chose dans un storyboard. Donc, si vous êtes affecté par des bugs, cela peut forcer votre main dans un sens ou dans l'autre. Une autre consiste à se rappeler que les storyboards fonctionnent généralement au niveau UIViewController, donc si vous devez faire quelque chose comme avoir un UIView ou un UICollectionViewCell à charger, cela va probablement être mieux servi par un xib.
Deuxièmement, et je ne sais pas pourquoi cela ne m'est pas venu à l'esprit au début, mais il y a rien qui vous oblige à utiliser un storyboard singulier pour l'ensemble de votre projet! Je pense que la nature du storyboard permet aux gens de graviter de cette façon, mais nous devons nous rappeler que rien ne l'exige (à ma connaissance).
Ce que j'ai trouvé fonctionne bien, c'est d'approcher généralement chaque "groupe de vues" par storyboard. Autrement dit, souvent vos ViewControllers ont tendance à être isolés et finissent par être de 1 par storyboard (ou xib). Mais vous pourriez avoir une situation où vous avez deux ViewControllers étroitement liés, et il est logique de les mettre dans le même storyboard, en particulier parce que vous pouvez alors facilement connecter des choses entre eux, comme des séquences.
Le principal avantage de plusieurs storyboards? Travailler en équipe. De cette façon, Fred peut travailler sur son storyboard et Wilma peut travailler sur son storyboard, et il n'y a pas de gros soucis de problèmes de fusion ou de coordination de travail! L'utilisation de plusieurs storyboards (et généralement 1 ViewController par storyboard) a été d'une grande aide dans l'utilisation des storyboards dans une équipe de développement composée de plusieurs personnes.
C'est assez évident Apple veut que nous préférions les storyboards, et je les embrasse de plus en plus ces jours-ci. L'utilisation de plusieurs storyboards, mais toujours en utilisant un xib lorsque cela est nécessaire, fonctionne assez bien maintenant.
Mise à jour 2015-09-21 Maintenant que Apple a publié Xcode 7 , il y a encore plus de raisons d'adopter des storyboards, car Apple fonctionne pour surmonter les lacunes.
L'amélioration la plus importante est références de storyboard, qui vous permet de créer dans un storyboard une référence à un autre storyboard. C'est très simple à faire, et maintenant vous pouvez avoir des séquences de storyboard croisées (à la fois à l'entrée et à la sortie). Je l'ai déjà utilisé plusieurs fois sur un nouveau projet et c'est juste une joie.
Une autre amélioration est que vous pouvez créer des classes UIView autonomes dans un storyboard. Cependant, à ce jour, j'ai eu des résultats mitigés avec. Les cas simples fonctionnent bien, mais pas des trucs plus "compliqués". Par exemple, j'avais un UIViewController avec un UITableView à l'intérieur. Comme il s'agissait d'un simple tableau avec 5 cellules statiques, j'ai simplement instancié les 5 UITableViewCells en tant que partie du ViewController dans le storyboard. Semblait fonctionner, mais au moment de l'exécution, rien ne se chargeait réellement et n'apparaissait; déplacé le UITableViewCells dans un xib, et tout a fonctionné. Je ne sais pas si je faisais quelque chose de mal ou ce que cela pourrait être, alors YMMV. Mais encore, même s'il n'y a que quelques bizarreries, avec le temps je suis sûr Apple les résoudra et ensuite une autre barrière contre les storyboards tombera. Je dirais que si vous avez besoin d'un tel support, vous devriez essayez-le et voyez comment cela se passe pour vous. Il y a une grande promesse.
De plus en plus, les storyboards s'annoncent excellents.