web-dev-qa-db-fra.com

Quels sont les avantages de l'utilisation de Storyboards au lieu de fichiers xib dans la programmation iOS?

Quelles sont les principales différences entre l'utilisation de Storyboards et les fichiers xib.

Plus précisément, quels sont les avantages ou inconvénients de l'utilisation d'un Storyboard?

Malheureusement, malgré de nombreuses recherches, tout ce que j'ai pu trouver sur les storyboards sont de simples didacticiels qui vous montrent comment configurer un storyboard, au lieu d'informations concrètes expliquant ce qu'ils sont.

iosxcodestoryboardinterface-builderxib
70
Steve

Un Storyboard c'est:

  • Un conteneur pour toutes vos scènes (View Controllers, Nav Controllers, TabBar Controllers, etc)
  • Un gestionnaire de connexions et de transitions entre ces scènes (elles s'appellent Segues)
  • Une belle façon de gérer la façon dont les différents contrôleurs se parlent
  • Les storyboards vous donnent un aperçu complet du flux de votre application que vous ne pouvez jamais obtenir à partir de fichiers de nib individuels flottant.
  • Un réducteur de tout le "fouillis" qui se produit lorsque vous avez plusieurs contrôleurs chacun avec son propre fichier nib.

J'utilise Storyboards depuis un certain temps maintenant et le SEUL inconvénient est que vous ne pouvez pas cibler iOS 4 ou une version antérieure. Les storyboards ne fonctionnent que sur les appareils exécutant iOS 5 ou supérieur. En dehors de cela, les avantages sont nombreux et les inconvénients sont inexistants à l'OMI.

Le meilleur tutoriel que j'ai vu est Ray Wenderlich's

De plus, si vous êtes membre du programme pour développeurs Apple, consultez la dernière session de la WWDC sur Storyboards (iTunesU)), c'est génial.

Un autre grand (également sur iTunesU) est le dernier cours de programmation d'application Stanford iOS.

83
LJ Wilson

Il n'y a pas que les côtés pro du storyboard, également les inconvénients - simplement parce que vous avez demandé votre avis:

  • ce n'est pas facile de travailler avec des SB dans une équipe, car un seul participant peut travailler sur le SB à la fois (car il s'agit d'un seul fichier).

- Ce qui suit n'est pas vrai: - si vous avez besoin de faire des choses que SB n'offre pas, il n'est pas assez facile de mélanger SB avec des vues créées par programmation (enfin, c'est possible cependant)

La règle générale semble être la suivante: plus vous vous attendez à ce que votre projet devienne complexe, plus vous ferez mieux de ne pas opter pour SB.

EDIT: - un autre inconvénient de SB: contourner tous les bugs ennuyeux de XCode concernant SB. Par exemple. avoir à vider fréquemment le dossier DerivedData en raison de plusieurs incohérences. Parfois, les fichiers de storyboard ou le lien vers ceux-ci sont corrompus. Ensuite, vous pourriez avoir la joie de rechercher le problème. Jetez un oeil à cela fil pour avoir l'idée

EDIT 2 (mars 2013): pendant ce temps, les storyboards et Xcode fonctionnent beaucoup mieux, et la documentation et les meilleures pratiques sont très répandues. Je pense que travailler avec le storyboard peut être recommandé pour la majorité des projets, même s'il y a encore des problèmes.

EDIT 3 (septembre 2013): maintenant avec le nouveau format Xcode 5, travailler en équipe avec SB pourrait encore s'améliorer, car il semble possible de fusionner le code SB beaucoup plus facilement maintenant.

Un autre EDIT: eh bien, si vous avez une heure, asseyez-vous, détendez-vous et écoutez ces gars discuter de ce sujet (Ray Wenderlich & Co)

Edit 2016.1: après avoir longtemps été un défenseur du Storyboard, j'ai eu tellement de soucis avec lui au cours des derniers mois, que j'ai décidé d'abandonner autant que possible les Storyboards. La raison en est que Apple ajoute une fonctionnalité stupide, mais ne se soucie pas des bugs et des défauts. Les performances ayant beaucoup de contraintes de mise en page automatique sont vraiment mauvaises (pendant la conception) , et le risque d'erreur est devenu énorme. Exemple: les Storyboards encore moins complexes ont tendance à passer en "mode sale" juste après avoir ouvert un projet dans Xcode (voir état git). Astuce: en tant que débutant, vous allez adorer les Storyboards depuis vous pouvez créer des prototypes rapidement et faire fonctionner les choses sans beaucoup de code. Lorsque vous entrez dans un état intermédiaire, vous ajouterez plus de code GUI à votre projet. Tôt ou tard, vous aurez tendance à faire la plupart des choses de l'interface graphique dans le code, car le résultat est plus prévisible que d'avoir plusieurs sources.

52
brainray

Sommaire

Les fichiers Nibs/.xib et les storyboards sont tous deux des fichiers Interface Builder qui sont utilisés pour créer visuellement une interface utilisateur pour les applications iOS et Mac dans Xcode (j'utiliserai la terminologie iOS pour les classes car cette question est étiquetée iOS mais elle s'applique également à la programmation Mac) .

Différences

Les plumes sont destinées à être utilisées avec un seul UIView. Ils peuvent également être connectés à une sous-classe UIViewController en définissant la classe du propriétaire du fichier sur n'importe quelle sous-classe de UIViewController et en connectant la sortie de la vue (faites glisser pour vous connecter à l'aide de l'inspecteur de connexions dans le volet de droite de Xcode).

Les storyboards sont destinés à contenir l'interface utilisateur pour 1 ou plusieurs UIViewController. Vous pouvez créer l'intégralité de votre interface utilisateur dans un seul storyboard ou la séparer en parties plus petites.

Les avantages

Les storyboards doivent toujours être utilisés en faveur des fichiers .xib/Nibs (pour les contrôleurs de vue). Les storyboards ont plus de fonctionnalités et sont activement développés par Apple.

Chaque argument en faveur de Nibs repose sur le fait qu'ils sont utilisés individuellement alors que les story-boards contiennent de nombreuses scènes. Vous pouvez utiliser un storyboard unique pour chaque UIViewController aussi facilement que vous le pouvez avec Nibs (voir les exemples de code ci-dessous). Continuez à lire pour une explication détaillée et des exemples de code.

Détaillé

Pourquoi les Storboards sont-ils supérieurs aux Nibs?

La réponse se résume essentiellement à Apple encourageant l'utilisation des Storyboards et y mettant plus d'efforts de développement.

  1. Les storyboards ont une capacité de zoom qui manque aux Nibs. Sérieusement, vous ne pouvez pas du tout zoomer sur Nibs, ce qui est nul lorsque vous concevez des écrans plus grands sur un petit ordinateur portable.
  2. Il manque des fonctionnalités clés telles que:
    • Prototype et cellules dynamiques pour UITableView ( plus d'informations )
    • La propriété top layout layout (voir le commentaire)
    • Il y en a probablement plus, veuillez modifier ou commenter si vous avez quelque chose à ajouter à cette liste
  3. Vous n'avez pas besoin de jouer avec la définition de la classe du propriétaire des fichiers.

L'argument de base contre les storyboards est que le fait d'avoir tous vos contrôleurs de vue au même endroit entraîne des conflits de fusion, un Xcode lent, des temps de construction lents et une difficulté générale à maintenir. Par conséquent, le conseil général est d'utiliser un Nib pour chaque UIViewController.

Mais ... Vous pouvez simplement créer un storyboard pour chaque UIViewController. Une pratique courante (pour moi au moins) consiste à masquer toutes les initialisations UIViewController dans une méthode de classe (car aucune autre classe n'a besoin de connaître le nom du fichier où se trouve la Nib/Storyboard du contrôleur). Permet de comparer les extraits de code associés que l'on pourrait utiliser pour créer une telle méthode. Une seule ligne de code fait toute la différence entre les deux.

Objectif c

Storyboard 

+ (ViewController *)create
{
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil];
    return [storyboard instantiateInitialViewController];
}

Plume 

+ (ViewController *)create
{
    return [super initWithNibName:@"ViewController" bundle:nil];
}

Utilisation 

- (void)showMyViewController
{
    ViewController *vc = [ViewController create];
    [self presentViewController:vc animated:YES completion:nil];
}

Swift

Storyboard 

static func create() -> ViewController {
    let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle())
    return storyboard.instantiateInitialViewController() as! ViewController
}

Plume 

static func create() -> ViewController {
    return ViewController(nibName: "ViewController", bundle: nil)
}

Utilisation 

func showMyViewController() {
    let vc = ViewController.create()
    self.presentViewController(vc, animated: true, completion: nil)
}

Arguments

Je vais aborder tous les arguments habituels pour Nibs; comme je l'ai mentionné plus tôt, il y a surtout en faveur de fichiers uniques, pas comme argument pour Nibs sur Storyboards

  1. Équipes et fusion

Argument: avoir un storyboard avec beaucoup de contrôleurs de vue provoquera des conflits de fusion si vous travaillez dans une équipe avec plusieurs personnes apportant des modifications

Réponse: un seul storyboard ne provoque pas plus de conflits de fusion qu'un seul Nib

  1. Complexité

Argument: les applications très complexes ont beaucoup de scènes dans le Storyboard, ce qui conduit à un storyboard géant qui prend une éternité à charger et est à peine compréhensible en raison de sa taille.

Réponse: C'est un bon point, mais vous pouvez facilement diviser les storyboards en parties plus petites. Références du storyboard ressemble à une grande fonctionnalité qui peut être utilisée pour lier les storyboards ensemble, mais ils ne sont disponibles que dans Xcode 7/iOS 9+. De plus, ce n'est pas une raison de choisir des plumes individuelles plutôt que des storyboards.

  1. Réutilisation

Argument: la création d'une Nib pour chaque sous-classe UIViewController vous permet de réutiliser le code afin que vous n'ayez pas à configurer toutes vos contraintes et sorties pour chaque scène de votre storyboard.

Réponse: Encore une fois, ce n'est pas une raison pour choisir des plumes individuelles plutôt que des storyboards individuels.

8
Kevin

Il y a eu une Belle présentation sur Storyboard donnée lors de la réunion LiDG il y a quelques mois.

Personnellement, je dirais que c'est la voie à suivre avec une nouvelle application. Il existe des lacunes, en particulier pour les applications très complexes, mais les avantages l'emportent principalement sur les inconvénients.

5
Stephen Darlington

Quelques avantages supplémentaires des storyboards:

  • Les storyboards ont un meilleur support pour les vues de table. Autrement dit, vous pouvez utiliser des cellules "dynamiques" et "prototypes".
  • Il est plus facile d'instancier des contrôleurs de vue à l'aide de storyboards. Vous pouvez faire des choses comme: [se lf.storyboard instantiateViewControllerWithIdentifer:]
  • Les storyboards prennent en charge les conteneurs de contrôleurs de vue, vous pouvez donc disposer des contrôleurs de vue enfant disposés graphiquement.

Les inconvénients sont:

  • Les storyboards sont lents à rendre dans XCode lorsqu'ils contiennent beaucoup de contrôleurs de vue

  • La mise en page automatique ne peut pas être activée pour un contrôleur de vue dans le storyboard.

4
railwayparade

Soyez prudent, si vous utilisez Storyboards, votre application n'est pas rétrocompatible avec les anciennes installations de système d'exploitation.

3
Beleg

Un storyboard est essentiellement un appareil pour faciliter votre travail de développeur. Il est intégré dans une série de fichiers nib, donc les performances sont à peu près équivalentes, mais c'est génial en tant que développeur de pouvoir consulter un aperçu rapide de l'ensemble de votre flux d'application.

Je commence à utiliser des storyboards sur de nouveaux projets, à condition de pouvoir convaincre le client d'accepter iOS 5 comme version minimale. C'est simplement parce que je préfère le faire de cette façon, et cela me prend moins de temps pour accomplir les mêmes tâches.

2
Ell Neal

Vous voyez la grande image en une seconde. Ayant de nombreux fichiers NIB, eh bien, vous ne voyez pas la grande image. Plus facile à maintenir vos programmes. Plus facile à comprendre les autres programmes ... entre autres.

1
Ricardo

Votre attitude vis-à-vis de la mise en page automatique peut également affecter si vous souhaitez utiliser les storyboards. En utilisant xibs, vous pouvez activer ou désactiver la disposition automatique sur une base par .xib, permettant un mixage au sein de votre application, tandis que les storyboards appliquent votre choix à TOUTES les vues qu'ils contiennent.

1
Drew C

Les storyboards ont bien plus de problèmes que d'avantages. Voici une liste de leurs problèmes, copiée de iraycd :

  • 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. Mettre à 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 points où. Mettre à jour: Ce problème peut être résolu 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 énorme 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. 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 excellente 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 empêchent 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 ajuster 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 vous font tout faire deux fois : Construisez-vous une application universelle qui fonctionne à la fois sur iPad et sur iPhone? Lorsque vous utilisez des storyboards, vous aurez généralement un storyboard pour la version iPad et un pour la version iPhone. Garder les deux synchronisés vous oblige à effectuer chaque changement d'interface utilisateur ou de flux de travail d'application à deux endroits. Yay. Mettre à jour: Dans iOS 8 et Xcode 6, vous pouvez utiliser un seul Storyboard pour iPhone et iPad.

  • 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 au segue, 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 ne sont pas consultables : Une recherche à l'échelle du projet dans Xcode n'est pas vraiment une recherche à l'échelle du projet lorsque vous utilisez des storyboards. Ils ne sont pas inclus dans la recherche. Ainsi, lorsque vous supprimez une classe personnalisée de votre code ou la renommez, vous devrez parcourir manuellement le storyboard ou regarder son XML brut pour vous assurer qu'il est à la hauteur de vos modifications de code. Non monsieur, je n'aime pas ça. Mettre à jour: les storyboards sont consultables dans Xcode 6.

  • 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 UICollectionViewController? Ou dans un simple 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 à un UIImageView: Qui sait pourquoi.

  • Les storyboards ne vous permettent pas d'activer la disposition automatique pour des vues individuelles (-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 compatibilité descendante : Xcode modifie parfois le format de fichier Storyboard et ne garantit en aucune façon que vous pourrez ouvrir Fichiers de storyboard que vous créez aujourd'hui dans quelques années, voire quelques mois. (Merci à thinkadvances pour ce point. Voir le commentaire original )

  • C'est McDonald's : Pour le dire dans les mots de Steve Jobs à propos de Microsoft: C'est McDonald's (vidéo) !

1
Eric

Avantages:

1) C'est très agréable de concevoir des interfaces

2) Vous pouvez utiliser StoryBoard Segues pour identifier les relations de navigation/modales de manière cool.

3) Si votre application prend en charge plusieurs appareils, c'est un bon moyen d'organiser différentes vues.

4) Le prototypage est un autre avantage supplémentaire.

5) Le prototype UITableViewCell peut gagner du temps et réduire également la quantité de code.

6) vous pouvez voir tous les écrans de l'application en un seul endroit en utilisant StoryBoard.

7) Vous pouvez facilement voir la relation entre eux

8) si vous travaillez sur le code de quelqu'un, vous pouvez mieux comprendre le flux de l'application.

9) Vous pouvez configurer l'interface utilisateur pour iPhone 4 et iPhone 5 en appliquant le facteur de forme rétine à partir du storyboard, sans exécuter l'application encore et encore.

10) Les clients peuvent voir le prototype de l'application avant de commencer à la développer, ici le storyboard vous aide beaucoup.

Inconvénients:

1) Il n'est disponible que sur iOS 5+

2) Les StoryBoardSegues sont plutôt rigides et vous pouvez utiliser prepareForSegue plusieurs fois.

4) Comme IB, pas très sympathique avec d'autres moteurs d'affichage et boîtes à outils.

4) Il est difficile de partager des conceptions pour une seule vue ou un ensemble de vues - vous devez envoyer tout ou rien.

5) Pour le storyboard, vous aurez besoin d'un grand écran spécialement en cas d'iPad.

6) Difficulté lors de la copie des vues d'autres applications vers le storyboard.

7) Problèmes dans le storyboard lorsque plusieurs développeurs travaillent sur le même projet en utilisant le référentiel git

copié à partir d'une ressource

1
Sandeep Rajbhar

Avant iOS 7, les story-boards étaient plutôt soignés mais pas indispensables. Ils ont introduit autant de problèmes qu'ils ont résolu. iOS 7 a fait pencher la balance vers les storyboards.

Avec iOS 8 et 9, ce n'est plus une question: utilisez des storyboards!

Le principal inconvénient du storyboard est que vous êtes complètement dépendant de XCode, et vous pourriez finir par passer des heures à faire tourner vos roues sur les bogues XCode. Mais XCode s'est beaucoup amélioré et les avantages des Storyboards sont maintenant trop nombreux pour être ignorés. Prototypes de cellules de vue tableau, classes de taille, prise en charge de la mise en page automatique, etc.

Quelques conseils:

  • Considérez chaque Storyboard comme un conteneur pour les contrôleurs de vue qui vont ensemble. Ne pensez pas à cela comme une grande mise en page de votre application entière.
  • Vous pourriez avoir besoin de plus d'un Storyboard
  • Les séquences ne sont vraiment utiles que pour les cas d'utilisation les plus triviaux - ils sont parfaits pour cela. Mais dans une application du monde réel, de nombreuses transitions se produiront à partir du code. Et c'est OK.
  • Écrivez une catégorie pour instancier par programmation des contrôleurs de vue à partir du ou des storyboard (s) de sorte que tout ce que vous avez à faire est de laisser vc = SomeViewController.create (), où la méthode gère tous les détails (tirer le story-board, retirer le contrôleur de vue du story-board, etc. ).
0
n13