Dot.Blog

Depuis le début du mois précèdent je vous explique ce qu’est MAUI, d’où vient MAUI, ses avantages principaux. Mais pourquoi faut-il passer à MAUI d’où qu’on vienne de l’univers du développement ? 10 raisons à découvrir !

Pourquoi passer à MAUI ?

Bon, je vais passer le couplet lyrique sur la beauté de l’avenir, du sens de la découverte, du progrès en marche qu’on ne peut arrêter et toutes ces balivernes qui nous ont amené à creuser les inégalités dans nos propres pays et à ravager la planète. Non l’avenir n’est pas radieux ou alors dans le sens étymologique de « radiosus » - rayonnant - car le Dieu Râ va nous griller comme des merguez à la fête de l’Huma… A moins que ce ne soient les rayonnements alpha, beta et gamma d'une surprise "lumineuse" du fou de service à l' Est...

Il est vrai que j’écris cela en août et que ma clim n’arrive pas à descendre sous les 28°, alors d’un seul coup la réalité s’impose comme la canicule elle-même. Mais je pense avoir bien assez plombé l’ambiance, on va pouvoir remettre nos nez rouges et nos chapeaux pointus et revenir sous le chapiteau pour finir notre numéro de clown sous les applaudissements des actionnaires en délire. Business as usual.

Donc pourquoi opter pour MAUI pour ses développements mobiles (ou pas) ?

Première réponse, MAUI ou Xamarin.Forms vous participerez de la même façon au désastre écologique donc autant utiliser celui des deux qui est le mieux fichu… c’est-à-dire MAUI.

Je pourrais fermer le billet ici mais ça serait un peu court. Il existe effectivement des raisons rationnelles, outre la précédente, de choisir MAUI.

Un avenir meilleur

Non, je blague. Enfin, quoi que…

Il est vrai que MAUI a quelques arguments qui nous poussent à lui faire confiance (donc à voir l’avenir sous un meilleur jour, au moins pour le code). Après tout l’apocalypse arrivera quand elle le voudra entre-temps il faudra bien payer le loyer donc avoir fait le choix des meilleurs outils !

L'écosystème Xamarin se renforce depuis près d'une décennie maintenant et Xamarin.Forms a pris beaucoup de vitesse au cours des 7 à 8 dernières années. Bien que la promesse ait toujours été là, il y avait des coûts initiaux de développement/plateforme jusqu'à l'acquisition de Microsoft en 2016 - depuis lors, il n'y a plus eu de barrière à l'entrée (l’abonnement annuel était assez cher il faut le dire, faisant partie des premiers à m’intéresser à Xamarin, et ce blog en contient les traces, MVP ou pas, Xamarin était une société isolée qui faisait payer cher son produit, devenu gratuit par la grâce de Microsoft).

La communauté des développeurs a bien accueilli l'écosystème Xamarin en open source et la plate-forme désormais soutenue par Microsoft. Cependant, même les Xamarin.Forms ne semblaient pas tout à fait faire partie intégrante de .NET - c'était comme faire autre chose pour aller sur Android ou iOS. Même le nom de la société créatrice du produit était resté alors que Microsoft a plutôt l’habitude de tout changer rapidement lors de rachat d’entreprises. Malgré l’avancée spectaculaire que représentaient les Xamarin.Forms, l’approche multiplateforme ciblant iOS et Android restaient intrinsèquement difficiles avec de nombreuses dépendances, et les outils Xamarin ont montré quelques défauts au fil des ans, comme tout produit qui est utilisé par de nombreux développeurs d’ailleurs. Plus on est à se servir d’un soft plus on lui trouve des défauts différents. Mais on pouvait espérer un peu mieux il est vrai.

C’est toute cette perception qui change avec .NET MAUI et la vague .NET 6+ dont l’énergie est bien celle de CORE qui ne dit plus son nom depuis au moins .NET 5. Xamarin.iOS et Xamarin.Android sont désormais essentiellement du .NET pour iOS et Android, tous intégrés dans .NET 6+ lui-même, le vrai, pas Mono (par ailleurs incroyablement excellent pour un travail fait en parallèle hors des murs Microsoft)
MAUI repose ainsi de facto un .NET multiplateforme unifié. Les runtimes eux-mêmes sont unifiés dans .NET 6+ et les outils comme Visual Studio inspirent généralement confiance aux développeurs. La qualité de VS n’étant plus à démontrer, ni celle de .NET qui a échappé à l’éradication avant l’arrivée judicieuse du pragmatique Nadella à la tête de Microsoft.

Le bureau à porter de main

Xamarin.Forms est en grande partie une pile multiplateforme conçue pour les mobiles, principalement pour iOS, Android et d'autres plateformes comme Tizen. Cependant, atteindre le bureau avec Xamarin.Forms n'est pas totalement hors de portée : il existe des moteurs de rendu Xamarin.Forms pour Mac et WPF. Mais bien qu'elles aient du potentiel, ces solutions ont été en mode Aperçu et n'ont jamais vraiment acquis la confiance dont les entreprises avaient besoin pour créer des applications de bureau avec les Xamarin.Forms. Pourtant, un XF sous WPF cela aurait été parfait.

Au cours de son histoire récente qui se mêle à celle de Core plus ancien, il y a eu un énorme changement de paradigme dans l'évolution de .NET MAUI - le bureau est devenu un « citoyen de première classe » comme disent les américains, avec une prise en charge naturelle Windows et Mac. L’adoption de cette nouvelle stratégie par .NET MAUI ne réinvente pas la roue pour atteindre le bureau, il n’y a pas de compromis ni de bricolage. Pour ce faire, il utilise deux méthodes établies de WinUI 3 pour Windows et Mac Catalyst pour MacOs. WinUI 3 est le dernier framework UI/UX de bout en bout pour les applications Windows et fonctionne sur Win32 et .NET natif. Mac Catalyst est la solution d'Apple pour amener les applications iOS créées avec UIKit sur le bureau MacOs et augmenter l'expérience du développeur avec des API AppKit/plate-forme supplémentaires selon les besoins.

Avec .NET MAUI, les développeurs peuvent désormais cibler officiellement les applications mobiles et de bureau à partir de la même base de code. Bien sûr, il y a des considérations UX à prendre en compte selon les facteurs de forme, mais enfin nous y sommes !

L’arrivée de Blazor

Il ne s’agit pas du nom d’un superhéros ou d’un Youtubeur connu (genre Defakator qui pourchasse les fake news) mais bien d’un outil de développement et pas n’importe lequel !

Les développeurs .NET qui ont approché Blazor sont très enthousiastes, un framework Web moderne avec du code C# avant et arrière (code behind), exécuté côté serveur ou côté client avec Wasm. Il y a une « clientèle » pour Blazor et Wasm c’est une évidence et elle est différente de celle qui préfère ASP.NET. Mélanger Web et Apps natives avec le même code serait-il alors possible ?

.NET MAUI permet justement cela et apporte la qualité de Blazor au mobile et au bureau via les applications Blazor Hybrid. Essentiellement, .NET MAUI fournit l'amorçage de l'application avec un accès complet à l'API native, puis fournit une BlazorWebView magique, qui peut héberger des applications Blazor entières ou toute autre application Web construite avec les technologies SPA. Le composant BlazorWebView rend WebView2 sur Windows ou WKWebView sur macOS, les deux derniers composants WebView fournissant un excellent canevas pour les applications Blazor.

Les composants Blazor peuvent désormais coexister avec le code .NET MAUI, être stylisés, prendre en charge le routage et activer le partage de code avec les applications Web. Il s'agit d'un changement très bienvenu pour certains contextes applicatifs.

Le projet Unique

L'une des bêtes noires des développeurs avec les solutions Xamarin.Forms existantes est la nature des projets eux-mêmes : une bibliothèque .NET Standard partagée et des projets spécifiques à la plate-forme pour chaque plate-forme cible. Bien qu'il n'y ait rien d'intrinsèquement mauvais avec cette approche, la réalité pour la plupart des solutions Xamarin.Forms du monde réel est que cela donne des projets peu maniables – il y a de nombreuses choses spécifiques à chaque plate-forme que les développeurs doivent se rappeler de faire dans chaque projet, sans parler de s'assurer que les dépendances sont bien synchronisées.

.NET MAUI essaie de résoudre ce problème complexe avec ce qu'on appelle un « projet unique » - un projet consolidé de style SDK. Avec le multi-ciblage, les builds deviennent plus intelligents et savent comment produire des exécutables pour chaque plate-forme concernée, tout en préservant la cohérence de la base de code. Les artefacts/ressources d'application, tels que les polices et les images, peuvent désormais être partagés entre différentes plates-formes. Le système de génération .NET MAUI sait comment les récupérer pour chaque plate-forme ciblée. Vous voulez faire quelque chose de personnalisé pour chaque plate-forme ? Vous pouvez toujours remplacer et le faire - les éléments spécifiques à la plate-forme vont simplement dans des dossiers spécifiques, au lieu de projets lourds – c’est une solution simple et élégante.

Une architecture mieux pensée

.NET MAUI est une opportunité de repartir de zéro sur plusieurs fronts, et les équipes Microsoft n'ont pas laissé passer une telle occasion ! .NET MAUI fournit une bien meilleure architecture d'application, c’est un fait certain. Cela commence par la façon dont les applications sont amorcées - .NET MAUI adopte le constructeur d'hôte générique .NET. Cela apporte de la cohérence avec le reste de .NET et facilite l'injection de dépendances, la prise en charge de MVVM, l'enregistrement des gestionnaires/rendus et une plus grande extensibilité.

L'autre grand changement est la façon dont les applications .NET MAUI rendent l'interface utilisateur native sur chaque plate-forme. Auparavant, cela était piloté par un code appelé moteur de rendu qui prenait le balisage XAML Xamarin.Forms ou l'arborescence visuelle C# et rendait l'interface utilisateur native correspondante. Cependant, les moteurs de rendu avaient des liaisons étroites avec Xamarin.Forms, des dépendances directes sur la pile de l'interface utilisateur native et une personnalisation difficile. .NET MAUI adopte l'approche d'interface avec des gestionnaires - en faisant abstraction du rendu de l'interface utilisateur, des dépendances natives et du balisage de code. Cela ouvre l’horizon des gestionnaires .NET MAUI qui peuvent être utilisés à partir d'autres piles d'interface utilisateur, comme MVU avec Comet, F# ou Reactive UI.

L’accès au matériel

La plupart des appareils mobiles modernes sont bourrés de capteurs de tout genre, et les développeurs ne devraient pas avoir à écrire du Java/Swift ou tout autre code natif pour accéder aux API natives. La merveilleuse solution a été Xamarin.Essentials : un package NuGet qui permet de bénéficier de tous les accès à l'API native via du code C# abstrait.

Comment évolue l'accès aux API natives dans .NET MAUI ? Les développeurs ont désormais tout simplement son équivalent « .NET MAUI Essentials ». Toutes les API des périphériques spécifiques aux plates-formes sont regroupées dans une seule bibliothèque, qui est en fait intégrée directement dans .NET MAUI. Les développeurs doivent simplement activer <UseMaui>true</UseMaui>dans le fichier .csproj et importer l'espace de noms Microsoft.Maui.Essentials. Et toutes les API de périphériques multiplateformes deviennent disponibles sans effort et à partir du code C#, peu importe la cible !

La modification du visuel rendue plus rapide

L'un des fléaux avec le développement de Xamarin.Forms a été la boucle interne : à quelle vitesse les développeurs peuvent-ils apporter des modifications au balisage ou au code pendant que l'application est en cours d'exécution et les voir reflétées sur les simulateurs/appareils ?

La solution WPF, WinUI est simple est directe : on dispose d’un éditeur visuel interactif dans Visual Studio et même dans son grand frère à ce niveau, Blend. Le tout avec bien entendu toutes les subtilités de ces plateformes ultra sophistiquées (dessin vectoriel comme dans Illustrator, génération de XAML automatique qui traduit les ajouts au visuel en code, dispositif de données de tests pour afficher de vraies données en conception, etc…).

Mais sous Xamarin.Forms cet aspect n'a traditionnellement pas été une force par rapport à d'autres piles technologiques multiplateformes. Et il y a toujours beaucoup à faire. Des solutions intermédiaires comme XAML Previewer et Hot Restart ont aidé certains sans faire l’unanimité, mais .NET MAUI relève le défi au maximum, sans toutefois s’attaquer à la seule vraie solution, le designer visuel comme WPF/WinUI. Les contraintes du cross-plateforme semblent hélas rendre une telle option impossible, au moins pour l’instant. Restait donc à améliorer ce que les XF proposaient.

Bienvenu donc à « Hot Reload » - le moyen le plus rapide de voir les changements de code en cours d'exécution dans le simulateur ou les devices connectés à la machine de développement sans recompilation complète. Et pour aller plus loin, Hot Reload permet de fonctionner outre avec le code C# mais aussi avec les modifications de balisage d'arborescence visuelle .NET MAUI XAML. Code visuel ou code C#, le procédé ne couvre pas tout à fait 100% des situations mais il apporte un confort indéniable, principalement pour la conception visuelle.

Une belle boîte à outils

 De nombreux développeurs Xamarin.Forms utilisent des boîtes à outils supplémentaires pour améliorer leur expérience de développement, la plus populaire étant la boîte à outils de la communauté Xamarin qui évite de réinventer la roue pour de nombreux besoins récurrents.

Grâce aux efforts de Microsoft et de la communauté, l'expérience Toolkit fait également peau neuve dans .NET MAUI. Bienvenue dans la boîte à outils de la communauté .NET MAUI, un ensemble de bibliothèques destinées à améliorer l'expérience des développeurs .NET MAUI. La boîte à outils de la communauté .NET MAUI est disponible sous la forme de deux packages NuGet - CommunityToolkit.Maui et CommunityToolkit.Maui.Markup - tous deux faciles à ajouter aux applications .NET MAUI exécutées sur .NET 6. À partir d'une collection d'animations, de comportements, de convertisseurs et de contrôles UI autant que des méthodes C# fluides pour les interfaces utilisateur déclaratives - la boîte à outils de la communauté .NET MAUI est là pour vous aider.

On notera que la confusion avec Maui Essentials, déjà évoquée, est encore fréquente. Il s’agit bien de deux librairies différentes. Essentials se concentre plus sur l’accès aux devices et est intégré à MAUI. Quant au Toolkit MAUI de la communauté il s’intéresse plus aux contrôles visuels, aux behaviors, etc. Il existe donc bien deux boîtes à outils ultra complètes et open source qui couvrent une bonne partie des besoins, Essentials et le Community Toolkit.

Migration et modernisation assistée

Avec .NET 6 portant le tag LTS, de nombreuses entreprises envisagent de migrer et de moderniser leurs applications « legacy ». Vous avez des applications de bureau WinForms ou WPF ? L'assistant de mise à niveau .NET peut aider à mettre à jour leurs runtimes vers .NET 6+ et les développeurs peuvent alors commencer à moderniser la pile d'interface utilisateur par petits morceaux. .NET MAUI ouvre des opportunités intéressantes pour porter et migrer les applications de bureau existantes et atteindre de nouvelles plates-formes en dehors de Windows, tout en réutilisant une grande partie du code existant si les applications sont bien conçues. Et avec les applications Blazor Hybrid dans le panier, les développeurs ont une réelle chance de partager beaucoup de code entre les applications natives et Web. C’est une véritable opportunité de modernisation ou de remplacement des vieilles applications pour un environnement hautement unifié et cohérent.

Vous avez des applications Xamarin.Forms existantes ? La migration vers .NET MAUI ne devrait alors pas être pénible avec les bons outils. Utilisez .NET Upgrade Assistant , remappez les espaces de noms, mettez à jour toutes les dépendances vers .NET 6+ et enregistrez tous les services/rendus de compatibilité. On notera tout de même que pour bénéficier des meilleures performances de .NET MAUI il est préférable d’utiliser la nouvelle architecture des handlers. Néanmoins, les rendus personnalisés existants n'ont pas besoin d'être migrés immédiatement et peuvent être transférés vers .NET MAUI avec un minimum d'effort. Tout a été prévu !

Des contrôles visuels tiers gratuits (ou pas)

 Toute nouvelle pile technologique d'interface utilisateur comporte un risque évident : quelle part de la roue devons-nous réinventer ? Heureusement, .NET MAUI arrive dans un écosystème .NET qui sait déjà très bien faire une interface utilisateur multiplateforme. .NET MAUI propose des composants d'interface utilisateur similaires à ceux de Xamarin.Forms et la communauté intervient et interviendra pour combler le reste de l'écart et même aller plus loin. Que ce soit par le biais du Community Toolkit évoqué plus haut ou de packages indépendants, pour la plupart gratuits.

Toutefois certaines Apps réclament des artifices d’UI plus délicats à programmer, grilles complexes, animations particulières, charts, etc. Dans ce cas il existe aussi des composants tiers commerciaux comme Syncfusion ou Telerik. N’étant pas un fan des dépendances extérieures avec des librairies tierces je ne pousserai personne dans cette direction, mais j’avoue que parfois, même ponctuellement, ces composants peuvent faire gagner beaucoup de temps aux développeurs tout en apportant un niveau de confort et de service « pro » aux utilisateurs. Chacun fera ainsi en fonction de ses besoins et ceux de ses utilisateurs. Avec MAUI toutes les solutions sont sur la table !

Conclusion

Oui, il est temps de conclure. Ce grand tour du monde MAUI n’est qu’un aperçu des vastes possibilités offertes par cet environnement, de sa robustesse technique, des opportunités tentaculaires qu’il met à disposition des développeurs. MAUI ce sont les Xamarin.Forms en mieux posées sur un socle .NET rénové (Core), puissant, unifié et cross-plateforme par conception. Le tout entièrement maîtrisé par Microsoft, en open source, et en collaboration avec la communauté qui est très actives (les toolkits notamment).

J’espère que ce « cliché aérien » du pays MAUI vous aidera à mieux situer ses éléments constituants et ses avantages. N’hésitez pas à poser des questions, les commentaires sont là pour ça !

Stay Tuned !