Dot.Blog

Bien programmer une plateforme n’est pas qu’un exercice de besogneux du code, c’est aussi en comprendre l’esprit, les origines. MAUI d’où viens-tu ?

Qu'est-ce que .NET MAUI ?

.NET MAUI signifie Multi-platform App User Interface, c’est un framework qui permet de créer des Apps ayant une interface utilisateur travaillée ciblant de nombreuses plates-formes avec une seule base de code. Autant le code habituel que le code de l’UI.

Par Multi-plateforme nous entendons : Android, iOS, Windows, Linux et Mac. Ce qui est déjà beaucoup (mais d'autres peuvent venir s'y ajouter comme Tizen de Samsung).

Bref historique de MAUI

En mai 2020, lors de l'événement « Build » lors de la conférence "The Journey to One.NET", le directeur du programme Microsoft, Scott Hunter, et le directeur de la communauté, Scott Hanselman, ont annoncé ".NET MAUI l'évolution de Xamarin" et l'ont présenté dans toute la communauté .NET. L'idée et l'engagement de fournir .NET MAUI se sont précisés en février 2020 par la voix des program managers David Ortinau et James Montemagno .

De fait .NET MAUI est la dernière étape tant attendue de fusion de Xamarin dans Microsoft et de Mono dans un et un seul .NET

MAUI n'est pas seulement un changement de marque de Xamarin – Microsoft comme d’autres aimant rebaptiser leurs acquisitions pour donner l’impression qu’ils en sont depuis le début les inventeurs – mais représente un bouleversement sans heurt qui reprend les meilleures pratiques de Xamarin.Forms en évitant de nombreux échecs ou oublis, y compris les fonctionnalités demandées et souvent développées par la communauté Xamarin.

Xamarin et MAUI sont des projets Open Source menés par Microsoft. C’est important de le souligner. Le code source est disponible.

Xamarin.Forms avec la version 5 est devenu un produit mature, mais pour de nombreuses personnes cette versions 5 est tout simplement ce qu’ils auraient pensé naturel de trouver dans la version 1 !

.NET MAUI est la leçon tirée des succès et des échecs de Xamarin.Forms. C’est ce qui lui donne sa force, ce n’est pas un produit de remplacement créé à la va-vite, ce n’est pas une tentative de combler un manque (comme ce fut le cas pour la société Xamarin totalement étrangère à Microsoft au début), c’est un produit créé sur les bases d’un autre produit, lui-même mature et ayant permis d’engranger beaucoup d’expérience.

L'Open Source est une source d'idées et est également "un droit de réparer" , grâce à la gestion de Microsoft et aux efforts de la communauté, MAUI devrait être un produit stable et mature dès le premier jour.

Pour comprendre les besoins et les avantages de .NET MAUI, il est nécessaire de le comparer avec ses ancêtres Xamarin ‘Native’ et Xamarin.Forms.

Xamarin ‘Native’

Cette technologie a été créée pour développer des applications mobiles à l'aide d'API natives, d'interfaces utilisateur natives et d'outils natifs comme Android Studio et xCode en C#/.NET/MONO.

Son principal avantage est que le développeur peut créer une interface utilisateur parfaite au pixel près pour chaque plate-forme de manière native tout en programmant la partie code en C# / .NET.

Le principal problème avec Xamarin ‘Native’ est que vous devez connaître les API natives pour 2 plates-formes, ce qui est très lourd car même la quantité de connaissances pour une seule plate-forme est déjà beaucoup pour un développeur qui veut rester à jour.

L'interface utilisateur pour chaque plate-forme est effectuée séparément, donc si vous avez deux plates-formes Android et iOS, le travail devait être fait deux fois. La seule chose qui est sauvée ce sont les classes principales écrites en C# qui sont partageables jusqu’à un certain niveau entre les deux versions (Android / iOS).

La création d'interfaces utilisateur iOS et Android sont des technologies étrangères, dissemblables les unes des autres et non similaires aux technologies d'interface utilisateur .NET telles que WPF, UWP ou même Winforms ou ASP.NET, ce qui rend le développement décourageant.

De plus Xamarin ‘native’ se limite à deux plateformes mobiles oubliant la compatibilité avec Windows ou le Mac. Ce qui rendait sont utilisation encore plus canalisée dans un couloir de niches (même si ces niches pouvaient être rentables).

Xamarin.Forms (XF)

XF est une abstraction de proxy sur des API d'interface utilisateur natives permettant une interface utilisateur plus conviviale pour .NET sans avoir besoin d'utiliser xCode ou Android Studio.

XF a d'abord été proposé par Jason Smith de Xamarin/Microsoft comme technologie pour créer des applications et des prototypes de formulaires d'entreprise simples.

Une API UI XAML sur Android et iOS est ce que de nombreux développeurs ont toujours réclamé. Ils l'ont essayée et elle est  devenue quelque chose de bien plus que du simple prototypage, c'est-à-dire un outil pour écrire des applications de production utilisées par des millions d'utilisateurs.

Essayer de faire correspondre et de fusionner deux ou plusieurs API d'interface utilisateur inégales dans une abstraction était un défi pour Microsoft et la communauté .NET du monde entier.

Avant XF5 et le rechargement à chaud, la conception ‘pixel perfect’ était faisable, parfois difficile à réaliser, mais pour de nombreux nouveaux développeurs, ce n'était certainement pas très facile ni même vraiment accessible.

Bien plus qu’un rebranding

.NET MAUI s'intègre dans l'image de marque et la logique du branding Microsoft comme MS SQL, ASP.MVC… Il est même étonnant que le changement de nom n’ait pas eu lieu juste après le rachat comme cela se pratique partout et surtout chez Microsoft (appropriation de l’image, des clients, etc, c’est tout l’intérêt d’un rachat de société sur le même créneau).

Mais au-delà du rebranding nécessaire pour la cohérence de la ligne de produits Microsoft, il y avait bien plus. Bien que Xamarin.Forms soit maintenant un produit très mature et stable, il y avait encore de la place pour des améliorations et mieux les intégrer aux autres outils de développement Microsoft. Par exemple la fusion avec .NET Core et l’abandon de Mono, copie non officielle mais légale de .NET ne l’oublions pas, le hot reload qui facilite beaucoup le travail de l’UI, la suppression des rendus personnalisés remplacés par une technique plus rapide et plus puissante et le fameux projet unique, bref tout cela n’aurait pas été possible sans l’existence des XF mais la société Xamarin seule n’aurait certainement pas pu aller aussi loin. L’alliance d’un produit très attrayant et efficace à la puissance de Microsoft a donné naissance à MAUI. La ‘tête’ des XF est conservée presque intacte (l’abstraction des UI en XAML cross-plateforme) mais elle est posée sur le corp solide et nativement cross-plateforme de DotNet Core. Tout revient ainsi à sa place, comme si Microsoft avait d’emblée créé le produit de A à Z sans passer par la case Mono.

Les Xamarin.Forms vs MAUI

Souvent un petit dessin est plaisant mais ici c’est plutôt un petit tableau qui permettra de se rendre compte des différences :

^* The Windows implementation is Windows App SDK with WinUI 3.

^** These app models are no more experimental.

^*** Visual Studio Code will work by virtue of .NET unification, however not all experiences that make .NET MAUI development delightful (intellisense for example) may be enabled at the time of .NET 6 release.

Ce tableau est issu du travail important de David Ortineau et d’autres membres de la communauté et peut être consulté sur GitHub à cette adresse : https://github.com/dotnet/maui/wiki/Xamarin.Forms-vs-.NET-MAUI 
La validité de certaines annotations peut avoir changé depuis la parution du tableau, notamment les statuts "expérimental" ou en attendre de certaines features pour certains outils ou plateforme. MAUI est aujourd'hui en GA et l'ensemble des outils est donc jugé au point par Microsoft.

Conclusion

Il y aurait en réalité beaucoup de choses encore à dire sur la naissance MAUI qui entraîne de comprendre celle des Xamarin.Forms et avant elles de Xamarin ‘native’ et encore avant de la perte du marché des mobiles par Microsoft puis encore avant la mort de Silverlight et le manque de popularité de WPF pourtant le plus bel environnement de développement jamais inventé (mais paraissant un peu ésotérique à beaucoup de développeurs étrangers au monde XAML). Toute l’histoire de Microsoft mériterait aussi d’être évoqué, la perte de l’universalité verticale (toutes les machines gérées par Windows) pour finir par créer une universalité horizontale (les produits Microsoft pouvant tourner sur Mac, iOS…).

Mais ce sont des sujets que j’ai déjà abordé au fil des ans, à chaque fois qu’un de ses tournants de l’histoire est intervenu et a modifié le futur. Je renvoie le lecteur intéressé à tous mes anciens articles traitant de ces questions, et notamment « Se préparer au Big Shift de la stratégie de Microsoft » écrit en novembre 2011 alors que Silverlight venait d’être tué (https://www.e-naxos.com/Blog/post/Se-preparer-au-big-shift-de-la-strategie-Microsoft.aspx ). 11 ans nous séparent de ce papier, mais déjà il annonçait l’inéluctable mouvement de la verticalité à l’horizontalité. Pour ceux qui veulent savoir.

Maintenant vous êtes un peu plus intime avec MAUI et ses origines, vous comprendrez certainement mieux sa philosophie et surtout la nécessité de son avènement qui s'inscrit dans une continuité, une histoire certes un peu mouvementée, mais qui se termine bien. Un peu comme un équilibriste qui au milieu du chemin a failli tomber, tanguant à droite et à gauche, mais finissant fièrement le parcours au-dessus du vide et arrivant glorieux et en sécurité.

Stay Tuned !