Je vous ai présenté les concepts de l’Adaptive Design et le rôle du nouveau trigger XAML permettant de réagir à la taille de l’écran. Mais on peut faire beaucoup plus créant ses propres triggers ! C’est toute une librairie que je vous propose de découvrir aujourd’hui…
L’AdaptiveTrigger et ses cousins
Je ne m’étendrai pas sur le sujet puisqu’un billet récent lui est consacré avec le RelativePanel. Pour faire court donc, ce trigger XAML permet de rendre un VisualState actif sans action extérieure (ni code C# ni déclenchement d’animation ou autre). Ce trigger fourni avec UWP permet de tester la hauteur ou la largeur en pixels effectifs de la fenêtre et donc de réagir automatiquement aux changements de ces valeurs en proposant généralement une mise en page différente.
Mais la taille écran n’est pas la seule à présenter un intérêt pour personnaliser une page XAML !
On peut aussi vouloir utiliser le concept même en dehors de l’Adaptive Design. Réagir à une propriété du ViewModel, à la Famille de device sur laquelle l’application tourne, etc…
C’est donc toute une famille de triggers qui se cache derrière l’AdaptiveTrigger !
StateTriggerBase
Derrière toute famille se cache une mère… La classe mère d’AdaptiveTrigger est StateTriggerBase. Et cette maman là est porteuse potentiellement de centaines de petits !
Le principe pour créer son propre StateTrigger, donc un trigger qui fait changer d’état visuel (géré par le VisualStateManager de XAML), consiste simplement à créer une classe enfant de StateTriggerBase et d’y coder ce dont on à besoin … Toutes les idées sont donc possibles.
Voici un exemple de code qui permet de créer un DeviceFamilyTrigger, c’est à dire un trigger qui permettra d’activer un VisualState automatiquement selon la famille de device Windows 10 sur laquelle le code sera exécuté :
Trois règles :
- L’héritage de StateTrigger
- L’utilisation de SetActive pour activer (ou non) l’état visuel
- Rendre publique une propriété à tester (famille, résolution..)
Tout cela est donc fort simple et ouvre la porte à de nombreuses possibilités dont vous saurez tirer le meilleur parti j’en suis convaincu.
Une librairie de StateTriggers
Un californien signant “DotMorten” a mis en ligne sur GitHub une librairie contenant de nombreux StateTriggers qu’il a écrits. Il est donc possible de profiter de ce travail offert à la communauté tout comme vous pourrez participer et ajouter vos propres créations ou forker la librairire.
On la trouve à cette adresse : https://github.com/dotMorten/WindowsStateTriggers
Triggers par Famille de device, par simple égalité de valeur, détection du passage en plein écran, du type de saisie utilisée, par expression régulière, par orientation d’écran, etc. Le choix est déjà assez vaste mais surtout, puisque c’est Open Source, cela donne un sacré coup de pouce pour écrire de nouveaux StateTriggers en disposant de nombreux codes exemples !
Conclusion
UWP vient avec de nombreuses bonnes idées qui elles-mêmes ouvrent la voie vers plus de créativité. C’est une plateforme ouverte intellectuellement parlant. Le tout se reposant sur XAML. C’est plus qu’on ne pouvait espérer pour ce langage après le passage à vide de la fin de Silverlight et les idées un peu coincées de WinRT qui portaient plus de contraintes que d’espoir.
UWP devient une plateforme aussi agréable et ouverte à l’imagination que le fut Silverlight et que l’est toujours WPF (dont l’utilité reste entière puisque tournant en mode non sandboxé et sur tous les PC n’ayant pas Windows 10).
Stay Tuned !