Dot.Blog

Les 4 articles précédents ont permis de construire une App de base plus réaliste qu’un Hello World, abordant MVVM, les tests unitaires, l’injection de dépendances et bien d’autres choses encore. Mais il reste la « final touch », le style…

Cet article fait partie d’une série de 5 épisodes dont voici les liens :
1- https://www.e-naxos.com/Blog/post/un-projet-zero-maui-realiste-partie-1-5-creation-du-projet-et-mvvm.aspx (Création du projet et MVVM)

2 - https://www.e-naxos.com/Blog/post/un-projet-zero-maui-realiste-partie-2-5-les-tests-unitaires.aspx (Les tests unitaires)
3 - https://www.e-naxos.com/Blog/post/un-projet-zero-maui-realiste-partie-3-5-modele-services-et-injection-de-dependances.aspx (Modèle, Services et injection de dépendances !)
4 - https://www.e-naxos.com/Blog/post/un-projet-zero-maui-realiste-partie-4-5-les-vues-et-le-shell.aspx (Les Vues et le Shell)
5 - https://www.e-naxos.com/Blog/post/un-projet-zero-maui-realiste-partie-5-5-styler-l-app.aspx (Styler l’App)

Les Styles

Une App n’est pas que du code. Cela peut sembler évident mais ça va mieux en le disant. Une App c’est aussi et avant une Expérience Utilisateur, la fameuse UX. Et l’UX passe en partie par l’UI.

Le soin apporté à la conception de l’UI sera déterminant dans l’adoption d’une App, comme l’UX générale et la qualité du code. Il n’y a pas de bas morceaux dans une App… Tout est bon ou doit l’être.

Si MAUI nous aide beaucoup à produire code de qualité, il met aussi à notre disposition des outils permettant de concevoir des UI de façon tout aussi intelligentes, c’est-à-dire DRY, bien structurées, facilement modifiables, et tout ce que nous avons vu jusqu’à maintenant pour garantir la qualité du code.

Dans cet état d’esprit les Styles jouent un rôle essentiel.

Les styles sont ainsi un ensemble d’instruction XAML regroupées en un même endroit et sous un même nom éventuellement ce qui permet de les utiliser partout dans l’App ou partout sur une même page (tout dépend de l’endroit où le style est déclaré).

Pour mieux comprendre l’intérêt pratique des styles (ils ont d’autres intérêts aussi) prenons l’exemple le plus simple, un bouton :

Dont le code XAML est :

Imaginons que je veuille que ce bouton utilise une des fontes enregistrées dans MauiProgramm.cs, que le texte soit noir, que le fond soit orange et que les coins soient carrés :

Le code XAML sera alors :

Ce n’est pas très long, c’est très explicite (l’avantage de XAML), c’est ce qu’on appelle un « style explicite » par opposition aux style implicites qui peuvent être définis au niveau de la page ou des styles globaux définis dans App.xaml. Mais entre nous si je veux que tous les boutons de l’App soient ainsi cela risque de devenir pénible de répéter partout ce même code de style !

Le problème est d’ailleurs plus complexe dans la réalité puisqu’il peut y avoir certains boutons ayant un style particulier et ainsi plusieurs styles peuvent coexister et seront utilisés dans des contextes différents (les boutons de validations qu’on peut vouloir rond sur fond vert, les boutons d’action qui seront rouges avec un des coins arrondis… que sais-je, tout dépendra de l’UX et de l’UI qui en découlera).

Pour régler ces problèmes il faudrait pouvoir créer des « styles » qui soit s’appliqueraient à toute une classe de contrôles (voire à tous), soit à une classe bien précise, soit ponctuellement par code (il serait plus facile de dire « style = machin » que de reproduire tout le style « machin » à chaque fois).

Cela existe bien entendu.

Restylons l’App

Bon, soyons moins présomptueux, cette série de 5 articles est un tour de découverte, une incitation à en apprendre plus sur tous les domaines que nous avons visité. Les styles font appel à une syntaxe et à des connaissances de XAML qui ne peuvent tenir en quelques paragraphes. Et si je vous propose une App entière relookée sans expliquer le code cela ne servira à rien. Je vais donc me contenter ici de mettre l’accent sur cette étape importante et les mécanismes à mettre en œuvre. D’autres papiers viendront éclairer la façon exacte de procéder (un petit tour par la doc Microsoft peut s’avérer utile aussi : https://docs.microsoft.com/en-us/dotnet/maui/user-interface/styles/xaml !).

Pour l’instant, sous Windows, notre App ressemble à cela, au détail près des outils XAML c’est identique à la version Android. Il y a un truc louche là-dessous…

C’est beaucoup plus joli que les Apps par défaut des premières versions des Xamarin.Forms ! Mais nous voulons personnaliser l’aspect à notre guise, en utilisant des Styles.

En réalité l’App par défaut contient déjà des styles… Ce n’est pas un bouton « brut » qu’on voit par défaut même si on ne le sait pas à première vue du code où rien ne semble apparaitre… Et c’est ce qui explique que le look est identique sous Windows et Android, c’est le même style choisi par le développeur qui est appliqué et non les styles natifs des plateformes. Dans le répertoire « resources » on trouve plein de choses dont un répertoire « styles » qui contient déjà des définitions pour les couleurs, et les styles :

Et dans le fichier Styles.xaml on trouve :

En fait le bouton par défaut du projet par défaut de MAUI est loin d’être brut de fonderie ! Il bénéficie déjà de tout un travail de styling, et c’est ça qui le rend plus sympa visuellement !

On voit que le code utilise des couleurs qui sont définies dans le fichier Colors.xaml. Cette séparation est recommandée.

Le fichier des couleurs permet de créer des « thèmes » facilement en ne touchant qu’un seul endroit de l’App, et le fichier des styles permet de la même façon de pouvoir modifier le look des objets visuels sans toucher à autre chose. Futé !

Travailler ainsi réclame malgré tout un peu d’organisation c’est évident. Mais c’est tellement payant que l’effort est rentable.

Si on supprime les fichiers dans le répertoire « Styles » et qu’on supprimer la définition des ressources dans App.xaml, l’App va continuer à marcher … elle sera moche (pas très jolie en tout cas), c’est tout :

Bouton par défaut, pas de couleurs, pas de titre bien posé. Et encore je n’ai pas supprimé la fonte qui donne déjà un meilleur look… Je pense que vous comprendrez aisément à ce petit test visuel toute l’importance des styles et de leur bonne utilisation. Lisez la doc MS dont l’adresse est donnée plus haut pour voir toutes les possibilités que le procédé offre, comme par exemple le VisualStateManager.

Le code de l’App

Cette App que nous avons modifié au long des articles n’a rien d’extraordinaire en termes de code, mais elle présente certains aspects qui méritent peut-être que vous y jetiez un œil de plus près. Cela fait aussi un excellent terrain de jeu pour vos expérimentations ! Le code source complet se trouve en lien en fin d’article sous la forme d’un fichier Zip. Les deux projets qui s’y trouvent doivent être placés dans un même répertoire, les deux au même niveau.

Conclusion de la série de 5 articles

Aller dans le détail de chaque point technique abordé dans cette série de 5 articles n’était pas le but (impossible à tenir de toute façon). Bien d’autres papiers viendront compléter tout cela, tout comme les docs officielles. Le but était juste de partir du projet par défaut de MAUI et de l’améliorer un peu pour y intégrer tout (ou presque) ce qui fait un véritable projet de départ. Pattern MVVM, tests unitaires, styles, couleurs, injection de dépendances… Nous en avons vu des choses ! Il faudra toutes les creuser. Beaucoup de sujets ont déjà été traité par Dot.Blog (MVVM, l’injection de dépendances…) et d’autres le seront bientôt !

Alors pour aller plus loin…

Stay Tuned !

Le code source de la solution en fin de série de 5 épisodes :