Intermédiaire

L’utilisation du storyboard avec iOS et Xamarin iOS

xcode-6En matière de design d’application mobile, chaque système, que ce soit Windows Phone, Android ou iOS, aborde une manière différente de concevoir ses interfaces. Du côté d’iOS, Apple a opté pour le principe du storyboard. Cette gestion des vues, un peu particulière, demande de maîtriser un certain nombre de principes, qui sont valables pour une application développée en Swift, Objective-C ou encore pour Xamarin iOS.

Nous allons voir dans cet article les bases d’utilisation du storyboard, quelles sont les méthodes pour réaliser une interface adaptative, et en profiter pour réaliser un parallèle avec un projet Xamarin iOS, qui peut aussi utiliser ce concept.

Mais tout d’abord, kezaco le storyboard ?

f38b602f06208f037f3ff56caef395e7En soi, le terme de storyboard n’a pas grand-chose de nouveau, puisqu’il est souvent, voire systématiquement, utilisé dans le cinéma, la bd, ou autre domaine qui demande à raconter une histoire par l’image. C’est exactement le même principe pour les storyboards sous iOS (ou Mac), puisqu’ils vont finalement raconter l’histoire de l’application, ou plutôt son cycle d’utilisation, grâce à des écrans reliés entre eux, le tout dans un même fichier (ou pas, cela dépend de la taille de l’application, mais au moins une partie est regroupée). Cette gestion, dans un seul fichier, est ce qui fait sa grande différence avec le développement d’une application Android ou Windows Phone.

Le storyboard pour le développement iOS se présente comme ceci :

Capture d'écran 2015-08-23 23.40.28

Où et comment l’utiliser ?

Historiquement, le storyboard ne s’utilisait que sous Xcode (avec Interface Builder, qui a d’abord été un outil à part, mais qui est maintenant intégré à Xcode), puisque destiné aux applications Mac ou iOS. Depuis la montée en popularité de Xamarin et des outils qui l’accompagnent, la gestion du storyboard est maintenant également accessible depuis Xamarin Studio et Visual Studio.

tumblr_inline_mxaqdhiz3J1qzumo9Xamarin s’efforce de l’intégrer au mieux à ses derniers outils, néanmoins son utilisation reste moins fluide et intuitive que sous Xcode. A noter cependant que, pour le binding ou la manipulation d’éléments depuis le code dans le cadre d’une application Xamarin iOS, Xcode est moins pratique : en effet, il ne permet pas facilement de nommer les éléments, ce qui est indispensable pour effectuer un binding, forçant un peu le développeur à jongler entre Xcode et Xamarin Studio/Visual Studio.

Ce que ça a changé pour les développeursCeci est une révolution

Outre la meilleure lisibilité et la vision d’ensemble de l’application apportées par le storyboard, que ce soit pour un designer ou un développeur, Interface Builder permet de gérer très facilement la navigation entre les pages : un simple ctrl+clic et glissé d’une vue à une autre, et une petite fenêtre propose différents modes de navigation.

Interface Builder permet de créer les vues et les éléments avec un simple système de Drag&Drop d’éléments, et fournit un ensemble de paramètres pour un peu customiser la vue ; je dis un peu car non, Interface Builder ne permet pas de personnaliser comme on le souhaite des boutons, labels, ou autres éléments graphiques, pour lesquels il faudra malheureusement souvent passer par le code.

Malgré cet inconvénient, il faut avouer que construire ses vues en drag&dropant des éléments dans le storyboard est assez agréable… à condition de savoir comment positionner ces-dits éléments, pour respecter une cohérence entre les différents appareils ou l’orientation : c’est là que l’Auto Layout intervient !

L’auto layout

Ce système, qui existe depuis quelques années mais qui n’est pas encore systématique pour les développeurs (ce qui est bien dommage), facilite grandement le positionnement des éléments d’une interface, en imposant des contraintes entre chacun d’eux, ou avec les bords de l’écran.

Comme je le disais dans le paragraphe précédent, Auto Layout est fortement recommandé, voire même indispensable, pour avoir une interface propre et adaptative selon le périphérique et l’orientation.

 

La base d’Auto Layout : les contraintes

Les contraintes sont des valeurs mathématiques qui sont appliquées à un élément pour qu’il soit positionné dans l’écran. Un élément peut avoir une taille forcée et une position fixe (avec donc des valeurs fixes). Il peut également être centré verticalement et/ou horizontalement par rapport aux bords de l’écran, ou encore être positionné en fonction d’autres éléments graphiques.

Jusque-là rien de bien nouveau, donc aucune grande difficulté pour le développeur / designer / intégrateur. Mais on peut aussi avoir une taille dynamique, qui s’adapte à la place que prend son contenu, et c’est là qu’il faut faire attention.

Par exemple, le fait de pouvoir centrer deux labels côte à côte dans une vue, quel que soit la taille du texte, peut être un vrai casse-tête si on n’a pas compris la logique des contraintes.

L’astuce est de mettre, dans un premier temps, les deux labels dans une vue, qui aura juste comme contrainte d’avoir un alignement horizontal avec le conteneur, donc la “super” vue. Dans un second temps, on va demander au premier label “Natalie” d’être collé à gauche, en haut et en bas de son conteneur (pour ces deux derniers on va soit fixer au label à une hauteur fixe et lui définir un alignement vertical, soit lui donner des contraintes au-dessus et en dessous du label d’une valeur de 0). Idem pour le label “Portman” mais pour le côté droit (donc collé en haut, en bas et à droite), et pour finir on va fixer une contrainte horizontale entre les deux labels (de 8 par exemple).

Du coup, les deux labels vont avoir une position fixe dans la vue mais une taille dynamique, et la vue va pouvoir adapter sa taille en fonction des labels, tout en restant centrée.

LabelCenter ViewCenter

Et pour encore plus de possibilités d’adaptivité : les Size Class

Si les contraintes permettent de gérer le positionnement d’éléments dans une vue, il manque tout de même quelque chose pour compléter cela, et ce sont les Size Class qui vont s’en charger. Une Size Class est une représentation de la taille et de l’orientation d’un écran, et fournit donc au développeur de nouvelles possibilités pour construire l’interface. L’utilisation des Size Class peut s’activer ou se désactiver depuis Interface Builder.

Avant d’entrer dans le détail, une petite indication : le nom d’une Size Class a la forme suivante wTaille hTaille: le w correspond à la largeur et h à la hauteur. Voici quelques exemples :

  • Le format wAny hAny est celui qui correspond à tout type d’écran. Pour les contraintes générales, c’est celle-là qu’il faut utiliser.
  • wRegular hRegular est pour les iPad, sans distinction entre le portrait et le paysage.
  • wCompact hRegular correspond aux iPhones en portrait.
  • wCompact hAny correspond aux iPhone en portrait, jusqu’à 4,7 pouces.

AnyAny CompactAny RegularRegular

Ces Size Class sont les plus utilisées, mais le plus simple reste de tester les différentes possibilités et voir lesquelles correspondent le mieux au design voulu.

L’avantage avec ce système est qu’une contrainte peut être appliquée sur toutes les Size Class, ou n’être active que sur une (ou plusieurs). Cela permet de varier l’emplacement et la taille d’éléments selon l’orientation de la tablette, et donc d’avoir une interface parfaitement adaptative.

Mais comme rien n’est plus parlant qu’un exemple, en voici un rapide avec un placement d’éléments différent selon la taille de l’écran :

Depuis le fichier du storyboard, on commence par partir de la Size Class de base, donc Any Any. J’ai ajouté une UIView de couleur pour créer un header, ainsi qu’une image et deux labels. Voilà comment la vue sera visible sur n’importe quel appareil :

Capture d’écran 2015-08-14 à 12.07.30

Attaquons-nous maintenant à la disposition des éléments pour un iPad. En effet, comme l’écran est plus grand, j’aimerais en profiter pour avoir une plus grande image et la déplacer plus bas, avec les labels. Pour ça, je vais d’abord passer en mode wRegular hRegular. Après l’ajout des nouvelles contraintes, Interface Builder s’affole : il y a des conflits au sein de nos contraintes ! Et il le fait comprendre avec un indicateur rouge (voir capture d’écran ci-dessous). On peut voir dans le détail qu’effectivement, les deux hauteurs ne peuvent pas s’appliquer en même temps… Rien d’illogique.

Capture d'écran 2015-08-16 00.21.49 Capture d'écran 2015-08-16 00.33.04

ConstraintsConflictPour avoir une taille de mon image différente sur iPad, je vais donc accéder à ma contrainte (double-clic dessus), et je vais pouvoir voir la liste des Size Class sur laquelle cette contrainte est active. Il suffit ensuite de sélectionner la Size Class pour laquelle je veux que la contrainte soit active ou non : ici j’ai choisi de désactiver la contrainte qui forçait la Constraintlargeur de mon image à 100px dans le cas Regular Regular.

Il reste donc uniquement à désactiver la contrainte en trop, en décochant la Size Class concernée (voir capture d’écran ci-contre).

 

Un avantage est que, lorsqu’on sort de la taille Any Any et qu’on ajoute une nouvelle contrainte, Interface Builder comprend qu’il ne faut l’ajouter que dans cette configuration.

Après toutes les modifications nécessaires, voici comment la vue sera présentée sur un iPad :

Capture d’écran 2015-08-14 à 12.29.15

Attention lors de la définition des contraintes : il faut s’assurer, lors de la mise en place basique d’éléments et des contraintes, que le storyboard est en Any Any. Sinon, cela garantit un gros bazar et parfois plus d’une heure de définition de contraintes à refaire, ce qui n’est pas drôle du tout. Cela dit, Interface Builder met quand même en garde le développeur en affichant la barre des Size Class en bleu si on n’est pas en Any Any.

Quelles différences avec un projet Xamarin iOS ?

Maintenant que les présentations avec les principes du storyboard sont faites, nous pouvons nous intéresser au cas Xamarin iOS, avec un projet qui utilise le pattern Mvvm.

Le pattern Mvvm est souvent choisi pour ce type de projet, et qui dit Mvvm dit binding. Cela tombe bien car, contrairement au storyboard sous Xcode, l’interface fournie par Xamarin Studio et Visual Studio permet de nommer les composants, et donc de pouvoir binder les éléments graphiques aux viewmodel coté code behind. Petit parallèle avec WP et Android : les deux plateformes permettent un binding directement depuis le xaml ou xml mais, pour le moment, pour le développement Xamarin iOS, il faudra se contenter de cette solution.

Pour l’histoire, il y a encore quelques mois le designer sous Xamarin Studio ou Visual Studio n’était pas encore tout à fait au point. En effet, il fallait créer les éléments comme n’importe quel projet iOS sous Xcode, c’est-à-dire avec un clic-glissé déposé depuis le storyboard vers le fichier .h correspondant au controller. Malgré le côté plutôt contraignant et long à réaliser, cette manipulation était obligatoire pour accéder aux éléments côté code (et donc faire le binding, entre autres).

Heureusement, les différences s’arrêtent ici pour un projet simple. Cela se corse un peu avec la navigation…

Les limitations du storyboard

Comme je l’expliquais au début de l’article, même si Interface Builder et le storyboard facilitent la gestion des éléments et la conception d’une interface, Interface Builder laisse peu de place à la personnalisation, et cela est valable autant pour un projet iOS que Xamarin. Pour personnaliser un élément, il n’y a pas d’autre choix que de passer du côté obscur du code. Heureusement, il existe plusieurs méthodes pour le faire en quelques lignes et donc faciliter un peu cela. Mais un développeur habitué au XAML va rapidement regretter la customisation via Visual Studio ou Blend… On ne peut pas tout avoir !

Dans le cas d’un projet Xamarin iOS qui utilisemvvmcross un framework Mvvm comme MvvmCross, le storyboard perd son avantage de gestion de la navigation, puisque MvvmCross la surcharge en la rendant faisable très facilement depuis les ViewModel. La difficulté augmente d’un cran pour une application iPad avec les vues de type Master-Detail, car deux ViewModels sont affichés en même temps et il faut donc savoir comment gérer cela. Je vous invite à regarder le blog de Stuart Lodge, qui comporte notamment un  article sur les vues Master-Detail et d’autres tutoriels très pratiques.

Le mot de la fin

Dans cet article, nous avons eu l’occasion de balayer une partie des concepts présents dans la gestion des interfaces sous iOS, mais il reste encore bien des secrets et astuces à percer pour encore mieux maitriser le storyboard. La WWDC 2015 a réservé aux développeurs de bonnes surprises côté nouveautés et pratiques en matière d’UI, mais je n’en dirai pas plus pour garder le suspense jusqu’à mon prochain article dédié à ce sujet !

barneyStinsoWaitForIt

Nombre de vue : 762

COMMENTAIRES 2 commentaires

  1. […] d’or en termes de conférences techniques, et pour faire suite à mon précédent article sur les bases du storyboard, nous allons rester sur le même sujet et passer au niveau […]

  2. […] pour développer : l’IDE. Je l’avais déjà abordé dans un précédent article sur le fonctionnement du storyboard : pour le moment si on veut être efficace lors du développement d’un projet Xamarin, il […]

AJOUTER UN COMMENTAIRE