Évolution de l’accès aux API de la plate-forme avec .NET MAUI

L’accès aux API de la plate-forme mobile est une histoire heureuse pour les développeurs .NET. Revenons dans le passé sur la façon dont nous en sommes arrivés là.

Le .NET d’aujourd’hui est open source et une plate-forme de développement multiplateforme avec des outils solides. Modern .NET aide les développeurs à créer des applications natives pour divers facteurs de forme mobiles et une pléthore d’appareils. Avec Xamarin, Xamarin.Forms et maintenant .NET MAUI, le code .NET s’étend facilement à iOS et Android avec un accès complet aux API de plateforme natives.

Cependant, les développeurs ont rapidement appris que les API natives sont mieux utilisées à partir de .NET/C#, avec des mappages de plate-forme sous-jacents exposés via une abstraction. Sans cela, les développeurs .NET auraient appris Java ou Swift/Objective-C pour accéder aux API natives et, pire encore, répliquer le code d’accès natif pour chaque plate-forme.

Cependant, la façon dont nous accédons aux API mobiles natives via .NET a évolué au fil des ans. Voyons où .NET a commencé avec les API de plate-forme et où les choses se dirigent, à travers le prisme d’une petite histoire américaine.

Ère #1 : Le Far West

Le Far West était une période de l’histoire américaine, jouée aux frontières de l’expansion vers l’ouest et des colonies autour de la ruée vers l’or. Alors qu’il y avait l’anarchie et les conflits, l’époque est immortalisée par les représentations médiatiques de l’image du cow-boy et de l’individualisme sauvage.

XamarinName et Xamarin.FormsXamarin.Forms a joué un grand rôle dans la démocratisation du code .NET qui fonctionnait de manière transparente sur les appareils mobiles exécutant iOS/Android. Les développeurs ont appris à écrire une logique métier dans du code C# qui serait partagé entre les plates-formes et même à utiliser C#/XAML comme abstraction d’interface utilisateur multiplateforme. Cependant, lorsqu’il s’agissait d’accéder aux API de la plate-forme, les développeurs ne se souciaient pas d’écrire du code natif. .NET ne pouvait-il pas faire le travail ? La réponse était plugins— de petites abstractions qui enveloppaient du code spécifique à la plate-forme et exposaient des fonctionnalités en C# pur.

Il y avait beaucoup d’enthousiasme – la communauté des développeurs a écrit une tonne de plugins Xamarin, tout comme les gens de Microsoft. Tout ce que les développeurs Xamarin avaient à faire était d’apporter des packages NuGet – il y avait des plugins pour à peu près toutes les fonctionnalités de l’API et de l’appareil de la plate-forme. Cela a finalement conduit à une situation de trop de choix – il y avait plusieurs plugins pour faire la même chose. Les applications d’entreprise avaient besoin d’assistance et les développeurs ne savaient pas à quels packages faire confiance. Néanmoins, la communauté .NET se souvient avec émotion des immenses contributions individuelles qui ont fait des plugins Xamarin un écosystème riche.

Ère #2 : Les États-Unis

Treize colonies de Grande-Bretagne le long de la côte atlantique ont publié la déclaration d’indépendance en juillet 1776, créant ainsi l’union américaine. La naissance d’une nation est rarement facile – davantage d’États ont rejoint l’union, souvent à la suite d’un conflit et une guerre civile totale a éclaté, mais l’intégrité des États combinés est restée intacte, menant ainsi aux États-Unis d’Amérique.

Pour les développeurs Xamarin, les abstractions C # étaient le moyen d’accéder aux API/fonctionnalités de la plate-forme – l’écosystème du plug-in Xamarin s’était développé de manière presque incontrôlable. Microsoft avait besoin de combiner toutes les qualités en un seul endroit et d’offrir une solution stable pour accéder aux API mobiles natives. Entrer Xamarin.Essentials– la seule bibliothèque pour les gouverner tous. Android, iOS et UWP offraient des API de plate-forme/fonctionnalités de système d’exploitation uniques auxquelles les développeurs avaient désormais accès en C#. Obtenez un package NuGet et finissez-en.

Xamarin.Essentials a représenté un effort substantiel dans la normalisation de l’accès aux API de la plate-forme à partir de .NET et a fourni aux développeurs Xamarin un canevas stable sur lequel s’appuyer pour les fonctionnalités natives. Il est désormais intégré aux projets Xamarin avec des modèles par défaut. Avec plus de 40 API multiplateformes, les développeurs .NET sont gâtés avec un accès facile à la plateforme, quelle que soit la composition de l’interface utilisateur de l’application. Xamarin.Essentials, à ce jour, reste la référence en matière de standardisation des fonctionnalités d’API et de plate-forme multiplateformes, toutes unies dans le confort de C#.

Ère #3 : Fusion de l’Alaska

Lorsque les superpuissances mondiales sont en désaccord sur les luttes impériales, de grandes portions de terres changent parfois de propriétaire. En 1867, les États-Unis d’Amérique ont pris possession de l’Alaska après l’avoir acheté à la Russie, l’ajoutant finalement en tant que 49e État de l’union. Bien que séparé du reste des États continentaux, l’Alaska est stratégique dans sa position et abrite de magnifiques paysages naturels intacts.

Xamarin et Xamarin.Forms ont peut-être été le moyen préféré des développeurs .NET pour écrire des applications multiplateformes, mais il est également indéniable que certains des points faibles de l’écosystème – cibler plusieurs plates-formes n’était pas facile, les grands projets d’applications mobiles ont eu compliquées, les personnalisations de la plate-forme étaient délicates et l’outillage pourrait être meilleur. Entrer .NET MAUI—la nouvelle génération de développement multiplateforme intégrée à .NET.

Alors que .NET MAUI a commencé avec un état d’esprit axé sur le mobile lors de l’évolution de Xamarin.Forms, il a rapidement évolué pour cibler les plates-formes de bureau, tout en offrant plus de confiance aux développeurs. .NET MAUI arbore un projet véritablement unique ciblant diverses plates-formes, dispose d’outils perfectionnés et permet un meilleur partage de code avec les applications Web. Cependant, les développeurs ont toujours besoin d’accéder aux API de la plate-forme, en particulier sur les plates-formes mobiles comme iOS/Android. Pourquoi jeter tout le travail qui a été consacré à Xamarin.Essentials ?

Dès les premiers jours de .NET MAUI, le mot à la mode était .NET MAUI Essentials– la même pile d’API multiplateformes natives que les développeurs adorent. Ce qui a évolué, c’est le changement de propriétaire : .NET MAUI Essentials fait désormais partie intégrante de .NET, inspirant ainsi la confiance des développeurs. Sous le capot, .NET MAUI Essentials fournit la même API de plate-forme ou des abstractions de fonctionnalités, toutes exposées avec précision via C#. Essentials est une pierre angulaire de .NET MAUI, permettant à diverses piles d’interfaces utilisateur multiplateformes écrites en C#/XAML/Blazor d’accéder facilement aux API de plateforme natives.

Ère #4 : Archipel Hawaïen

En août 1959, Hawaï est devenu le 50e État des États-Unis d’Amérique. Les îles hawaïennes sont un archipel de huit îles principales, plusieurs atolls et de nombreux îlots plus petits dans l’océan Pacifique Nord. Alors qu’il s’agit d’un État américain stratégique, les îles hawaïennes combinées respirent l’histoire et la culture polynésiennes et sont considérées comme un paradis tropical.

Vous savez ce qui se passe quand quelque chose est ancré dans l’histoire, d’une importance capitale et enraciné dans la culture – cela devient évident. .NET MAUI Essentials est devenu une partie si stratégique de .NET MAUI qu’il n’y est plus explicitement – il est assimilé et simplement intégré. Après avoir été une partie importante des aperçus .NET MAUI, juste avant la première Release Candidate, .NET MAUI Essentials a été repensé et le nom Essentials n’est plus. Ne vous y trompez pas, tous les avantages de .NET MAUI Essentials sont toujours là, juste intégrés pour faire partie de .NET MAUI lui-même.

Dans le passé, le monolithique Microsoft.Maui.Essentials namespace a apporté tous les .NET MAUI Essentials, que les développeurs aient besoin de toutes les API de la plate-forme ou non. Maintenant, l’objectif est de garder les choses granulaires et de faire en sorte que les développeurs apportent des espaces de noms lorsqu’ils utilisent explicitement des API/fonctionnalités de plate-forme spécifiques. Jetons un coup d’œil à certains des groupes les plus populaires :

Besoin d’API spécifiques aux appareils mobiles, telles que la source d’alimentation, l’orientation, l’affichage, la lampe de poche, les vibrations, etc. ? Utilisation Microsoft.Maui.Devices.

Besoin d’API d’accès multimédia, comme l’appareil photo ou la photothèque ? Utilisation Microsoft.Maui.Media.

Besoin de puiser dans les API pour une pléthore de capteurs sur les appareils mobiles ? Utilisation Microsoft.Maui.Sensors.

Les développeurs .NET MAUI devraient comprendre : .NET MAUI Essentials n’est plus, mais les mêmes API sont désormais intégrées et regroupées dans des espaces de noms granulaires.

Une question est cependant évidente : les développeurs ne devraient-ils pas se souvenir/rechercher les espaces de noms dont ils ont besoin pour les API de plate-forme correspondantes auxquelles ils souhaitent accéder ? Oui, d’une certaine manière, mais cela pourrait être une chose unique par projet .NET MAUI. Apportez simplement les espaces de noms avec un Global mot-clé et vous aurez accès à toutes les API partout ailleurs dans le projet .NET MAUI. Mieux encore, pourquoi ne pas mettre tous les espaces de noms nécessaires dans un projet au niveau GlobalUsings.cs fichier—gardez les choses organisées en un seul endroit et appelez-le un jour ?

Mais attendez, l’histoire s’améliore. Au lieu que les développeurs aient à apporter des espaces de noms à l’échelle mondiale, ne serait-il pas agréable que .NET MAUI fasse une partie du travail automatiquement ? Fait et fait. Démarrez un nouveau projet .NET MAUI et examinez le fichier de construction intermédiaire nommé XX.GlobalUsings.g.cs— la plupart des espaces de noms de l’API de la plate-forme sont pré-câblés pour vous ! Et au moment de la construction/publication, il y a une arborescence pour s’assurer que votre package d’application n’inclut que les éléments dont vous avez besoin pour les API de la plate-forme en cours d’utilisation. Alléluia.

Dans une conversation passée, Gérald Versluis et David Ortinau avait dit à juste titre que les développeurs .NET MAUI peuvent simplement utiliser des API mobiles natives multiplateformes prêtes à l’emploi. Pas besoin d’y penser – les API sont juste là avec la plupart des espaces de noms déjà intégrés. Vous pouvez essayer de plier la cuillère, ou vous rendre compte il n’y a pas de cuillère. Tout comme les îles hawaïennes, les API de la plate-forme mobile fonctionnent ensemble comme une partie intégrée de .NET MAUI, un petit coin de paradis pour les développeurs.

Conclusion

Le .NET moderne permet aux développeurs d’écrire facilement des applications mobiles/de bureau multiplateformes. Cependant, pour une expérience haute fidélité, les développeurs doivent souvent exploiter des API ou des fonctionnalités spécifiques à la plate-forme. Au cours d’une décennie d’évolution, l’actuel .NET MAUI rend l’accès à l’API de la plate-forme plutôt facile pour les développeurs – tout est intégré. Les abstractions via C # signifient la personnalisation de l’interface utilisateur ou de l’UX sur chaque plate-forme, ce qui est également transparent pour les développeurs .NET. Cela a pris du temps, avec de grandes contributions de la communauté des développeurs et des normalisations de Microsoft—les développeurs .NET MAUI sont dans un endroit heureux pour aller de l’avant. Acclamations.