Mise à jour 1/12/2016 : c'est 2016 et je préfère toujours disposer mes interfaces utilisateur dans le code et non dans les storyboards. Cela étant dit, les storyboards ont parcouru un long chemin. J'ai supprimé tous les points de ce post qui ne s'appliquent tout simplement plus en 2016.
Mise à jour du 24/04/2015 : Fait intéressant, Apple n'utilise même pas de storyboards dans son ResearchKit récemment ouvert, comme Peter Steinberger l'a remarqué (sous la sous-rubrique "Interface Builder").
Mise à jour 6/10/2014 : comme prévu, Apple continue d'améliorer les storyboards et Xcode. Certains des points qui s'appliquaient à iOS 7 et inférieurs ne s'appliquent plus à iOS 8 (et sont désormais marqués comme tels). Donc, même si les story-boards ont toujours des défauts, je révise mes conseils de ne pas utiliser pour utiliser sélectivement là où cela a du sens .
Même maintenant que iOS 9 est sorti, je conseillerais contrefaire preuve de prudence lors de la décision d'utiliser des story-boards. Voici mes raisons:
Les storyboards échouent à 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é dans votre storyboard? Il explosera au moment de l'exécution. Vous utilisez une sous-classe UIViewController personnalisée qui n'existe plus dans votre storyboard? Il explosera au moment de l'exécution. Si vous faites de telles choses dans le code, vous les rattraperez tôt, pendant la compilation. Mise à jour : Mon nouvel outil StoryboardLint résout principalement ce problème.
Les storyboards deviennent rapidement déroutants : à mesure que votre projet se développe, votre storyboard devient de plus en plus difficile à naviguer. De plus, si plusieurs contrôleurs de vue ont plusieurs séquences vers plusieurs autres contrôleurs de vue, votre storyboard commence rapidement à ressembler à un bol de spaghetti et vous vous retrouverez à zoomer et dézoomer et à faire défiler partout pour trouver le contrôleur de vue que vous recherchez pour et pour savoir ce qui segue indique où.Mise à jour : ce problème peut être résolu principalement en divisant votre Storyboard en plusieurs Storyboards, comme décrit dans 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 énorme pour votre projet, avoir plusieurs développeurs apportant régulièrement des modifications à ce fichier peut être un casse-tête: les modifications doivent être fusionnées et les conflits résolus. Lorsqu'un conflit se produit, il est difficile de dire comment le résoudre: Xcode génère le fichier XML de la table de montage séquentiel et il n'a pas vraiment été conçu dans le but qu'un humain doive lire, sans parler de le modifier.
Les storyboards rendent les révisions de code difficiles ou presque impossibles : les révisions de code par les pairs sont une bonne chose à faire pour votre équipe. Cependant, lorsque vous apportez des modifications à un storyboard, il est presque impossible de revoir ces modifications avec un développeur différent. Tout ce que vous pouvez tirer est un diff d'un énorme fichier XML. Décrypter ce qui a vraiment changé et si ces changements sont corrects ou s'ils ont cassé quelque chose est vraiment difficile.
Les storyboards entravent la réutilisation du code : dans mes projets iOS, je crée généralement une classe qui contient toutes les couleurs et polices et marges et encarts que j'utilise dans l'application pour lui donner une apparence cohérente: c'est un changement d'une ligne si je dois ajustez l'une de ces valeurs pour l'ensemble de l'application. Si vous définissez de telles valeurs dans le storyboard, vous les dupliquez et devrez 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 un tap sur cette cellule de vue de table pour charger un contrôleur de vue différent. Je dois maintenant ouvrir le storyboard, trouver le bon contrôleur de vue, créer une nouvelle séquence à l'autre contrôleur de vue (que je dois également trouver), donnez un nom à la séquence, souvenez-vous de ce nom (je ne peux pas utiliser de constantes ou de variables dans les storyboards), revenez au code et j'espère que je ne sais pas mal le nom de qui enchaînent pour ma méthode prepareForSegue. Comment j'aimerais pouvoir taper ces 3 lignes de code ici 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 refactorisez votre code, vous devez vous assurer qu'il correspond toujours à ce que votre storyboard attend. Lorsque vous déplacez des éléments dans votre storyboard, vous ne découvrirez au moment de l'exécution que si cela fonctionne toujours avec votre code. J'ai l'impression que je dois synchroniser deux mondes. Il se sent fragile et décourage le changement à mon humble avis.
Les storyboards sont moins flexibles : dans le code, vous pouvez essentiellement faire tout ce que vous voulez! Avec les storyboards, vous êtes limité à un sous-ensemble de ce que vous pouvez faire en code. Surtout quand vous voulez faire des choses avancées avec des animations et des transitions, vous vous retrouverez à "combattre le storyboard" pour le faire fonctionner.
Les storyboards ne vous permettent pas de changer le type de contrôleurs de vue spéciaux : 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 tous les segments. Il est beaucoup plus facile d'effectuer un tel changement de code.
Les storyboards ajoutent deux responsabilités supplémentaires à votre projet : (1) L'outil Editeur de storyboard qui génère le XML du 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 contenir des bogues que vous ne pouvez pas corriger.
Les storyboards ne vous permettent pas d'ajouter une sous-vue à unUIImageView
: qui sait pourquoi.
Les storyboards ne vous permettent pas d'activer la disposition automatique pour des vues individuelles (-Contrôleur) : en cochant / décochant l'option Disposition automatique dans un storyboard, la modification est appliquée à TOUS les contrôleurs du storyboard. (Merci à Sava Mazăre pour ce point!)
Les storyboards ont un risque plus élevé de briser la compatibilité descendante : Xcode change parfois le format de fichier Storyboard et ne garantit en aucune façon que vous pourrez ouvrir les fichiers Storyboard que vous créez aujourd'hui dans quelques années, voire quelques mois. (Merci à thinkadvances pour ce point. Voir le commentaire original )
Les storyboards peuvent rendre votre code plus complexe : lorsque vous créez vos contrôleurs de vue en code, vous pouvez créer des init
méthodes personnalisées , par exemple initWithCustomer:
. De cette façon, vous pouvez rendre l' customer
intérieur de votre contrôleur de vue immuable et vous assurer que ce contrôleur de vue ne peut pas être créé sans customer
objet. Cela n'est pas possible lors de l'utilisation de storyboards. Vous devrez attendre que la prepareForSegue:sender:
méthode soit appelée, puis vous devrez définir la customer
propriété sur votre contrôleur de vue, ce qui signifie que vous devez rendre cette propriété modifiable et vous devrez autoriser la création du contrôleur de vue sans customer
objet . D'après mon expérience, cela peut considérablement compliquer votre code et rendre plus difficile de raisonner sur le flux de votre application. Mise à jour 9/9/16: Chris Dzombak a écrit un bon article sur ce problème .
C'est McDonald's : Pour le dire dans les mots de Steve Jobs à propos de Microsoft: C'est McDonald's (vidéo) !
Ce sont mes raisons pour lesquelles je n'aime vraiment pas travailler avec des storyboards. Certaines de ces raisons s'appliquent également aux XIB. Sur les projets basés sur le storyboard sur lesquels j'ai travaillé, ils m'ont coûté beaucoup plus de temps qu'ils n'en 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 du code, je contrôle beaucoup plus ce qui se passe, il est plus facile de déboguer, il est plus facile de repérer les erreurs dès le début, il est plus facile d'expliquer mes modifications aux autres développeurs et cela est plus facile à prendre en charge iPhone et iPad.
Cependant, je suis d'accord que la présentation de l' ensemble de votre interface utilisateur dans le code pourrait ne pas être une solution universelle pour chaque projet. Si l'interface utilisateur de votre iPad diffère considérablement de l'interface utilisateur de votre iPhone à certains endroits, il peut être judicieux de créer un XIB pour ces zones uniquement.
Un grand nombre des problèmes décrits ci-dessus pourraient être résolus par Apple et j'espère que c'est ce qu'ils feront.
Juste mes deux cents.
Mise à jour : dans Xcode 5, Apple a retiré l'option de créer un projet sans Storyboard. J'ai écrit un petit script qui porte les modèles de Xcode 4 (avec l'option de désactivation de Storyboard) sur Xcode 5: https://github.com/jfahrenkrug/Xcode4templates