Comment gérer l’apparence de vos applications iOS ?

Problématique

Il y a différents moyens de personnaliser l’interface d’une application iOS. Le plus simple est de modifier les attributs des vues dans les fichiers xib ou storyboard (pour les non initiés il s’agit des fichiers représentant l’interface graphique construite via Xcode) mais bien souvent cela ne suffit pas et on est obligé d’ajouter quelques lignes de codes pour arriver à nos fins. On se retrouve alors face à différents problèmes :

• Si l’on veut modifier l’apparence d’un composant commun à plusieurs vues, tel que la police du titre dans la barre de navigation de l’application, on devra le faire sur toutes les vues (si on n’emploie que les storyboards, ou xib).
• La déclaration des polices ou la personnalisation de boutons peut être dupliquée dans le code si le développement de l’application n’est pas bien encadré.
• Si l’on veut optimiser notre interface via des méthodes de “split test” (A/B testing) et que le code de présentation de l’IHM n’est pas factorisé, on perdra en efficacité.

Dans ce billet je vais vous présenter une solution via un exemple disponible sur github. Elle est issue de la session 216 du WWDC de 2012.

Mise en oeuvre

L’exemple est simple et a pour but de ne décrire que le principe d’architecture logicielle. D’un point de vue graphique, on n’a qu’un seul écran :

Celui-ci est composé :

• D’une barre de navigation comportant un titre,
• De trois labels: - “View Title”
• “View Subtitle”
• “Lorem ipsum…”

Le code mis en oeuvre permettra de :

• Modifier les composants communs (barre de navigation), ceux qui peuvent se trouver sur plusieurs vues (les labels titre, sous titre, corps de texte), et ceux propres à une vue (la couleur de fond de la vue courante),
• Factoriser le code de présentation,
• Permettre de rapidement mettre en place des variantes de cette présentation (présentation client, A/B testing) de façon isolée.

L’architecture utilisée repose sur l’utilisation d’un “Protocol” (l’équivalent d’une interface Java) déclarant les méthodes utilisées pour personnaliser notre IHM. Voici ce que l’on obtient pour notre exemple :

Ce Protocol est ensuite implémenté dans une classe qui décrit notre thème. L’héritage permet ensuite d’apporter des variantes à notre thème et ce  de façon isolée (tests clients ou A/B testing). On peut ainsi avoir plusieurs thèmes déclarés dans notre application. Afin de ne déclarer le thème utilisé qu’à un seul endroit, on utilise une autre classe :

La méthode sharedTheme permet d’instancier le thème utilisé
:

La méthode customizeAppearance permet quant à elle de personnaliser l’apparence des composants communs (barre de navigation, barre d’onglet, Progress View,…) et sera appelée dans le Delegate de l’application :

Les autres méthodes sont à appeler au besoin dans les méthodes viewDidLoad de chaque vue :

L’utilisation des principes de programmation défensives permettent une utilisation plus souple de l’implémentation des thèmes :

Dans l’exemple ci-dessus, on peut par exemple voir que l’implémentation du thème peut déclarer (ou pas) une police et une couleur particulière.

Voici un exemple utilisant les couleurs du site Les Vendredis du Webdesign :

Cette capture d’écran est issue d’iOS 5, on notera que j’ai rencontré quelques problèmes avec iOS 6, le titre ne s’affiche pas correctement :

Ce problème est relaté dans le forum Apple mais ne semble pas avoir été résolu sur iOS6, ou du moins pour les simulateurs. Pour ceux qui ont besoin d’avoir un titre avec une police personnalisée, je conseille donc de le représenter sous forme d’image.

Conclusion

L’exemple que j’ai présenté ici montre l’intérêt de la méthode pour avoir un code plus maintenable et évolutif. On peut aussi imaginer qu’elle permette de réutiliser une partie du design pour la conception de plusieurs applications. En effet, en utilisant l’héritage entre les thèmes, on peut imaginer créer différents types de thèmes: des thèmes de bas niveau (pour la typographie par exemple) utilisés pour un squelette applicatif ou la réutilisation de règles typographiques et des thèmes de haut niveau pour des applications partageant la même identité visuelle (plusieurs applications pour un même groupe ou client).

Cet exemple ne montre cependant pas les différentes possibilités de personnalisation des différents composants iOS. Ceux-ci sont largement décrits dans la session 216 du WWDC 2012. De plus, un exemple de code est disponible pour les personnes enregistrées en tant que développeurs Apple. Je vous encourage donc à vous y reporter pour pouvoir appliquer cette méthode dans vos projets iOS.

Pour les développeurs qui souhaitent aller plus loin dans la conception graphique et ergonomique, je conseille de visionner cette présentation. Bien qu’adaptée au Web Design, elle décrit des principes de base qui peuvent être utilisés dans la conception d’applications mobiles.