Interfaces utilisateur iOS : Storyboards vs NIBs vs Custom Code

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 NIB ou du code ?

Les réponses à cette question, explicitement ou implicitement, tendent à supposer qu'il y a un choix mutuellement exclusif à faire, un choix 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 ?

Je m'explique avec un exemple hors sujet. Supposons que je veuille 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 ? Peu 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 vous souciez 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 n'y a qu'une bonne ou une mauvaise voiture en fonction de besoins spécifiques.

Retour à la conception de l'interface utilisateur iOS

Tout comme avec 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 é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 détracteurs :

• Storyboards iOS : Un outil visuel pour mettre en page plusieurs vues d'application et les transitions entre elles.
• NIBs (ou XIBs) : Chaque fichier NIB correspond à un seul élément de vue et peut être mis en page 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 (anciennement .nib et maintenant .xib, bien que l'ancienne prononciation ait persisté).
• Code personnalisé : c'est-à-dire qu'il n'y a pas d'outils d'interface graphique, mais plutôt la gestion de tous les positionnements, animations, etc. personnalisés par programmation.

Aucune de ces options n'est universellement meilleure que les autres (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 NIB et les interfaces utilisateur de code personnalisé. Je considère les storyboards comme un outil utile, mais pas tant comme un remplacement que comme un complément pour les NIB et le code personnalisé. Les storyboards sont le bon choix dans certaines situations, mais pas toutes.

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

C'est une question qui peut être, à mon avis, généralisée à un niveau supérieur, et dont la réponse est bien classée dans ma liste de principes de développement logiciel : il n'y a pas de langage, de cadre ou de technologie universel 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 didacticiel de développement iOS, nous allons explorer chacune de ces méthodes et présenter des cas d'utilisation dans lesquels elles doivent et ne doivent pas être utilisées, ainsi que des moyens de les combiner.

Storyboards iOS

L'erreur classique d'un débutant consiste à créer un storyboard iOS massif à l'échelle du projet. J'ai moi aussi fait cette erreur lorsque j'ai commencé à travailler avec Storyboards (probablement parce que c'est une voie tentante à emprunter).

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 gestion :

• Un ensemble de vues pour l'authentification et l'enregistrement.
• Un flux de saisie de commande en plusieurs étapes.
• Un flux de type assistant (c'est-à-dire un didacticiel).
• Un ensemble principal-détail de vues (par exemple, des listes de profils, des détails de profil).

Pendant ce temps, les grands storyboards doivent être évités, y compris les storyboards à 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 à entretenir, ajoutent une couche de complexité à un environnement d'équipe : lorsque plusieurs développeurs travaillent sur le même fichier de storyboard en même temps, les conflits de contrôle de code 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 visualisent le code source, ils lui attribuent une signification sémantique. Ainsi, lors de la fusion manuelle, 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 la mise en page automatique), et ce dernier pousse son changement, produisant un conflit comme celui-ci (notez les attributs id en conflit) :

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

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

Pour atténuer 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 principale simplification 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 NIB 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 passe-partout nécessaire pour faire apparaître, pousser, présenter et ignorer les contrôleurs de vue. De plus, les contrôleurs de vue sont automatiquement alloués, il n'est donc pas nécessaire d' init alloc .

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 sur place aide à garder les pièces ensemble.
• Plusieurs modèles de cellule peuvent être conçus dans le contrôleur de vue de table parent.
• Il est possible de créer des vues de tableau statiques (un ajout attendu depuis longtemps 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 NIB. 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 mise en page compliquée ou dynamique, mieux implémentée avec du code.
• La vue est déjà implémentée avec des NIB 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 rompt le flux visuel du Storyboard, mais n'a aucune implication négative sur le fonctionnement ou le développement. 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 au contrôleur de vue : elle est simplement intégrée en tant que composant, d'où le contrôleur de vue doit interagir avec la vue plutôt que de l'implémenter.

Avantages et inconvénients généraux

Maintenant que nous savons quand les storyboards sont utiles dans la conception de l'interface utilisateur iOS, et avant de passer aux NIB dans ce didacticiel, passons en revue leurs avantages et inconvénients généraux.

Avantage : performances

Intuitivement, vous pouvez supposer que lorsqu'un Storyboard est chargé, tous ses contrôleurs de vue sont instanciés immédiatement. Heureusement, ce n'est qu'une abstraction et ce n'est pas vrai de l'implémentation réelle : à la place, 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 transition est effectuée, soit manuellement à partir du code.

Pour : Prototypes

Les storyboards simplifient le prototypage et la maquette des interfaces utilisateur et du flux. En fait, une application prototype fonctionnelle complète avec vues et navigation peut être facilement implémentée à l'aide de Storyboards et de quelques lignes de code.

Inconvénient : 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.

Inconvénient : 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 interrompu dans ce cas car il n'y a aucune trace de ce qui se passe dans Interface Builder. Les storyboards prennent en charge la gestion du 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 nous appuyer sur un prepareForSegue:sender , avec un squelette if/else-if comme celui-ci :

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

Je trouve que cette approche est sujette aux erreurs et inutilement verbeuse.

NIB

Les NIB sont l'ancienne (plus) façon d'effectuer la conception d'interface iOS.

Dans ce cas, "ancien" ne signifie pas "mauvais", "obsolète" ou "obsolète". En fait, il est important de comprendre que les storyboards iOS ne remplacent pas universellement les NIB ; ils simplifient simplement la mise en œuvre de l'interface utilisateur dans certains cas.

Avec les NIB, n'importe quelle 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 distincts , chacun implémenté en tant que 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, plus facile à tester et plus facile à déboguer.

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

Quand utiliser les NIB pour la conception d'interface utilisateur iOS

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

• Vues modales
• Vues simples de connexion et d'enregistrement
• Réglages
• Fenêtres contextuelles
• Modèles de vue réutilisables
• Modèles de cellule de tableau réutilisables

Entre-temps…

Quand ne pas utiliser les NIB

Vous devez éviter d'utiliser les NIB pour :

• Vues avec contenu dynamique, où la mise en page change considérablement en fonction du contenu.
• Des vues qui, par nature, ne sont pas facilement concevables dans Interface Builder.
• Visualisez les contrôleurs avec des transitions compliquées qui pourraient être simplifiées avec Storyboarding.

Avantages et inconvénients généraux

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

Avantage : réutilisabilité

Les NIB sont pratiques lorsque la même mise en page est partagée entre plusieurs classes.

Comme 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 du même NIB. Le TTLoginView devrait masquer le champ du mot de passe, et les deux devraient spécifier les étiquettes statiques correspondantes (telles que "Entrez votre nom d'utilisateur" contre "Entrez votre mot de passe"), mais les étiquettes auraient les mêmes fonctionnalités de base et des dispositions similaires.

Avantages et inconvénients : performances

Les NIB sont chargés paresseusement, ils n'utilisent donc pas de mémoire tant qu'ils n'y sont pas obligés. Bien que cela puisse être un avantage, il y a une latence dans 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 NIB 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 les NIB et les 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 NIB et les storyboards sont implémentés avec du code, de sorte que leur fonctionnalité sera naturellement un sous-ensemble. Passons directement aux avantages et aux inconvénients.

Avantage : sous le capot

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

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

Cela ne se limite pas à iOS, mais à tout outil RAD visuel (par exemple, Visual Studio et Delphi, pour n'en nommer que quelques-uns). Les environnements Visual HTML RAD représentent un cas limite typique : ils sont utilisés pour générer du code (souvent mal écrit), prétendant 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 code HTML et CSS brut conduira à un code plus modulaire et plus efficace.

Ainsi, maîtriser le codage des interfaces utilisateur iOS vous donne plus de contrôle et une meilleure connaissance de la façon dont ces éléments s'emboîtent, ce qui augmente votre limite supérieure en tant que développeur.

Pour : 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 la vue sont déplacés et le flux ou la mise en page s'ajuste de manière significative en fonction du contenu, en sont des exemples typiques.

Pour : Conflits de fusion

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

Inconvénient : Prototypage

Il est difficile de comprendre à quoi ressemblera une mise en page tant que vous ne l'aurez pas 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 NIB et aux Storyboards qui vous donnent un aperçu immédiat de la façon dont les choses seront rendues.

Inconvénient : refactorisation

Refactoriser du code qui a été é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 ardues.

Avantage : performances

En termes de performances, les storyboards et les NIB sont soumis à la surcharge de chargement et d'analyse ; et à la fin, ils sont indirectement traduits en code. Inutile de dire que cela ne se produit pas avec les interfaces utilisateur codées.

Avantage : 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 forké, dans le but de créer une seule base de code, mais générant 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 NIB et les storyboards. Les fichiers modèles n'autorisent pas l'héritage et les solutions possibles se limitent aux suivantes :

• Dupliquez les fichiers NIB et Storyboard. Après cela, ils ont des vies séparées et n'ont aucun lien 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. De lourds remplacements de 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 Interface Builder, 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 le code personnalisé pour la conception de l'interface utilisateur iOS lorsque vous avez :

• Mises en page dynamiques.
• Vues avec effets, tels que coins arrondis, ombres, etc.
• Tous les cas où l'utilisation des NIB et des Storyboards est compliquée ou irréalisable.

Quand ne pas utiliser le code

En général, les interfaces utilisateur codées peuvent toujours être utilisées. Ils sont rarement une mauvaise idée, alors je mettrais un ici.

Bien que les NIB 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 NIB 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 UI programmatiques ne prendront probablement pas en compte les deux autres options : le code permet de faire tout ce qui est techniquement possible, alors que les alternatives ont leurs limites. Pour le reste des développeurs, le couteau de l'armée Xcode fournit trois outils qui peuvent être utilisés simultanément, dans le même projet, efficacement.

Comment, demandez-vous? Comme tu veux. Voici quelques approches possibles :

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

Pour terminer, regardons un dernier exemple qui relie tout cela ensemble.

Un cas d'utilisation simple

Supposons que nous souhaitions 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 dans les futures listes).
• Une vue détaillée du profil, composée de sections distinctes (comprenant des informations sur le profil, des 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 des utilisateurs, chaque balise étant proportionnelle en taille 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 dans 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, car nous pouvons 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 distinct pour le modèle de cellule de liste de profils réutilisable.
• Trois fichiers NIB distincts pour la vue des détails du profil, un pour chacune des sections distinctes qui le composent (détails du profil, statistiques, trois derniers messages), pour permettre une meilleure maintenabilité. Ces NIB seront instanciés en tant que vues, puis ajoutés au contrôleur de vue.
• Code personnalisé pour la vue du nuage de tags. Cette vue est un exemple typique d'une vue qui ne peut pas être conçue dans Interface Builder, ni via les StoryBoards ni les NIB. Au lieu de cela, il est complètement implémenté via le 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 à l'intérieur du contrôleur de vue plutôt que comme une vue autonome, mais nous les gardons séparées 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 relient nos trois approches principales de la conception de l'interface utilisateur. N'oubliez pas : il n'y a pas de décision binaire à prendre, car chaque outil a ses forces et ses faiblesses.

Emballer

Comme examiné dans ce didacticiel, les storyboards ajoutent une simplification notable à la conception de l'interface utilisateur iOS et au flux visuel. Ils éliminent également le code passe-partout ; mais tout cela a un prix, payé en flexibilité. Les NIB, 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 NIB, les storyboards et l'ISU codé.

En conclusion, je tiens à souligner une chose : évitez à tout prix d'utiliser l'outil de conception d'interface utilisateur iOS inapproprié . Si une vue ne peut pas être conçue avec un Storyboard, ou si elle peut être implémentée avec des NIB ou du code de manière plus simple, n'utilisez pas de Storyboard. De même, si une vue ne peut pas être conçue à l'aide de NIB, n'utilisez pas de NIB. Ces règles, bien que simples, contribueront grandement à votre formation en tant que développeur.