Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

MAUI - Qu’est-ce c’est et pourquoi l’adopter ?

Microsoft a annoncé il y a plus d'un an son nouveau cadre pour la création d'applications modernes multiplateformes sur mobile et ordinateur de bureau. Il l'appelle MAUI

MAUI

Microsoft a annoncé il y a plus d'un an son nouveau cadre pour la création d'applications modernes multiplateformes sur mobile et ordinateur de bureau. Il l'appelle MAUI. Nous ne parlons pas ici de la plage de Maui, MAUI est un acronyme qui signifie Multi-platform App UI. Ce framework est l'évolution des Xamarin.Forms. Ce cadre apporte plusieurs fonctionnalités pour rendre extrêmement facile la création d'applications cross-plateformes, modernes et robustes.

imageAu moment de la rédaction de cet article, .NET MAUI est déjà passé en GA et ne cessera d’évoluer. Dans cet article, nous apprendrons ce qu'est vraiment MAUI, et nous allons plonger dans ce que .NET MAUI a à nous offrir, nous les développeurs mobiles avides de moyens productifs pour créer des applications tueuses dans le monde réel !



Que couvrirons-nous ici ?

  • Une introduction à .NET MAUI (Qu'est-ce que MAUI)
  • 6 façons dont .NET MAUI permet aux développeurs d'applications de travailler beaucoup plus facilement et plus rapidement
  • 5 raisons pour lesquelles vous devriez choisir MAUI plutôt que d'autres frameworks multiplateformes comme Flutter, React Native, Native Script, etc.
  • Mise à niveau des applications Xamarin Forms vers MAUI

Qu'est-ce que MAUI ? Présentation de .NET MAUI

.NET MAUI est l’évolution des Xamarin Forms. MAUI prend les meilleures idées des XF, supprime les points faibles, introduit une nouvelle architecture plus rapide et plus facile à utiliser, améliore les performances, ajoute de nouvelles fonctionnalités et abaisse la barrière de la convivialité. Et surtout MAUI se fonde sur Dotnet 6 et suivant, c’est-à-dire CORE qui par essence est cross-plateforme pour de la compilation native.

Toutefois je vous avais déjà proposé en avant-goût une première et rapide présentation de MAUI à lire dans l’article suivant :

https://www.e-naxos.com/Blog/post/Presentation-de-MAUI-Multi-plateform-App-UI.aspx

Et avec des gens bien que vous connaissez certainement (Denis Voituron et Richard Clark), j’avais participé au Podcast suivant qui vous en dira encore un peu plus et dans la bonne humeur :

https://www.youtube.com/watch?v=pEkP2PrDkZE

Comment MAUI facilite-t-il le travail des développeurs d'applications ?

En tant que développeur .NET et Xamarin Forms de longue date, j'ai parcouru ce que Xamarin avait à offrir. Je suis avec Xamarin depuis l'époque où l'outillage était vraiment un cauchemar à gérer. Vous ne vous en êtes pas rendu compte à l’époque car je faisais tout mon possible pour rendre l’enfer tout à fait vivable . J'ai vu Xamarin Forms évoluer d'un framework pour créer des applications de base à un framework pour des scénarios prêts pour la production. Avec les nombreuses améliorations apportées (visuels, moteurs de rendu, Shell, etc.) Et de ce que j'ai remarqué après avoir regardé le développement de MAUI, l'équipe qui a construit MAUI s’est basée exactement sur ce que nous, la communauté, voulions dans les Xamarin Forms ou tout autre cross- cadre de plate-forme pour être utilisable dans le monde réel.

1- Abstraction des configurations répétitives de plates-formes

En tant que développeur mobile, il y a certaines tâches que je déteste refaire tout le temps. Par exemple,

  • Ajout de polices d'application
  • Déterminer l'écran de démarrage de l'application, l'icône de l'application,
  • Ajouter des images avec des tailles appropriées à chaque plate-forme etc…

Tout cela, sachant que chaque plate-forme (Android, iOS, WinUI…) a sa propre façon d'ajouter des images ou de configurer des icônes ou des écrans de démarrage au projet. .NET MAUI est conçu à partir de zéro pour résumer ces tâches que les développeurs mobiles effectuent de manière répétitive.

Comment tirer parti de ces abstractions avec MAUI, c'est facile. Dans le fichier csproj, vous pouvez ajouter des balises pour les configurer.

<MauiImage Include="Resources\Images\*" />

La balise ci-dessus se termine par un caractère générique, indiquant que chaque fichier svg, png etc… du dossier Images doit être utilisé comme image. Cela signifie que les différentes tailles d'image nécessaires pour les autres plates-formes seront générées automatiquement en fonction des images trouvées dans ce dossier.

L'approche que vous préférerez, j'en suis sûr, consistera simplement à déposer vos fichiers SVG dans le dossier images et à laisser MAUI faire sa magie pour la mise à l'échelle abstraite, le redimensionnement, etc.

NOTEZ que, vous pouvez toujours accéder aux dossiers de votre plate-forme et ajouter vos images dans les dossiers de ressources appropriés, comme vous le faisiez traditionnellement.

<MauiFont Include="Resources\Fonts\*" />

Il en va de même pour la balise « MauiFont ». Ci-dessous, vous pouvez facilement définir directement l'icône de votre application et l'écran de démarrage.

<MauiIcon Include="Resources\appicon.svg"

  ForegroundFile="Resources\appiconfg.svg"

  Color="#081B25" />

<MauiFont Include="Resources\Fonts\*.otf" />

<MauiSplashScreen Include="Resources\appiconfg.svg"

  Color="#081B25" />

2- Le projet unique MAUI

.NET MAUI nous permet de créer des applications multiplateformes dans un seul projet. C'est génial, car nous pouvons tout faire au même endroit et MAUI résume et remplace également certaines tâches spécifiques au projet qui devaient être répétées plusieurs fois sur chaque projet avec les anciennes applications Xamarin Forms. Ceux-ci incluent l'ajout de polices, d'images, d'icônes d'application, etc. Vous le faites une fois, et cela fonctionne automatiquement partout !

Pour retrouver vos fichiers de plateforme (fichiers propres à chaque plateforme ciblée par votre application MAUI), il vous faudra désormais descendre dans le dossier des plateformes. Ce dossier contient tout ce que vous aviez l'habitude de trouver dans vos projets iOS et Android. Ceux-ci comprennent :

  • L'activité principale,
  • Les dossiers de ressources
  • Le délégué App… et bien plus encore.

C'est quelque chose qui n'a sûrement jamais été fait auparavant. Et l'équipe de Visual Studio a dû créer de nouvelles fonctionnalités pour s'adapter à cette structure de projet unique. Pour cibler un cadre spécifique pour les builds, vous devrez le faire via le menu déroulant sur le bouton d'exécution de Visual Studio. Pas plus compliqué que cela…

image

Comment fonctionne cette structure de projet unique sous le capot ?

Ce type de projet magique est possible grâce au « multi-ciblage », c'est un concept né il y a quelques années dans l’écosystème .NET. Il y a quelques années, vous pouviez voir certains responsables de bibliothèques de la communauté adopter le multi-ciblage dans leurs bibliothèques Xamarin. Le multi-ciblage consiste à cibler plusieurs frameworks dans votre application ou votre bibliothèque. Cela se fait en modifiant l'option "TargetFrameworks" de votre projet, en éditant votre projet dans un éditeur de texte, puis en ajoutant le TFM (Target Framework Moniker) du framework cible que vous souhaitez ajouter.

Ces TFM incluent (net6.0-android pour Android, net6.0-ios pour iOS, netstandard2.1 pour les normes .NET 2.1 etc.) Vous pouvez trouver la liste de tous les TFM disponibles ici. Cette fonctionnalité nous permet désormais d'ajouter des packages de nuggets au projet pour une cible spécifique uniquement et de compiler pour chaque plate-forme répertoriée.

3- Personnalisez tout avec les Handlers

Un Handler MAUI est un concept architectural utilisé par .NET MAUI pour mapper les contrôles multiplateformes à leur implémentation native. Les Handlers sont utilisés à la place des moteurs de rendu dans .NET MAUI car ils offrent plusieurs avantages. Rapidité, simplicité d’utilisation, facilement personnalisable etc…

L'utilisation de gestionnaires pour personnaliser vos contrôles est très simple. Je ne couvrirai pas cela en détail ici, on y reviendra plus tard.

L'architecture des gestionnaires a été introduite pour offrir plusieurs avantages, notamment :

De meilleures performances. Plus d'analyse/réflexion d'assemblage, les contrôles natifs ne sont pas enveloppés dans des conteneurs inutiles (des moteurs de rendu rapides sont utilisés à la place).

Facilité d’utilisation. Il est plus facile de personnaliser les commandes sur place. Nous n'avons plus besoin d'écrire des classes entières avec du code passe-partout juste pour changer quelques propriétés d'un contrôle.

Un code plus maintenable peut être obtenu, avec une meilleure API. Les gestionnaires sont plus faciles à implémenter, et avec l'injection de dépendances et le modèle de générateur d'hôte, nous pouvons spécifier de quel gestionnaire nous avons besoin pour quel type en un seul endroit. par exemple, ci-dessous l’extrait de code montre comment enregistrer un gestionnaire spécifique pour un contrôle.

        public static MauiApp CreateMauiApp()

        {

            var builder = MauiApp.CreateBuilder();

            builder

                .UseMauiApp<App>()       

                .ConfigureMauiHandlers(handlers =>

                {

                    handlers.AddHandler(typeof(MyEntry), typeof(MyEntryHandler));

                });    

            return builder.Build();   

        }

Pour mieux comprendre l'impact positif que les gestionnaires ont sur les anciens renderers des Xamarin Forms , nous devons mettre en évidence les inconvénients de ces derniers...

Les moteurs de rendu (renderers) nécessitaient une analyse de l'assembly , ce qui impliquait que Xamarin Forms analysait vos assembly et, par réflexion, enregistrait les types appropriés pour vos composants d'interface utilisateur. Ce processus était lent et avait un impact négatif sur les performances des vues Xamarin Forms.

L'accès aux contrôles spécifiques à la plate-forme à partir du projet partagé est difficile avec les moteurs de rendu. Il existe des moyens d'accéder aux commandes spécifiques à la plate-forme via des renderers, mais ce n'était pas facile.

Pour personnaliser un aspect d'un contrôle, vous deviez écrire beaucoup de code passe-partout pour faire une seule chose. par exemple, si vous vouliez une entrée sans bordures, vous deviez connaître "Elementchanged", "ExportRenderer", Vérifier si le contrôle est nul etc... Créer un moteur de rendu pour cela nécessitait beaucoup de code pour faire une seule chose.

Utilisation des Renderers dans .NET MAUI

Vous pouvez toujours utiliser les anciens moteurs de rendu dans .NET MAUI. Il est encore plus facile d'utiliser des moteurs de rendu dans MAUI que de les utiliser dans Xamarin Forms. Puisque vous n'aurez plus besoin de beaucoup d'efforts. Si vous avez un moteur de rendu que vous souhaitez porter sur MAUI, dans l’AppBuilder , précisez simplement le type de contrôle pour lequel vous souhaitez utiliser votre moteur de rendu. Voici un exemple.

appBuilder.ConfigureMauiHandlers(handlers =>

{

   handlers.AddCompatibilityRenderer(typeof(MyButton), typeof(MyButtonRenderer));

});

4- Contrôles dessinés avec Microsoft.Maui.Graphics (Material, FluentUI, Cuppertino)

Avec MAUI, vous pouvez créer vos interfaces utilisateur avec des contrôles existants (ou dessiner vos contrôles) qui se ressemblent sur toutes les plates-formes, et qui pourraient être thématiques avec Fluent UI, Material UI, etc. Devoir coder une vue et lui donner le même aspect sur chaque plate-forme est quelque chose qui a été demandé il y a longtemps dans Xamarin Forms. L'équipe Xamarin a entendu notre cri (et celui des équipes de support clients des éditeurs !) et nous a apporté des visuels graphiques. C'était un remède utile à ce problème, mais ce n'était vraiment pas suffisant. MAUI apporte le concept d'interface utilisateur dessinée à un autre niveau. Bien entendu rien n’égalera jamais la puissance du XAML original, celui de WPF, Silverlight, Windows Phone etc. Mais je crains qu’il faille que nous fassions une croix sur une telle puissance, hélas. Toutefois MAUI offre beaucoup plus que les Xamarin Forms et l’avancée est énorme.

Microsoft.MAUI.Graphics est une bibliothèque graphique multiplateforme pour iOS, Android, Windows, MacOS, Tizen et Linux écrite entièrement en C # qui fournit une API commune pour cibler plusieurs abstractions vous permettant de partager votre code de dessin entre les plates-formes ou de mélanger et assortir les graphiques implémentations dans une application singulière.

Pour mieux comprendre comment cette bibliothèque va vous fournir une API unifiée pour dessiner vos contrôles, et utiliser des contrôles déjà dessinés, voici un schéma montrant les API abstraites sur chaque plateforme.

image

.NET MAUI a introduit la vue Graphics, qui fonctionne comme le canevas de skia pour dessiner des contrôles dessus. Cette vue nous permettra de dessiner tous les contrôles et d'exposer les événements pour les interactions. L'utilisation de ces contrôles dessinés dans votre projet MAUI peut être effectuée facilement en choisissant simplement les gestionnaires appropriés (Fluent, Material, Cuppertino) dans le constructeur d'applications Maui.

5- Le modèle de constructeur d'hôte

Il s'agit d'un modèle de conception utilisé pour échafauder l'ensemble de votre application en un seul point d'entrée, simple, facile à comprendre et facile à entretenir. Ce modèle est largement utilisé dans l'écosystème .NET pour créer plusieurs types d'applications comme les applications Blazor ou ASP.net Core. Il permet d'unifier la configuration globale de votre application. Vous pouvez configurer :

  • Votre classe d'application
  • Polices
  • Services via l'injection de dépendances
  • Initialisez les bibliothèques essentielles de MAUI dont vous avez besoin, etc.

Vous pouvez configurer tout ce qui précède en un seul endroit au lieu d'aller à votre délégué d'application ou à votre activité principale pour le faire. Voici une démonstration de la façon dont ce modèle est utilisé dans l'exemple d'application Weather 21 que vous pouvez trouver sur Github .

public static MauiApp CreateMauiApp()

    {

        var builder = MauiApp.CreateBuilder();

        builder

            .UseMauiApp<App>()

            .ConfigureFonts(fonts => {

                fonts.AddFont("fa-solid-900.ttf", "FontAwesome");

                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");

                fonts.AddFont("OpenSans-SemiBold.ttf", "OpenSansSemiBold");

            });

        builder.ConfigureLifecycleEvents(lifecycle => {

#if WINDOWS

            lifecycle

                .AddWindows(windows => windows.OnLaunched((app, args) => {

                    var winuiApp = (Microsoft.UI.Xaml.Window)MauiWinUIApplication.Current.Application.Windows[0].Handler!.NativeView!;

                    winuiApp.SetIcon("Platforms/Windows/trayicon.ico");

                }));

#endif

        });

 

        var services = builder.Services;

#if WINDOWS

            services.AddSingleton<ITrayService, WinUI.TrayService>();

            services.AddSingleton<INotificationService, WinUI.NotificationService>();

#elif MACCATALYST

            services.AddSingleton<ITrayService, MacCatalyst.TrayService>();

            services.AddSingleton<INotificationService, MacCatalyst.NotificationService>();

#endif

        return builder.Build();

    }

6- Tout recharger à chaud

C'est l'une des fonctionnalités les plus intéressantes et les plus attendues fournies avec .NET 6. Étant donné que MAUI est basé sur .NET 6+, il exploite évidemment la fonctionnalité de rechargement à chaud offerte par .NET 6 par défaut. Vous avez maintenant la possibilité non seulement de créer votre interface utilisateur XAML pendant que votre application est en cours d'exécution, mais en plus de cela, vous pouvez également modifier votre code C#.

NOTEZ que : comme mentionné par Dmitry Lyalin dans la .NET conf , le rechargement à chaud de .NET 6 fonctionne dans une grande variété de scénarios, mais il a encore quelques limitations. Cette technologie de rechargement à chaud est basée sur les fonctionnalités d'édition et de poursuite de Visual Studio qui alimentent l'édition principale du CLR ( moteur d'exécution .NET) pendant l'exécution. Par conséquent, les applications .NET utilisant directement le CLR principal bénéficieront le plus de cette fonctionnalité. Pendant ce temps, les applications .NET construites sur le « cadre mono » ( .NET iOS, Android, Blazor WASM ) ne prendront en charge que les types de modifications de remplacement de corps de méthode.

Pourquoi choisir MAUI plutôt que d'autres frameworks multiplateformes

Avec ce que vous venez de lire je pense que maintenant vous savez que .NET MAUI est génial. Ce que vous savez sûrement aussi, c'est qu'il existe plusieurs autres frameworks qui offrent un moyen de créer facilement des applications multiplateformes, alors pourquoi choisir MAUI à la place ?

  • Certains frameworks de développement multiplateforme ne sont pas entièrement natifs , vous devrez donc créer des fonctionnalités spécifiques à chaque plate-forme native (iOS, Android …) pour accéder à des API telles que Camera, Sensors, Connevtivity. En attendant, nous avons la librairie « essentiels » MAUI qui fournissent tout ce dont nous avons besoin, prêts à l'emploi.
  • MAUI est conçu spécifiquement pour .NET . C'est un grand avantage pour tout développeur .NET qui a déjà plongé dans le développement d'applications multiplateformes et qui ne veut pas perdre de temps à apprendre de nouveaux langages et de nouveaux outils. Vous pouvez tout faire avec vos outils .NET bien-aimés et Visual Studio.
  • MAUI prend en charge plusieurs plates-formes en tant que citoyens de première classe, notamment (Android, iOS, Mac, WinUI, Tizen…) (la prise en charge de Linux n'est pas encore officielle et restera un support de la communauté) tandis que d'autres frameworks comme le script natif prennent en charge moins de plates-formes.
  • Avec MAUI, vous pouvez créer pour le Web en tirant parti de la puissance des liaisons Blazor sur mobiles, alors que vous ne pouvez pas faire cela avec certains de ses concurrents.
  • MAUI prend en charge plusieurs paradigmes pour la création d'applications. Ce que je préfère avec MAUI, c'est qu'on peut faire les choses de plusieurs façons non pas pour faire du code spaghetti mais pour que l’outil s’adapte à vos pratiques et non l’inverse.
  • Vous pouvez construire votre application page après page, en définissant vous-même votre hiérarchie visuelle comme bon vous semble.
  • Vous pouvez créer votre application à l'aide du paradigme Shell (navigation) pour mettre en page toute votre hiérarchie visuelle et effectuer une navigation avec des itinéraires avec des paramètres et des objets.
  • Vous pouvez choisir de dessiner vos contrôles et de les rendre identiques sur toutes les plateformes, avec MAUI Graphics. Tout comme Flutter.
  • Vous pouvez aussi créer vos applications à l'ancienne, avec des contrôles ayant une apparence et une convivialité natives propres à chaque plate-forme.

Mise à niveau des applications Xamarin Forms vers MAUI

L' assistant de mise à niveau .NET est disponible pour vous aider dans la tâche de mise à niveau de vos applications. L' assistant de mise à niveau .NET est un outil CLI qui a été créé lors de la sortie de .NET 5. Il a principalement aidé les développeurs .NET à porter leurs applications WPF, WinForms… vers .NET 5. L'équipe MAUI a amélioré cet outil pour nous permettre de migrer nos applications vers .NET MAUI.

Cela ne fera cependant pas 100% du travail de migration pour vous. Vous devrez continuer le travail une fois qu'il aura terminé sa tâche, rien n’est magique bien entendu. Voici quelques transformations que cet assistant de mise à niveau fera pour vous :

  • Mettre à jour les packages nuget
  • Modifier les frameworks cibles
  • Cela fonctionne actuellement pour les applications ciblant Xamarin.Forms >= 4.8.
  • Votre application ne sera pas convertie en type de projet unique MAUI
  • Vous devrez mettre à jour vos espaces de noms XAML après une mise à niveau

L’outil évolue et je vous conseille de consulter sa documentation à jour avant de vous lancer.

Conclusion

MAUI a beaucoup à offrir, tellement de goodies, la version finale s’est faite un peu attendre mais on peut enfin utiliser MAUI en production. Le développement se poursuit activement et de toute façon MAUI sera un produit en perpétuel évolution, ne vous attendez pas à une livraison définitive coulée dans le béton et gravée dans le marbre. Déjà dotnet 7 puis 8, C#11, etc pointent leur nez. MAUI est une longue vague qui déferle, s’enroule, s’étale sur la plage pour mieux préparer le terrain pour la vague suivante, ce n’est pas un bassin à poissons rouges bien calme. Rien n’est mieux dans l’absolu objectif qu’on fantasme parfois, à chacun de savoir s’il est à l’aise dans un monde qui bouge ou si la culture des radis en Moldavie occidentale convient plus à son caractère.

Pour la suite de cette épopée surtout…

Stay Tuned !

Faites des heureux, partagez l'article !
blog comments powered by Disqus