Project Reunion: Pourquoi les développeurs de bureau se soucient-ils?

Project Reunion est destiné à consolider les API des différentes versions de Windows en une seule API. Si vous êtes un développeur de bureau, même en version préliminaire, Project Reunion propose déjà des outils que vous pourriez utiliser. Et si vous avez déjà pensé à UWP, vous vous en souciez beaucoup.

Permettez-moi de vous donner une idée de mon âge (mais continuez à lire quand même): lorsque j'ai commencé à créer des applications de bureau à l'aide des outils Microsoft, à l'aide de Windows Forms comme c'était le seul outil disponible, j'avais une copie du Guide du programmeur Visual Basic de Dan Appleman sur l'API Win32 . J'ai vivement recommandé de le lire et j'ai beaucoup appris sur Windows au cours du processus. C'était il y a combien de temps? Une partie du livre traitait de la conversion des appels 16 bits en appels 32 bits.

Oui, cet ancien.

Cependant, à part l'appel étrange pour échanger des chaînes avec des DLL C, je n'ai jamais vraiment utilisé les informations dans ce livre. Tous mes besoins en matière d'interface utilisateur et de développement d'applications ont été satisfaits avec Windows Forms, les contrôles d'interface utilisateur qui l'accompagnaient, les bibliothèques Windows COM que je pourrais ajouter à mes projets et l'écosystème tiers qui s'est développé autour de Windows Forms.

Depuis lors , nous avons eu plusieurs versions différentes de Windows et plusieurs plates-formes de développement différentes (WinForms, bien sûr, mais aussi WPF, .NET et UWP). J'ai pu, grâce à divers contrôles et bibliothèques, rester isolé des modifications sous-jacentes de l'API.

Le problème

Mais il y a des développeurs (et vous en êtes peut-être un) qui n'ont pas été isolés de ces appels d'API . Cela est particulièrement vrai, par exemple, des développeurs qui ont construit tous ces excellents contrôles et bibliothèques Windows Forms que j'ai utilisés dans mes applications. Les développeurs qui (juste pour choisir quelques exemples au hasard) ont développé la boîte à outils Telerik UI pour WinForms . Ou la boîte à outils Telerik UI pour WPF . Ou la boîte à outils Telerik for UI for Universal Windows Platform (UWP) . Ou la boîte à outils à venir Telerik UI pour WinUI . Et tous les autres fournisseurs d'outils de bureau sont dans le même bateau.

Une des raisons pour lesquelles il existe tant de boîtes à outils (ou, pour le dire autrement, le problème auquel sont confrontés ces développeurs de boîtes à outils) est la prolifération des API Windows 10 – prenant en charge UWP, par exemple, signifie prendre en charge les API WinRT. Ce n’est pas une tâche anodine, même sous Windows 10 et même avec la prise en charge améliorée NuGet . Même avec ce support, les développeurs doivent encore écrire code adaptatif de version s'ils veulent prendre en charge les versions antérieures de WinRT.

Et, en tant que développeurs de bureau, vous et moi nous soucions également. Si nous n'accédions qu'aux contrôles de l'interface utilisateur, cela pourrait ne pas être vrai. Mais nous utilisons également diverses bibliothèques pour accéder à des ressources non-UI comme, par exemple, GeoLocation. L'expérience de travailler avec GeoLocation dans .NET Framework est très différente de le faire dans UWP avec son support WinRT (en fait, jusqu'à .NET Framework 4.0, le seul moyen d'accéder à GeoLocation était d'utiliser des bibliothèques WinRT).

Mais Et si ces API WinRT n'étaient pas séparées? Et s'il y avait un seul ensemble d'API disponibles partout? Tout à coup, tous ces outils de développement atteindraient la parité des fonctionnalités – tout le monde prendrait en charge la géolocalisation et de la même manière (à part les différences de syntaxe). Plus important encore, la vie deviendrait considérablement plus facile pour les développeurs qui créeraient tous ces merveilleux outils, ce qui signifie des outils plus merveilleux . Et, comme le montre la croissance des outils multiplateformes tels que Xamarin, MAUI, UWP et WinUI, il existe un besoin impérieux d'une plate-forme de développement qui traverse plusieurs (sinon toutes) plates-formes. Cela devient beaucoup plus réalisable s'il n'y a qu'une seule API.

Project Reunion

C'est pourquoi vous vous souciez du Project Reunion de Microsoft et des produits qu'il propose déjà. Project Reunion vise à consolider l'accès aux fonctionnalités de Windows sous une seule API. En théorie, cela pourrait signifier la fin d’UWP en tant que plate-forme de développement distincte: tout fonctionnerait partout parce que tout se ressemblerait.

C’est probablement trop attendre. Cela dit, Project Reunion vient tout juste d'arriver à l'étape de prévisualisation 0,5 et comprend déjà une API unifiée pour DirectWrite, qui fournit une mise en page de texte indépendante du périphérique. Ce n'est pas quelque chose que vous pourriez utiliser directement. Au lieu de cela, vous comptez sur vos commandes d'interface utilisateur pour prendre soin d'afficher votre texte à l'écran (tout comme je n'ai jamais écrit directement à l'écran lorsque je créais des applications Windows Forms).

Mais Preview 0.5 inclut également MRTCore, un ensemble d'objets dans l'espace de noms Microsoft.ApplicationModel.Resources pour la gestion des ressources, y compris à la fois les ressources de fichiers (fichiers contenant des images bitmap, XAML, XML, HTML, etc.) et les ressources intégrées (ressources dans un Resources fichier comme .resw ou .resjson). Les objets MRTCore incluent ResourceLoader, ResourceManager (qui encapsule l'objet ResourceMap, qui répertorie toutes vos ressources) et ResourceContext (qui, via les objets ResourceCandidate, met les ressources pertinentes à la disposition de votre objet). C’est un ensemble d’objets que vous pourriez utiliser demain.

Si vous voulez essayer ces nouveaux outils, votre meilleur choix actuellement est dans un projet WinUI . WinUI, qui vous permet de créer des applications fonctionnant à la fois sous Windows et WinRT, est logique pour le déploiement de Project Reunion (et WinUI vaut la peine d'être essayé pour pour lui-même ). Espérons que les outils rendus possibles par Project Reunion seront disponibles dans tous les environnements de développement de bureau de Microsoft, ce qui a le potentiel d’être assez formidable. Même si je ne passe jamais d'appel API de ma vie.