Quand utiliser Storyboard et quand utiliser les XIB

Question

Existe-t-il des directives sur l'utilisation des storyboards dans un projet iOS et l'utilisation des XIB? quels sont les avantages et les inconvénients de chacun et quelles situations conviennent-ils à chacun?

Quoiqu'il en soit, ce n'est pas si propre d'utiliser des séquences de storyboard lorsque des contrôleurs de vue sont poussés par des éléments d'interface utilisateur dynamiques (comme des repères de carte).

henning77 · Accepted Answer

J'ai beaucoup utilisé les fichiers XIB et réalisé deux projets à l'aide de Storyboards. Mes apprentissages sont:

Les Storyboards conviennent aux applications avec un nombre d’écrans faible à moyen et une navigation relativement simple entre les vues.
Si vous avez beaucoup de vues et beaucoup de navigation croisée entre elles, la vue Storyboard devient confuse et trop de travail pour rester propre.
Pour un grand projet avec plusieurs développeurs, je n’utiliserais pas Storyboards car vous n’avez qu’un seul fichier pour votre interface utilisateur et vous ne pouvez pas travailler facilement en parallèle.
Cela pourrait valoir la peine de séparer de grandes applications en plusieurs fichiers de story-board, mais je n'ai pas encore essayé. Cette réponse montre comment faire la transition entre les storyboards.
Vous avez toujours besoin de XIB: dans mes deux projets Storyboard, je devais utiliser des XIB pour les cellules de tableau personnalisées.

Je pense que les scénarimages sont un pas dans la bonne direction pour la mise en œuvre de l'interface utilisateur et j'espère que Apple les étendra dans les futures versions d'iOS. Ils doivent cependant résoudre le problème du "fichier unique", sinon ils ne le feront pas. être attrayant pour les grands projets.

Si je lance une application de petite taille et que je ne peux me permettre que la compatibilité avec iOS5, j'utiliserais Storyboards. Pour tous les autres cas, je m'en tiens aux XIB.

Johannes Fahrenkrug · Answer

Mise à jour du 12/01/2016 : Nous sommes en 2016 et je préfère tout de même disposer mes interfaces utilisateur dans le code et non dans les Storyboards. Cela dit, les scénarimages ont parcouru un long chemin. J'ai supprimé de ce billet tous les points qui ne s'appliquent tout simplement plus en 2016.

Mise à jour du 24/04/2015 : intéressant Apple n'utilise même pas Storyboards dans leur ResearchKit récemment ouvert en tant que source ouverte Peter Steinberger a remarqué (sous le sous-titre "Interface Builder").

Mise à jour du 6/10/2014 : Comme prévu, Apple améliore sans cesse Storyboards et Xcode. Certains des points appliqués sur iOS 7 et les versions antérieures ne s'appliquent plus à iOS 8. (et sont maintenant marqués comme tels). Ainsi, alors que les Storyboards ont toujours des défauts, je modifie mon conseil de don ' t utiliser à utiliser sélectivement là où cela a du sens .

Même maintenant que iOS 9 est sorti, je conseillerais ~~contre~~ faire preuve de prudence avant de décider d'utiliser ou non les Storyboards. Voici mes raisons:

Les storyboards échouent au moment de l'exécution, pas au moment de la compilation : vous avez une faute de frappe dans un nom de séquence ou vous l'avez mal connectée dans votre story-board? Il va exploser au moment de l'exécution. Vous utilisez une sous-classe UIViewController personnalisée qui n'existe plus dans votre storyboard? Il va exploser au moment de l'exécution. Si vous faites de telles choses dans le code, vous les attraperez tôt, au moment de la compilation. Mise à jour : Mon nouvel outil StoryboardLint résout principalement ce problème.
Les storyboards deviennent rapidement déroutants : Au fur et à mesure de la progression de votre projet, votre storyboard devient de plus en plus difficile à naviguer. De plus, si plusieurs contrôleurs de vue ont plusieurs passages dans plusieurs contrôleurs de vue, votre story-board commence rapidement à ressembler à un bol de spaghettis et vous vous retrouvez à faire un zoom avant et arrière et à faire défiler l'écran pour trouver le contrôleur de vue que vous recherchez. pour et pour savoir quels points de segue où. Mise à jour : Ce problème peut être résolu en divisant votre Storyboard en plusieurs Storyboards, comme décrit dans la section cet article de Pilky et cet article de Robert Brown .
Les storyboards rendent le travail en équipe plus difficile : Parce que vous n'avez généralement qu'un seul fichier de storyboard pour votre projet, plusieurs développeurs apportant régulièrement des modifications à ce fichier peuvent être un casse-tête: les changements doivent être fusionnés et les conflits résolus. Quand un conflit se produit, il est difficile de dire comment le résoudre: Xcode génère le fichier XML du scénarimage et il n’a pas été conçu pour que l’être humain lise, et encore moins l’édite.
Les storyboards rendent les révisions de code difficiles ou presque impossibles : les révisions de code par les pairs sont une excellente chose à faire pour votre équipe. Toutefois, lorsque vous apportez des modifications à un storyboard, il est presque impossible de passer en revue ces modifications avec un développeur différent. Tout ce que vous pouvez extraire est un diff d'un fichier XML énorme. Décrypter ce qui a vraiment changé et si ces changements sont corrects ou s'ils cassent quelque chose, c'est vraiment difficile.
Les storyboards empêchent la réutilisation du code : dans mes projets iOS, je crée généralement une classe contenant toutes les couleurs, polices, marges et encarts que j'utilise dans l'application. pour lui donner un aspect cohérent: le changement d’une ligne est unique si je dois ajuster l’une de ces valeurs pour l’application entière. Si vous définissez de telles valeurs dans le storyboard, vous les dupliquez et devez rechercher chaque occurrence lorsque vous souhaitez les modifier. Il y a de fortes chances que vous en manquiez un, car il n'y a pas de recherche et de remplacement dans les storyboards.
Les storyboards nécessitent des changements de contexte constants : je me retrouve à travailler et à naviguer beaucoup plus rapidement dans le code que dans les storyboards. Lorsque votre application utilise des storyboards, vous changez constamment de contexte: "Oh, je veux que la cellule de la vue de la table soit tapotée pour charger un autre contrôleur de vue. Je dois maintenant ouvrir le storyboard, trouver le bon contrôleur de vue, créer un nouveau segment. à l'autre contrôleur de vue (que je dois aussi trouver), donnez un nom à la séquence, souvenez-vous de ce nom (je ne peux pas utiliser de constantes ni de variables dans les storyboards), revenez au code et espérez que le nom ne soit pas mal saisi Ce lien entre ma méthode prepareForSegue. Comme j'aimerais pouvoir simplement taper ces 3 lignes de code juste là où je suis! " Non, ce n'est pas amusant. Basculer entre le code et le storyboard (et entre le clavier et la souris) vieillit rapidement et vous ralentit.
Les storyboards sont difficiles à refactoriser : Lorsque vous refactorez votre code, vous devez vous assurer qu'il correspond toujours à ce que votre storyboard attend. Lorsque vous déplacez des éléments dans votre scénario, vous ne saurez que lors de l'exécution si cela fonctionne toujours avec votre code. Je ressens comme si je devais garder deux mondes synchronisés. Cela me semble fragile et décourage tout changement, à mon humble avis.
Les storyboards sont moins flexibles : En code, vous pouvez faire tout ce que vous voulez! Avec les storyboards, vous êtes limité à un sous-ensemble de ce que vous pouvez faire dans le code. Surtout lorsque vous voulez faire des choses avancées avec des animations et des transitions, vous vous retrouverez "en train de combattre le storyboard" pour le faire fonctionner.
Les story-boards ne vous permettent pas de changer le type de contrôleur de vue spécial : vous voulez changer un UITableViewController en un UICollectionViewController? Ou dans une plaine UIViewController? Pas possible dans un Storyboard. Vous devez supprimer l'ancien contrôleur de vue, en créer un nouveau et reconnecter toutes les étapes. C'est beaucoup plus facile de faire un tel changement de code.
Les storyboards ajoutent deux responsabilités supplémentaires à votre projet : (1) L'outil Storyboard Editor qui génère le XML de storyboard et (2) le composant d'exécution qui analyse le XML. et crée des objets d'interface utilisateur et de contrôleur à partir de celui-ci. Les deux parties peuvent avoir des bogues que vous ne pouvez pas corriger.
Les story-boards ne vous permettent pas d'ajouter une sous-vue à un UIImageView : Qui sait pourquoi.
Les Storyboards ne vous permettent pas d'activer la présentation automatique pour une vue individuelle (Contrôleur) s : en cochant/décochant l'option Disposition automatique dans un Storyboard, le Le changement est appliqué à TOUS les contrôleurs du Storyboard. (Merci à Sava Mazăre pour ce point!)
Les storyboards ont un risque plus élevé de rupture de la compatibilité ascendante : Xcode change parfois le format du fichier Storyboard et ne garantit en aucune manière que vous pourrez l'ouvrir. Fichiers de scénarimage que vous créez aujourd'hui dans quelques années, voire quelques mois. (Merci à thinkadvances pour ce point. Voir le commentaire d'origine )
Les storyboards peuvent rendre votre code plus complexe : lorsque vous créez vos contrôleurs de vue dans le code, vous pouvez créer des méthodes personnalisées init, par exemple initWithCustomer:. De cette façon, vous pouvez rendre le customer de votre contrôleur de vue immuable et vous assurer que ce dernier ne peut pas être créé sans un objet customer. Ce n'est pas possible lors de l'utilisation de Storyboards. Vous devrez attendre le prepareForSegue:sender: méthode à appeler et vous devrez ensuite définir la propriété customer sur votre contrôleur de vue, ce qui signifie que vous devez rendre cette propriété mutable et permettre à ce dernier d'être créé sans customer objet. D'après mon expérience, cela peut grandement compliquer votre code et compliquer la tâche de raisonner sur le flux de votre application. Mise à jour du 9/09/16 : Chris Dzombak a écrit un excellent article sur ce problème .
C'est McDonald's : Pour le dire dans les mots de Steve Jobs à propos de Microsoft: C'est McDonald (vidéo) !

Ce sont les raisons pour lesquelles je n'aime vraiment pas travailler avec des scénarimages. Certaines de ces raisons s'appliquent également aux XIB. Sur les projets de scénarimage sur lesquels j'ai travaillé, ils m'ont coûté beaucoup plus de temps que ce qu'ils ont économisé et ils ont rendu les choses plus compliquées plutôt que plus faciles.

Lorsque je crée mon interface utilisateur et mon flux d’application dans le code, je contrôle beaucoup mieux ce qui se passe, il est plus facile de déboguer, il est plus facile de repérer les erreurs tôt, il est plus facile d’expliquer mes modifications à d’autres développeurs. est plus facile à supporter iPhone et iPad.

Cependant, je conviens que la mise en page de toute votre interface utilisateur dans le code peut ne pas être une solution unique pour chaque projet. Si l'interface utilisateur de votre iPad diffère considérablement de celle de votre iPhone à certains endroits, il peut être judicieux de créer un fichier XIB pour ces zones uniquement.

Beaucoup des problèmes décrits ci-dessus pourraient être résolus par Apple) et j'espère que c'est ce qu'ils vont faire.

Juste mes deux cents.

Mise à jour : Dans Xcode 5, Apple a supprimé l'option permettant de créer un projet sans Storyboard. J'ai écrit un petit script qui porte les modèles de Xcode 4 (avec l'option Storyboard-opt-out) sur Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

Bot · Answer

Les storyboards ont été créés pour aider les développeurs à visualiser leur application et son déroulement. C'est un peu comme avoir un groupe de xib mais dans un seul fichier.

Il existe une question similaire à celle-ci: Quelle est la différence entre un fichier .xib et un .storyboard? .

Vous pouvez également créer des transitions personnalisées via un code qui changera de manière dynamique si nécessaire, comme vous pouvez le faire avec .xibs.

AVANTAGES:

Vous pouvez simuler le flux d'une application sans écrire beaucoup, voire aucun code.
Il est beaucoup plus facile de voir vos transitions entre les écrans et le flux de vos applications.
Peut également utiliser .xibs si nécessaire avec des storyboards.

LES INCONVÉNIENTS:

Ne fonctionne qu'avec iOS 5+. Ne fonctionne pas avec iOS4.
Peut être encombré facilement si vous avez une application très intensive.

Il n'y a pas vraiment de bon/mauvais quand utiliser l'un ou l'autre, c'est juste une question de préférence et quelles versions iOS vous voulez utiliser.

thgc · Answer

Je vais juste dire 4 raisons simples pourquoi devriez-vous utiliser des storyboards, en particulier dans un environnement productif où vous devez travailler dans une équipe de propriétaires de produits, chefs de produits, concepteurs UX, etc.

Apple a grandement amélioré son utilisation de Storyboards. Et ils vous encouragent à travailler avec eux. Ce qui signifie qu'ils ne le feront pas interrompent vos projets existants avec des mises à jour, ils veilleront à ce que les storyboards soient une preuve pour les versions futures de XCode/iOS.
Résultats plus visibles dans moins de temps pour les propriétaires et responsables de produits, même pendant la phase de création. Vous pouvez même utiliser le storyboard lui-même comme diagramme d'écran et en discuter lors de réunions.
Même après qu'une application soit terminée (et c'est généralement là que commence son cycle de vie) - dans l'avenir, ce sera plus rapide et plus facile d'appliquer de petits ajustements. Et ceux-ci pourraient très bien changer plusieurs aspects de votre mise en page en même temps, ce que vous voudrez probablement voir de manière WYSIWYG. L'alternative serait d'écrire à la main les modifications de l'interface utilisateur dans le code et de basculer entre le IDE et le simulateur pour le tester, chaque fois en attente de compilation et de construction.
On peut apprendre aux non-développeurs à configurer des dispositions dans les story-boards et à créer les points d'ancrage nécessaires aux développeurs (IBOutlets et IBActions). C'est un très gros avantage, car cela permet aux développeurs de se concentrer sur la logique et que les concepteurs UX appliquent leurs modifications de manière visuelle, sans avoir à écrire de code.

Je ne rédigerai aucun CONS, car Johannes a déjà énuméré toutes les solutions viables dans sa réponse. Et la plupart d'entre eux ne sont définitivement pas viables, surtout pas avec les améliorations majeures de XCode6.

Stefano Mondino · Answer

Je ne pense pas qu'il y ait une bonne réponse à votre question, c'est juste une question d'expérience personnelle et de ce avec quoi vous vous sentez plus à l'aise.

À mon avis, les scénarimages sont une bonne chose. C’est vrai, il est très difficile de savoir pourquoi votre application plante cruellement au moment de l’exécution, mais après un certain temps et une certaine expérience, vous réaliserez qu’elle est toujours liée au fait qu’il manque quelque part IBOutlet et que vous pourrez facilement le réparer.

Le seul vrai problème est de travailler en équipe sous contrôle de version avec des story-boards. Aux premiers stades de développement, cela pourrait être un vrai désastre. Mais après cette première étape, les mises à jour de l'interface utilisateur qui modifient complètement le storyboard sont très rares et, dans la plupart des cas, vous vous retrouvez avec des conflits dans les toutes dernières parties du xml, qui sont des références de séquence qui se corrigent généralement d'elles-mêmes lorsque vous rouvrez le storyboard. . Dans notre travail d’équipe, nous avons préféré traiter cela plutôt que de lourds contrôleurs de vue avec des tonnes de code de vue.

J'ai lu de nombreux commentaires à nouveau sur la mise en page automatique. Avec XCode5, cela s’est vraiment amélioré. C’est vraiment bien, même pour l’autorotation de présentations. Dans certains cas, vous devrez faire quelque chose dans le code, mais vous pouvez simplement indiquer la contrainte que vous devez éditer et, à ce stade, faire ce dont vous avez besoin dans votre code. Même les animer.

Je pense également que la plupart des gens qui n'aiment pas les story-boards n'ont pas vraiment essayé de comprendre le pouvoir d'un segment manuel personnalisé, où vous pouvez totalement personnaliser (dans un seul fichier) la façon dont vous passez d'un mode à un autre et aussi (avec astuces), vous pouvez même réutiliser un contrôleur de vue précédemment chargé en mettant à jour le contenu de la vue au lieu de tout recharger. À la fin, vous pouvez vraiment faire les mêmes choses que dans le code, mais je pense que vous avez une meilleure séparation des problèmes entre les scénarimages, mais je conviens que dans beaucoup de choses, ils manquent de fonctionnalités (polices, image de fond, ecc ... ).

Krishna Vedula · Answer

J'ai travaillé sur un projet de taille raisonnable (> 20 scènes dans le langage du storyboard), et j'ai rencontré de nombreuses limitations et je dois consulter à plusieurs reprises la documentation et les recherches sur Google pour faire des choses.

L'interface utilisateur est dans un seul fichier. Même si vous créez plusieurs story-boards, vous avez toujours plusieurs scènes/écrans dans chaque story-board. C'est un problème dans les équipes de taille moyenne.
Deuxièmement, ils ne fonctionnent pas bien avec les contrôleurs de conteneur personnalisés qui intègrent d'autres contrôleurs de conteneur, etc. Nous utilisons MFSlideMenu dans une application à onglets et la scène a une table. C'est presque impossible à faire avec un storyboard. Après avoir passé des jours, j'ai eu recours à la méthode XIB où le contrôle est total.
Le IDE ne permet pas de sélectionner des contrôles en état de zoom arrière. Ainsi, dans un grand projet, le zoom arrière sert principalement à obtenir une vue de haut niveau et rien de plus.

J'utiliserais des storyboards pour des applications plus petites avec des équipes de petite taille et utiliserais l'approche XIB pour des équipes/projets de moyenne à grande taille.

Hemang · Answer

Je n'utilise ni StoryBoard ni XIB dans l'application, mais je crée tout par programme.

∆ Avantages:

√ Vous pouvez créer n'importe quel type complexe d'interface utilisateur ou d'animation de transition pour UIView '.

√ Supporte toutes les versions iOS. Pas besoin de vous soucier de <iOS 5.

√ * Votre application prend en charge tous les appareils iPhone/iPod/iPad dans votre code.

√ Vous êtes toujours à jour car vous connaissez le code qui fonctionnera toujours.

√ * Fonctionnera sur tout (nouveau) appareil lancé - Pas besoin de changer de code.

√ Tout est à vous. À un certain endroit, vous voulez changer quelque chose - Pas besoin de regarder dans le storyboard ou xib. Il suffit de chercher dans une classe particulière.

√ Dernier point mais non la liste - Vous n’oublierez jamais cela, comment tout gérer par programme. C'est la meilleure chose car vous connaissez un contrôle très profond alors n'importe qui.

_{Je n'ai jamais trouvé de problème en n'utilisant ni SB ni XIB, cela me convient parfaitement.}

_{* si vous avez défini les cadres d'objet UIKit en fonction de la taille de l'écran.}

_{P.S. Si vous n'avez toujours pas fait cela - vous pouvez avoir des difficultés (ou vous sentir ennuyeux) mais une fois que vous vous êtes familiarisé avec cela - c'est vraiment une Candy pour vous.}

onmyway133 · Answer

Si vous êtes sur le point de vous intéresser aux performances du scénarimage, regardez WWDC 2015 Session 407

Temps de construction

Lorsque le constructeur d'interface compile un storyboard, il effectue deux tâches: il tente d'optimiser les performances de votre application et, deuxièmement, il réduit également le nombre de fichiers nib créés.

Si j'ai un contrôleur de vue avec une vue et un groupe de sous-vues, un constructeur d'interface, le moment de la construction va créer un fichier nib pour le contrôleur de vue et créer un fichier nib pour la vue.

En disposant de fichiers nib distincts pour le contrôleur de vue et la vue, cela signifie que la hiérarchie de la vue peut être chargée à la demande.

Durée d'exécution

Lorsque vous allouez une instance de storyboard à l'aide de l'API Storyboard, à l'origine, tout ce que vous allouez à la mémoire est l'instance de storyboard de l'interface utilisateur elle-même.

Pas de contrôleur de vue pas de vue pour le moment.

Lorsque vous instanciez votre contrôleur de vue initial, il charge le nib pour ce contrôleur de vue initial mais, encore une fois, aucune hiérarchie de vue n'a encore été chargée jusqu'à ce que quelqu'un le demande réellement.

Bibin Jaimon · Answer

Si vous souhaitez réutiliser une interface utilisateur dans plusieurs contrôleurs de vue, vous devez utiliser des XIB.