Xamarin.Forms est déjà un ensemble mature et complet d’outils, compilateurs, templates et contrôles cross-plateformes basés sur .NET et XAML. Développer pour Android, iOS, UWP avec un seul code unifié est déjà en soi une prouesse. Pour un résultat natif, pas un bricolage hybride ou interprété. La version 3.0 pousse encore plus loin les choses…
Les évolutions
Chaque évolution de Xamarin.Forms 3.0 mérite un article, il sera donc difficile ici de faire beaucoup mieux que de vous donner un aperçu de sujets sur lesquels je reviendrai dans les semaines à venir.
La première chose intéressante à noter c’est l’intégration du travail de la communauté. Xamarin.Forms s’enrichit par le travail de son équipe de développement mais aussi par celui de la riche communauté qui s’est formée autour de ce produit. Et c’est une excellente nouvelle !
Autre point : la convergence avec XAML de WPF s’améliore encore… Avec l’une ces possibilités les plus marquantes pour qui manipule WPF…
Le Visual State Manager
Emblématique fonctionnalité de WPF ? Non pas tout à fait… C’est feu Silverlight qui le premier introduisit cette extraordinaire possibilité doublée d’un pilotage admirable dans Blend. Ce n’est qu’après, constatant le côté incontournable de cette évolution, qu’on vit apparaître le VSM sous WPF.
Aujourd’hui il arrive dans Xamarin.Forms. Silverlight n’est pas mort, son âme plane toujours sur XAML !
Sous WPF et Sliverlight qui sont (était) des systèmes graphiques totalement vectoriel le VSM a toujours été une merveille visuellement. Vous définissez des “états” de votre UI, vous leur donnez des noms, vous fixez éventuellement des transitions, des effets, et via une commande en C# vous faites passer votre UI d’un état à l’autre. Brusquement ou plutôt via des effets de transition du plus bel effet. Cela s’accorde de plus facilement avec MVVM puisque le ViewModel n’a besoin que d’envoyer des noms d’état à l’UI pour que celle-ci s’adapte sans avoir à connaître les contrôles eux-mêmes. Le nom de l’état est une string, le découplage est donc total. En envoyant le nom de l’état dans un message MVVM vers la View les puristes retrouve un découplage total. Car ce nom envoyé ne présume en rien de ce qui en est fait. Un ViewModel peut ainsi prévoir de passer de l’état “Idle” à l’état “Chargement en cours” sans même savoir ce que l’UI en fera. Charge au designer d’utiliser ou non ces changements d’états bien identifiés pour les matérialiser dans l’UI.
Sous Xamarin.Forms le procédé n’est pas graphiquement du même niveau puisque ce XAML là n’est pas vectoriel, pas même graphique. On y manipule des abstractions de contrôles qui seront remplacées par des contrôles natifs. Impossible de déformer lentement l’enveloppe d’un bouton en tirant sur les points de contrôle de la courbe de Bézier de son contour par exemple…
C’est pourquoi WPF est et restera la référence absolue pour XAML, sa plus belle et plus puissante implémentation. Le petit frère Silverlight est tombé au combat, mais ce qu’il a lui-même apporté à WPF vit toujours et se retrouve désormais dans Xamarin.Forms.
Je ne vais pas vous gaver d’images piquées ici ou là, d’extraits de codes sortis de leur contexte, je réserve une accueil un peu plus sérieux au VSM sous Xamarin.Forms, et j’en parlerai plus en détail dans un article entièrement consacré à ce procédé absolument génial et indispensable même.
Le FlexLayout
Encore un contrôle permet de disposer ses enfants selon des modes particuliers. Dans la lignée de tous les xxxLayout. Et à chaque fois nous gagnons en souplesse car chaque layout propose une stratégie de placement de ses enfants que les autres ne savent pas faire.
FlexLayout est inspiré de la FlexBox du Web très en vogue pour les mises en page aujourd’hui. Un outil de plus pour se sortir de tous les cas c’est toujours bon à prendre.
CSS
CSS ? Vade Retro Satana ! Un exorciste vite !
Oui… la Bête immonde fait sont apparition dans Xamarin.Forms… Les âmes sensibles sont prévenues. Cauchemars à prévoir.
Alors disons le tout de suite pour rassurer tout le monde, c’est une option. Une simple option. Totalement démagogique je vous l’accorde. Comme à chaque fois qu’on met des morceaux de web dans de vrais langages. C’est justifié systématiquement par le fait que cela permettra aux développeurs Web de venir plus facilement à la technologie en question. MS a fait ça avec UWP, on voit le résultat, Xamarin, aujourd’hui possession de MS a certainement été poussé à le faire pour les mêmes raisons.
Si vous vomissez CSS comme moi, oubliez cette “possibilité” immédiatement.
car Si XAML est excitant, CSS, satan l’habite…
Mais si vous êtes un pratiquant de messes noires (du genre à coder en JS par exemple), vous serez heureux de pouvoir faire vos mises en page Xamarin.Forms en CSS !
L'utilisation de CSS pour styliser vos mises en page est un moyen optimal (langue de put* inside) d'exprimer des styles en tandem avec XAML. Beaucoup de développeurs adorent la magie noire CSS à cause de leur expérience avec les technologies Web n’ayant pas eu la chance de connaître un vrai cursus professionnel en informatique. Mais les développeurs XAML, ces saints, restent accrochés à la définition des styles en XAML. Xamarin.Forms vous offre ces deux options de productivité! Utilisez ce qui vous rend le plus productif (mais de préférence XAML).
Les StyleSheets peut être ajouté en tant que fichiers CSS distincts dans votre projet, ou en ligne dans vos ressources. Une variété de sélecteurs communs sont disponibles pour composer vos styles.
C’est pas merveilleux ça le mariage de la carpe et du lapin ?
(le texte ci-dessus est en partie une traduction très libre de l’annonce officielle : “Cascading Style Sheets (CSS) is a natural companion to FlexLayout given their shared heritage. Using CSS to style your layouts is an optimal way to express styles in tandem with XAML. We know many of you love CSS from your experience with web technologies and we also recognize XAML developers love to express their styles in XAML. We are so excited to bring both of these productivity options to you! Use what makes you most productive.”)
Bon alors next !
Localisation gauche droite
Il y a des langues qui s’écrivent dans l’autre sens que le nôtre, l’hébreu, l’arabe par exemple. Pour gérer ces cas de façon simple il suffit désormais d’utiliser FlowDirection…
Support de WPF
Voilà une riche idée, rendre à César ce qui lui appartient, un juste retour des choses… C’est un travail communautaire, ça avance mais ce n’est pas encore terminé à 100%. Ce projet permet d’ajouter WPF aux cibles d’une solution Xamarin.Forms… Vous pouvez accéder ici au statut d’avancement de ce chantier très intéressant !
Conclusion
Xamarin.Forms ne déçoit pas, chaque release apporte son lot d’améliorations. On peut certes regretter que des satanistes venus du Web aient noyauté l’équipe de développement pour souiller la pureté mariale de XAML, mais bon, ayons l’esprit large en sachant que cette mode d’ajouter du JS ou du CSS un peu partout pour faire venir des développeurs Web n’a jamais fonctionné qu’à la marge alors restons zen… 
Voire la communauté travailler au support de WPF est une excellente chose en revanche. Voire des inventions géniales de Silverlight faire leur comeback par la grande porte est aussi un plaisir.
Il y a vraiment du très bon dans cette version 3.0.
Je vais y revenir forcément.
J’ai eu 4 / 5 mois de charge un peu plus dense et j’ai moins écrit dans Dot.Blog, mais ne vous inquiétez pas, cela va revenir ! Alors…
Stay Tuned !