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

Quelle est la meilleure façon de développer une interface utilisateur sous iOS: via des storyboards, des NIB ou du code?

Les réponses à cette question, explicitement ou implicitement, tendent à supposer qu’il ya 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’un ou de plusieurs compteur des questions.

Quelle est la «meilleure» voiture?

Permettez-moi de 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 un marque ? Peu probable, sauf si vous suggérez une Ferrari. Au lieu de cela, vous répondrez probablement avec quelques autres questions, telles que:

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

Il est évident qu’il n’existe pas de bien ou mauvais voiture à moins qu’elle ne soit placée dans un contexte approprié - il n’ya 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, le 'Quelle est la meilleure façon de développer une interface utilisateur iOS?' la question manque de contexte. Et de manière assez surprenante, la réponse n'est pas nécessairement un cas fourre-tout.

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

• Scénarimages iOS : Un outil visuel pour la présentation de plusieurs vues d'application et les transitions entre elles.
• NIB (ou XIB) : Chaque fichier NIB correspond à un seul élément de vue et peut être mis en page dans Interface Builder, ce qui en fait également un outil visuel. Notez que le nom «NIB» est dérivé de l'extension de fichier (auparavant .nib et maintenant .xib, bien que l'ancienne prononciation ait persisté).
• Code personnalisé : c'est-à-dire non GUI outils, mais plutôt, gérer tous les positionnements personnalisés, animations, etc. par programmation.

Aucune de ces options n'est universellement mieux que tout autre (malgré ce que vous pourriez entendre).

la prévision des ventes est un exemple d'une (n) _____ tâche.

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 vois les storyboards comme un outil utile, mais pas tant remplacement as a complément pour les NIB et le code personnalisé. Les storyboards sont le bon choix dans certaines situations, mais pas dans 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 en question?

C'est une question qui peut, à mon avis, être 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 universel, de cadre ou de technologie 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 devraient et devraient ne pas être employés, ainsi que les moyens de les mélanger.

Scénarimages iOS

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

L'erreur classique d'un débutant est de créer un storyboard massif à l'échelle du projet. 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.

Comme son nom l'indique, un Storyboard est un planche avec une histoire à raconter . Il ne doit 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 veut pas dire chaque voir le contrôleur.

Par exemple, il est judicieux d'utiliser des Storyboards lors de la gestion:

• Un ensemble de vues pour l'authentification et l'enregistrement.
• Un flux d'entrée de commande en plusieurs étapes.
• Un flux semblable à un assistant (c'est-à-dire un didacticiel).
• Un ensemble de vues maître-détails (par exemple, listes de profils, détails de profil).

Pendant ce temps, les grands storyboards doivent être évités, y compris les storyboards uniques à l'échelle de l'application (à moins que l'application ne soit 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 de storyboard en même temps, les conflits de contrôle de source sont inévitables . Et tandis qu'un storyboard est représenté en interne comme 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, 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):

comment créer un robot

id

Le alloc 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’une des deux parties 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.

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.

En plus de faciliter le flux de navigation, un autre avantage distinct est qu'ils éliminent le code standard nécessaire pour afficher, 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 de faire manuellement init et prepareForSegue:sender.

Enfin, alors que les storyboards sont 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 Célibataire 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 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é, c'est juste une question de préférence: certains développeurs préfèrent tout avoir au même endroit, tandis que d'autres s'en moquent.

Quand ne pas pour utiliser les storyboards iOS

Quelques cas:

• La vue a une disposition complexe 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 en dehors du Storyboard, soit l'intégrer dans un contrôleur de vue. Le premier casse le flux visuel du Storyboard, mais n’a aucune implication fonctionnelle ou de développement négative. 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: il est simplement intégré en tant que composant, par conséquent, 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 avons une idée de quand les storyboards sont utiles dans iOS Conception de l'interface utilisateur , et avant de passer aux NIB dans ce didacticiel, passons en revue leurs avantages et inconvénients généraux.

Pro: 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 ne 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 lors d'un segue, soit manuellement à partir du code.

contrairement aux données dans les bases de données, les données dans les entrepôts de données sont :

Pro: Prototypes

Les storyboards simplifient le prototypage et la maquette des interfaces utilisateur et couler. 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.

Avec: 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 individuellement extrait et réutilisé ailleurs en tant qu'entité indépendante unique; cela dépend du reste du Storyboard pour fonctionner.

Avec: 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 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.

Les storyboards se chargent de gérer le flux entre les contrôleurs de vue, mais pas le flux de données.

Dans de tels cas, nous devons nous fier à un - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier [email protected] 'segue_name_1']) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier [email protected] 'segue_name_2']) { ... } else if ... } , avec un squelette if / else-if comme celui-ci:

TTLoginView

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

NIBs

Les NIB sont l'ancien (er) moyen de concevoir une 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 sont pas un remplacement universel des NIB; ils simplifient simplement la mise en œuvre de l'interface utilisateur dans certains cas.

Avec les NIB, toute vue arbitraire peut être conçue, que le développeur peut ensuite attacher à un contrôleur de vue selon ses 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, plus facile à tester et plus facile à déboguer.

Les NIB 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 à une 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 de connexion et d'inscription simples
• Paramètres
• Fenêtres pop-up
• Modèles de vue réutilisables
• Modèles de cellules de tableau réutilisables

Pendant ce temps…

Quand ne pas utiliser des NIB

Vous devez éviter d'utiliser les NIB pour:

• Vues avec un 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.
• 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 NIB.

Pro: réutilisabilité

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

En tant que 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 l'hypothétique TTSignupView et TTLoginView vues, qui peuvent toutes deux provenir du même NIB. Le

devrait masquer le champ du mot de passe, et les deux devraient spécifier les libellés statiques correspondants (tels que 'Entrez votre nom d'utilisateur' ou 'Entrez votre mot de passe'), mais les libellés auraient les mêmes fonctionnalités de base et des dispositions similaires.

Avantages et inconvénients: performances

Les NIB sont paresseusement chargé , ils n’utilisent donc pas la mémoire tant qu’ils ne le doivent pas. 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)

Tout Conception d'interface iOS cela peut être fait avec les storyboards et les NIB peuvent également être implémentés 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).

Ce qui ne peut pas être fait avec les NIB et les Storyboards peut toujours être implémenté avec du code.

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 réalisable. 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.

Pro: sous le capot

Le plus grand avantage de la création d'une interface utilisateur iOS par programmation: si vous savez coder une interface utilisateur, alors vous savez ce qui se passe sous le capot , alors que ce n'est pas nécessairement vrai 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 comment 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), 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 gestion manuelle du HTML et du CSS bruts conduira à un code plus modulaire et plus efficace.

qu'est-ce que l'ajustement fiscal à la frontière

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

Pro: quand le code est la seule option

Il existe également des cas dans lesquels le code iOS personnalisé est la seule option pour la conception d'interface utilisateur. Les mises en page dynamiques, dans lesquelles 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: Fusionner les conflits

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.

Avec: Prototypage

Il est difficile de comprendre à quoi ressemblera une mise en page tant que vous ne l'avez pas vue en action. De plus, vous ne pouvez pas positionner visuellement les vues et les commandes, de sorte que 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 du rendu des éléments.

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 ardues.

Pro: 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 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 forké, dans le but de créer une base de code unique, mais générant deux (ou plus) 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 sont limitées aux suivantes:

• 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 remplacements importants avec le code peuvent également rendre la conception visuelle inutile et évoluer vers une source constante de maux de tête, par exemple, lorsqu'un certain contrôle affiche 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 un code personnalisé pour la conception de l'interface utilisateur iOS lorsque vous avez:

• Dispositions dynamiques.
• Vues avec effets, tels que coins arrondis, ombres, etc.
• Tout cas dans lequel l'utilisation de NIB et de Storyboards est compliquée ou irréalisable.

Quand ne pas utiliser le code

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

Bien que les NIB et les storyboards apportent certains avantages à la table, je pense qu'il n'y a pas d'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 sommes chanceux 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 simultanément, dans le même projet, de manière efficace.

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

• Regroupez tous les écrans associés dans des groupes séparés 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é.
• Créez 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 vues dans un storyboard.

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

Un cas d'utilisation simple

Supposons que nous souhaitons 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 de profil, composée de sections séparées (comprenant des informations de profil, des statistiques et une barre d'outils).
• Une liste des messages envoyés et reçus d'un ami.
• Un nouveau formulaire de message.
• Une vue en 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:

générer un document word à partir de xml

• Cliquez sur un élément dans la liste des amis suivis pour afficher 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 balises. Cette vue est un exemple typique de celle qui ne peut pas être conçue dans Interface Builder, ni via StoryBoards ni NIB. Au lieu de cela, il est entièrement mis en œuvre via le code. Afin de maintenir le flux visuel du Storyboard, nous choisissons d'ajouter un contrôleur de vue vide au Storyboard, implémentons la vue du nuage de balises en tant que vue autonome et ajoutons 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 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'un application iOS sophistiquée dont les vues fondamentales relient nos trois principales approches 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 turtorial, les storyboards ajoutent une simplification notable à ios Conception de l'interface utilisateur et flux visuel. Ils éliminent également le code standard; 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 vivement 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 terminant, je tiens à souligner une chose: Évitez à tout prix d'utiliser l'outil de conception d'interface utilisateur iOS inapproprié . Si une vue n'est pas concevable avec un Storyboard, ou si elle peut être implémentée avec des NIB ou du code de manière plus simple, ne pas utilisez un 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, vous aideront dans votre formation de développeur.