Interfaces utilisateur iOS: Storyboards vs NIBs vs Code personnalisé

J’entends souvent les développeurs iOS poser une variante de la même question clé:

Quelle est la meilleure façon de développer une interface utilisateur dans iOS : via des Storyboards, des plumes ou du code?

Les réponses à cette question, explicitement ou implicitement, tendent à supposer qu’il y a un choix mutuellement exclusif à faire, qui est souvent abordé dès le départ, avant le développement.

Je suis d’avis que la réponse devrait plutôt prendre la forme d’une ou plusieurs contre-questions.

Quelle est la « meilleure » voiture?

Laissez-moi vous expliquer avec un exemple hors sujet. Dites que je veux acheter une voiture et je vous pose une question simple: « Quel est le meilleur choix? »

Pouvez-vous vraiment répondre en suggérant un modèle, voire une marque ? Pas probable, sauf si vous suggérez une Ferrari. Au lieu de cela, vous répondriez probablement avec quelques autres questions, comme:

• Quel est votre budget ?
• De combien de places avez-vous besoin ?
• Vous souciez-vous de la consommation de carburant?
• Que pensez-vous des voitures de sport?

Il est évident qu’il n’y a pas de bonne ou de mauvaise voiture à moins qu’elle ne soit placée dans un contexte approprié — il y a juste une bonne ou une mauvaise voiture basée sur des besoins spécifiques.

Retour à la conception de l’interface utilisateur iOS

Tout comme pour notre enquête sur les voitures, la question « Quelle est la meilleure façon de développer une interface utilisateur iOS » manque de contexte. Et assez étonnamment, la réponse n’a pas besoin d’être un cas fourre-tout.

D’une manière générale, il existe trois types d’approches de conception d’interface utilisateur que vous pouvez adopter, chacune avec ses avantages et ses inconvénients, ses fans et ses ennemis:

• Storyboards iOS : Un outil visuel pour afficher plusieurs vues d’applications et les transitions entre elles.
• Plumes (ou XIBs) : Chaque fichier de PLUMES correspond à un seul élément de vue et peut être disposé dans l’Interface Builder, ce qui en fait également un outil visuel. Notez que le nom « NIB » est dérivé de l’extension de fichier (précédemment.plume et maintenant.xib, bien que l’ancienne prononciation ait persisté).
• Code personnalisé: c’est-à-dire pas d’outils d’interface graphique, mais plutôt la gestion de tout le positionnement personnalisé, de l’animation, etc. par programme.

Aucune de ces options n’est universellement meilleure que toute autre (malgré ce que vous pourriez entendre).

Les storyboards, par exemple, sont le dernier ajout à la boîte à outils de l’interface utilisateur iOS. On m’a dit qu’ils étaient l’avenir, qu’ils remplaceraient les PLUMES et les interfaces utilisateur de code personnalisées. Je vois les storyboards comme un outil utile, mais pas tant un remplacement qu’un complément pour les plumes et le code personnalisé. Les storyboards sont le bon choix dans certaines situations, mais pas dans toutes les situations.

De plus, pourquoi devriez-vous vous en tenir statiquement à une seule option lorsque vous pouvez toutes les utiliser (dans le même projet), en choisissant le mécanisme qui correspond le mieux au problème spécifique en question?

C’est une question qui peut être, à mon avis, généralisée à un niveau supérieur, et dont la réponse est très bien classée dans ma liste de principes de développement logiciel: Il n’y a pas de langage, de cadre ou de technologie universels qui soit le meilleur choix universel pour chaque problème de développement logiciel. Il en va de même pour la conception de l’interface utilisateur iOS.

Dans ce tutoriel de développement iOS, nous allons explorer chacune de ces méthodes et introduire des cas d’utilisation dans lesquels elles devraient et ne devraient pas être utilisées, ainsi que des moyens de les mélanger ensemble.

Storyboards iOS

L’erreur d’un débutant classique est de créer un Storyboard iOS massif à l’échelle du projet. Moi aussi j’ai fait cette erreur quand j’ai commencé à travailler avec des Storyboards (probablement parce que c’est une voie tentante à prendre).

Comme son nom l’indique, un Storyboard est un tableau avec une histoire à raconter. Il ne devrait pas être utilisé pour mélanger des histoires sans rapport en un seul gros volume. Un storyboard doit contenir des contrôleurs de vue qui sont logiquement liés les uns aux autres — ce qui ne signifie pas tous les contrôleurs de vue.

Par exemple, il est logique d’utiliser des Storyboards lors de la manipulation:

• Un ensemble de vues pour l’authentification et l’enregistrement.
• Un flux d’entrée d’ordre en plusieurs étapes.
• Un flux de type assistant (c’est-à-dire tutoriel).
• Un ensemble de vues maître-détail (par exemple, listes de profils, détails de profil).

Pendant ce temps, les Storyboards volumineux doivent être évités, y compris les Storyboards uniques à l’échelle de l’application (sauf si l’application est relativement simple). Avant d’aller plus loin, voyons pourquoi.

La folie des grands Storyboards iOS

Les grands Storyboards, en plus d’être difficiles à parcourir et à maintenir, ajoutent une couche de complexité à un environnement d’équipe: lorsque plusieurs développeurs travaillent sur le même fichier storyboard en même temps, les conflits de contrôle de source sont inévitables. Et bien qu’un storyboard soit représenté en interne sous la forme d’un fichier texte (un fichier XML, en fait), la fusion n’est généralement pas triviale.

Lorsque les développeurs consultent le code source, ils lui attribuent une signification sémantique. Ainsi, lorsqu’ils fusionnent manuellement, ils sont capables de lire et de comprendre les deux côtés d’un conflit et d’agir en conséquence. Un storyboard, au contraire, est un fichier XML géré par Xcode, et la signification de chaque ligne de code n’est pas toujours facile à comprendre.

Prenons un exemple très simple: disons que deux développeurs différents changent la position d’un UILabel (en utilisant autolayout), et ce dernier pousse son changement, produisant un conflit comme celui-ci (remarquez les attributs id conflictuels):

<layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides><layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides>

Le id lui-même ne fournit aucune indication quant à sa véritable signification, vous n’avez donc rien avec lequel travailler. La seule solution significative est de choisir l’un des deux côtés du conflit et de rejeter l’autre. Y aura-t-il des effets secondaires? Qui sait ? Pas toi.

Pour résoudre ces problèmes de conception d’interface iOS, l’utilisation de plusieurs storyboards dans le même projet est l’approche recommandée.

Quand utiliser les storyboards

Les storyboards sont mieux utilisés avec plusieurs contrôleurs de vue interconnectés, car leur simplification majeure réside dans la transition entre les contrôleurs de vue. Dans une certaine mesure, ils peuvent être considérés comme une composition de PLUMES avec des flux visuels et fonctionnels entre les contrôleurs de vue.

En plus de faciliter le flux de navigation, un autre avantage distinct est qu’ils éliminent le code standard nécessaire pour faire apparaître, pousser, présenter et rejeter les contrôleurs de vue. De plus, les contrôleurs de vue sont automatiquement alloués, il n’est donc pas nécessaire de alloc et init manuellement.

Enfin, bien que les Storyboards soient mieux utilisés pour les scénarios impliquant plusieurs contrôleurs de vue, il est également défendable d’utiliser un Storyboard lorsque vous travaillez avec un seul contrôleur de vue de table pour trois raisons:

• La possibilité de concevoir des prototypes de cellules de table en place permet de garder les pièces ensemble.
• Plusieurs modèles de cellules peuvent être conçus à l’intérieur du contrôleur de vue de table parent.
• Il est possible de créer des vues de table statiques (un ajout tant attendu qui n’est malheureusement disponible que dans les Storyboards).

On pourrait soutenir que plusieurs modèles de cellules peuvent également être conçus à l’aide de PLUMES. En vérité, ce n’est qu’une question de préférence: certains développeurs préfèrent tout avoir au même endroit, tandis que d’autres s’en fichent.

Quand ne pas Utiliser les Storyboards iOS

Quelques cas:

• La vue a une disposition compliquée ou dynamique, mieux implémentée avec du code.
• La vue est déjà implémentée avec des NIBs ou du code.

Dans ces cas, nous pouvons soit laisser la vue hors du Storyboard, soit l’intégrer dans un contrôleur de vue. Le premier brise le flux visuel du Storyboard, mais n’a pas d’implications fonctionnelles ou de développement négatives. Ce dernier conserve ce flux visuel, mais il nécessite des efforts de développement supplémentaires car la vue n’est pas intégrée dans le contrôleur de vue: elle est simplement intégrée en tant que composant, le contrôleur de vue doit donc interagir avec la vue plutôt que de l’implémenter.

Avantages et inconvénients généraux

Maintenant que nous avons une idée du moment où les Storyboards sont utiles dans la conception de l’interface utilisateur iOS, et avant de passer aux PLUMES dans ce tutoriel, passons en revue leurs avantages et inconvénients généraux.

Pro: Performance

Intuitivement, vous pouvez supposer que lorsqu’un Storyboard est chargé, tous ses contrôleurs de vue sont instanciés immédiatement. Heureusement, il ne s’agit que d’une abstraction et non de l’implémentation réelle: au lieu de cela, seul le contrôleur de vue initial, le cas échéant, est créé. Les autres contrôleurs de vue sont instanciés dynamiquement, soit lorsqu’une séquence est effectuée, soit manuellement à partir du code.

Pro: Prototypes

Les storyboards simplifient le prototypage et la moquerie des interfaces utilisateur et du flux. En fait, un prototype d’application complet avec vues et navigation peut être facilement implémenté à l’aide de Storyboards et de quelques lignes de code.

Con: Réutilisabilité

Lorsqu’il s’agit de déplacer ou de copier, les Storyboards iOS sont mal positionnés. Un Storyboard doit être déplacé avec tous ses contrôleurs de vue dépendants. En d’autres termes, un contrôleur de vue unique ne peut pas être extrait individuellement et réutilisé ailleurs en tant qu’entité indépendante unique; il dépend du reste du Storyboard pour fonctionner.

Con : Flux de données

Les données doivent souvent être transmises entre les contrôleurs de vue lors de la transition d’une application. Cependant, le flux visuel du Storyboard est cassé dans ce cas car il n’y a aucune trace de cela dans le générateur d’interface. Les storyboards se chargent de gérer le flux entre les contrôleurs de vue, mais pas le flux de données. Ainsi, le contrôleur de destination doit être configuré avec du code, remplaçant l’expérience visuelle.

Dans de tels cas, nous devons compter sur un prepareForSegue:sender, avec un squelette if /else-if comme celui-ci:

- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = ; if ("segue_name_1"]) { MyViewController *vc = (MyViewController *) ; ; } else if ("segue_name_2"]) { ... } else if ...}

Je trouve cette approche sujette aux erreurs et inutilement verbeuse.

Plumes

Les plumes sont l’ancienne (er) façon d’effectuer la conception d’interface iOS.

Dans ce cas, « vieux » ne signifie pas « mauvais », « obsolète » ou « obsolète ». En fait, il est important de comprendre que les Storyboards iOS ne sont pas un remplacement universel des NIBs; ils simplifient simplement l’implémentation de l’interface utilisateur dans certains cas.

Avec les NIBs, toute vue arbitraire peut être conçue, que le développeur peut ensuite attacher à un contrôleur de vue selon les besoins.

Si nous appliquons une conception orientée objet à nos interfaces utilisateur, il est logique de diviser la vue d’un contrôleur de vue en modules séparés, chacun implémenté comme une vue avec son propre fichier NIB (ou avec plusieurs modules regroupés dans le même fichier). L’avantage évident de cette approche est que chaque composant est plus facile à développer, à tester et à déboguer.

Les NIBs partagent les problèmes de conflit de fusion que nous avons vus avec les Storyboards, mais dans une moindre mesure, car les fichiers NIB fonctionnent à plus petite échelle.

Quand utiliser les NIBs pour la conception de l’interface utilisateur iOS

Un sous-ensemble de tous les cas d’utilisation serait:

• Vues modales
• Vues simples de connexion et d’enregistrement
• Paramètres
• Fenêtres contextuelles
• Modèles de vue réutilisables
• Modèles de cellules de table réutilisables

Pendant ce temps…

Quand Ne pas utiliser de plumes

Vous devez éviter d’utiliser des plumes pour:

• Vues avec un contenu dynamique, où la mise en page change considérablement en fonction du contenu.
• Vues qui, par nature, ne sont pas facilement concevables dans le générateur d’interface.
• Affichez les contrôleurs avec des transitions compliquées qui pourraient être simplifiées avec le Storyboard.

Avantages et inconvénients généraux

Plus généralement, passons en revue les avantages et les inconvénients de l’utilisation des plumes.

Pro: Réutilisabilité

Les PLUMES sont utiles lorsque la même disposition est partagée entre plusieurs classes.

Dans un cas d’utilisation simple, un modèle de vue contenant un nom d’utilisateur et un champ de texte de mot de passe pourrait être implémenté avec les vues hypothétiques TTLoginView et TTSignupView, qui pourraient toutes deux provenir de la même plume. Le TTLoginView devrait masquer le champ de mot de passe, et les deux devraient spécifier les étiquettes statiques correspondantes (telles que « Entrez votre nom d’utilisateur » vs « Entrez votre mot de passe »), mais les étiquettes auraient les mêmes fonctionnalités de base et des mises en page similaires.

Pro & Con: Performance

Les plumes sont chargées paresseusement, elles n’utilisent donc pas de mémoire tant qu’elles ne le doivent pas. Bien que cela puisse être un avantage, il y a une latence pour le processus de chargement paresseux, ce qui en fait également un inconvénient.

Code personnalisé iOS (interfaces utilisateur programmatiques)

Toute conception d’interface iOS pouvant être réalisée avec des Storyboards et des NIBs peut également être implémentée avec du code brut (il fut un temps, bien sûr, où les développeurs n’avaient pas le luxe d’un ensemble d’outils aussi riche).

Peut—être plus important encore, ce qui ne peut pas être fait avec des NIBs et des Storyboards peut toujours être implémenté avec du code – à condition, bien sûr, que cela soit techniquement faisable. Une autre façon de voir les choses est que les NIBs et les Storyboards sont implémentés avec du code, donc leur fonctionnalité sera naturellement un sous-ensemble. Passons directement aux avantages et aux inconvénients.

Pro: Sous le capot

Le plus grand avantage de créer une interface utilisateur iOS par programmation: si vous savez coder une interface utilisateur, vous savez ce qui se passe sous le capot, alors qu’il n’en va pas de même pour les NIBs et les Storyboards.

Pour faire une comparaison : une calculatrice est un outil utile. Mais ce n’est pas une mauvaise chose de savoir comment effectuer des calculs manuellement.

Cela ne se limite pas à iOS, mais à n’importe quel outil Visual RAD (par exemple, Visual Studio et Delphi, pour n’en nommer que quelques-uns). Les environnements RAD HTML visuels représentent un cas limite typique : ils sont utilisés pour générer du code (souvent mal écrit), affirmant qu’aucune connaissance HTML n’est nécessaire et que tout peut être fait visuellement. Mais aucun développeur web n’implémenterait une page web sans se salir les mains: ils savent que la manipulation manuelle du HTML et du CSS bruts conduira à un code plus modulaire et plus efficace.

Ainsi, la maîtrise du codage des interfaces utilisateur iOS vous donne plus de contrôle et une plus grande conscience de la façon dont ces pièces s’emboîtent, ce qui soulève votre limite supérieure en tant que développeur.

Pro: Lorsque le code est la seule option

Il existe également des cas dans lesquels le code iOS personnalisé est la seule option pour la conception de l’interface utilisateur. Les mises en page dynamiques, où les éléments de vue sont déplacés et le flux ou la mise en page s’ajuste de manière significative en fonction du contenu, sont des exemples typiques.

Pro: Conflits de fusion

Alors que les NIBs et les Storyboards ont beaucoup souffert des conflits de fusion, le code n’a pas le même défaut. Tout le code a une signification sémantique, donc la résolution des conflits n’est pas plus difficile que d’habitude.

Con: Prototypage

Il est difficile de comprendre à quoi ressemblera une mise en page avant de l’avoir vue en action. De plus, vous ne pouvez pas positionner visuellement les vues et les contrôles, donc la traduction des spécifications de mise en page en une vue tangible peut prendre beaucoup plus de temps, par rapport aux NIBs et aux Storyboards qui vous donnent un aperçu immédiat du rendu des choses.

Avec: Refactoring

Refactoriser du code écrit il y a longtemps ou par quelqu’un d’autre devient également beaucoup plus compliqué: lorsque des éléments sont positionnés et animés avec des méthodes personnalisées et des nombres magiques, les sessions de débogage peuvent devenir difficiles.

Pro: Performance

En termes de performances, les Storyboards et les NIBs sont soumis à la surcharge du chargement et de l’analyse; et à la fin, ils sont indirectement traduits en code. Inutile de dire que cela ne se produit pas avec les interfaces utilisateur créées par code.

Pro: Réutilisabilité

Toute vue implémentée par programme peut être conçue de manière réutilisable. Voyons quelques cas d’utilisation:

• Deux vues ou plus partagent un comportement commun, mais elles sont légèrement différentes. Une classe de base et deux sous-classes résolvent le problème avec élégance.
• Un projet doit être bifurqué, dans le but de créer une base de code unique, mais de générer deux (ou plusieurs) applications différentes, chacune avec des personnalisations spécifiques.

Le même processus de conception d’interface utilisateur serait beaucoup plus compliqué avec les NIBs et les Storyboards. Les fichiers modèles n’autorisent pas l’héritage et les solutions possibles sont limitées aux éléments suivants:

• Dupliquez les fichiers NIB et Storyboard. Après cela, ils ont des vies séparées et aucune relation avec le fichier d’origine.
• Remplacez l’apparence et le comportement par du code, ce qui peut fonctionner dans des cas simples, mais peut entraîner des complications importantes dans d’autres. Les surcharges lourdes avec du code peuvent également rendre la conception visuelle inutile et devenir une source constante de maux de tête, par exemple, lorsqu’un certain contrôle s’affiche dans un sens dans le générateur d’interface, mais semble complètement différent lorsque l’application est en cours d’exécution.

Quand utiliser le code

Il est souvent judicieux d’utiliser un code personnalisé pour la conception de l’interface utilisateur iOS lorsque vous avez:

• Mises en page dynamiques.
• Vues avec des effets, tels que des coins arrondis, des ombres, etc.
• Tout cas dans lequel l’utilisation de plumes et de Storyboards est compliquée ou impossible.

Quand ne pas utiliser le Code

En général, les interfaces utilisateur créées par code peuvent toujours être utilisées. C’est rarement une mauvaise idée, alors je mettrais un ici.

Bien que les plumes et les Storyboards apportent certains avantages à la table, je pense qu’il n’y a aucun inconvénient raisonnable que je mettrais dans une liste pour décourager l’utilisation du code (sauf peut-être la paresse).

Un projet, plusieurs outils

Les Storyboards, les PLUMES et le code sont trois outils différents pour créer une interface utilisateur iOS. Nous avons de la chance de les avoir. Les fanatiques des interfaces utilisateur programmatiques ne prendront probablement pas en compte les deux autres options: le code vous permet de faire tout ce qui est techniquement possible, alors que les alternatives ont leurs limites. Pour le reste des développeurs, le couteau militaire Xcode fournit trois outils qui peuvent être utilisés en même temps, dans le même projet, efficacement.

Comment, demandez-vous? Comme vous le souhaitez. Voici quelques approches possibles:

• Regroupez tous les écrans associés en groupes distincts et implémentez chaque groupe avec son propre Storyboard distinct.
• Concevez des cellules de table non réutilisables en place avec un Storyboard, à l’intérieur du contrôleur de vue de table.
• Concevez des cellules de table réutilisables dans les NIBs pour encourager la réutilisation et éviter la répétition, mais chargez ces NIBs via un code personnalisé.
• Concevez des vues, des contrôles et des objets intermédiaires personnalisés à l’aide de NIBs.
• Utilisez du code pour les vues très dynamiques, et plus généralement pour les vues qui ne sont pas facilement implémentables via des Storyboards et des NIBs, tout en logeant des transitions de vue dans un Storyboard.

Pour fermer, regardons un dernier exemple qui lie tout cela.

Un cas d’utilisation simple

Disons que nous voulons développer une application de messagerie de base avec plusieurs vues différentes:

• Une liste d’amis suivis (avec un modèle de cellule réutilisable pour garder l’interface utilisateur cohérente sur les listes futures).
• Une vue détaillée du profil, composée de sections distinctes (y compris les informations sur le profil, les statistiques et une barre d’outils).
• Liste des messages envoyés et reçus d’un ami.
• Un nouveau formulaire de message.
• Une vue de nuage de balises qui affiche les différentes balises utilisées dans les messages de l’utilisateur, chaque balise ayant une taille proportionnelle au nombre de fois où elle a été utilisée.

De plus, nous voulons que les vues se déroulent comme suit:

• Cliquer sur un élément de la liste des amis suivis affiche les détails du profil de l’ami concerné.
• Les détails du profil affichent le nom du profil, l’adresse, les statistiques, une courte liste des messages les plus récents et une barre d’outils.

Pour implémenter cette application iOS, nos trois outils d’interface utilisateur seront utiles, comme nous pouvons l’utiliser:

• Un Storyboard avec quatre contrôleurs de vue (la liste, les détails, la liste des messages et le nouveau formulaire de message).
• Un fichier NIB séparé pour le modèle de cellule de liste de profil réutilisable.
• Trois fichiers NIB distincts pour la vue détails du profil, un pour chacune des sections distinctes qui la composent (détails du profil, statistiques, trois derniers messages), afin de permettre une meilleure maintenabilité. Ces NIBs seront instanciés en tant que vues, puis ajoutés au contrôleur de vue.
• Code personnalisé pour la vue nuage de tags. Cette vue est un exemple typique de celle qui ne peut pas être conçue dans le générateur d’interface, ni via des StoryBoards ni des NIBs. Au lieu de cela, il est complètement implémenté via du code. Afin de maintenir le flux visuel du Storyboard, nous choisissons d’ajouter un contrôleur de vue vide au Storyboard, d’implémenter la vue du nuage de balises en tant que vue autonome et d’ajouter par programme la vue au contrôleur de vue. De toute évidence, la vue pourrait également être implémentée dans le contrôleur de vue plutôt que comme une vue autonome, mais nous les gardons séparés pour une meilleure réutilisation.

Une maquette vraiment basique pourrait ressembler à:

Avec cela, nous avons décrit la construction de base d’une application iOS raisonnablement sophistiquée dont les vues principales lient nos trois approches principales de la conception de l’interface utilisateur. Rappelez-vous: il n’y a pas de décision binaire à prendre, car chaque outil a ses forces et ses faiblesses.

Conclusion

Comme examiné dans ce turtorial, les Storyboards ajoutent une simplification notable à la conception de l’interface utilisateur iOS et au flux visuel. Ils éliminent également le code standard; mais tout cela a un prix, payé en flexibilité. Les NIBs, quant à eux, offrent plus de flexibilité en se concentrant sur une seule vue, mais sans flux visuel. La solution la plus flexible, bien sûr, est le code, qui a tendance à être plutôt hostile et intrinsèquement non visuel.

Si cet article vous a intrigué, je vous recommande fortement de regarder le grand débat de Ray Wenderlich, 55 minutes bien consacrées à une discussion sur les NIBs, les Storyboards et les interfaces utilisateur créées par des codes.

En terminant, je tiens à souligner une chose: Évitez à tout prix d’utiliser l’outil de conception d’interface utilisateur iOS incorrect. Si une vue n’est pas concevable avec un Storyboard, ou si elle peut être implémentée avec des NIBs ou du code de manière plus simple, n’utilisez pas de Storyboard. De même, si une vue n’est pas concevable à l’aide de NIBs, n’utilisez pas de NIBs. Ces règles, bien que simples, contribueront grandement à votre éducation en tant que développeur.