Blog de Marco Cantù : UWP et Windows App Platform
UWP et Windows App Platform
Comme vous l'avez probablement constaté, le mois dernier, des discussions ont eu lieu autour de l'UWP (Universal Windows Platform) et de l'orientation actuelle, ou du changement d'orientation, de Microsoft en ce qui concerne la manière dont les développeurs devraient créer des applications pour leur système d'exploitation grand public, Windows 10. Il y a eu des affirmations et des contre-affirmations, ce qui a rendu le débat assez intéressant.
Il va sans dire que les instructions de Microsoft pour la création d'applications Windows sont d'une importance capitale pour la plupart de nos clients, ainsi que pour nous, à Embarcadero, étant donné que RAD Studio se concentre fortement sur le développement Windows.
Pour un résumé du point de vue de Microsoft, vous pouvez lire cet entretien de Mary Jo Foley avec Kevin Gallo, vice-président de la plate-forme Windows Developer de Microsoft : https://www.zdnet.com/article/microsoft-wants-to-close-the-uwp-win32-divide-with-windows-apps/
Mais permettez-moi de commencer par le début et de récapituler les plans de Microsoft (et la manière dont Embarcadero les a mis en œuvre).
Le Saint Graal de l'UWP et WinRT
Il y a quelques années, lorsque Microsoft a présenté Windows 10 pour les ordinateurs de bureau, l'entreprise avait encore de grands espoirs pour son système d'exploitation jumeau Windows 10 Phone. Nous savons que le téléphone a fini par être un gros échec pour Microsoft, mais à l'époque, l'entreprise misait beaucoup sur ce système. L'idée derrière UWP était de créer une nouvelle API commune et une infrastructure de base du système d'exploitation qui permettrait à la même application de fonctionner sur toutes les versions de Windows (y compris Xbox et HoloLens). Techniquement, Windows 10 a été doté d'un nouveau "noyau" appelé WinRT (initialement introduit dans Windows 8), un sous-système que vous pouvez cibler avec une API spécifique. Il ne s'agit pas d'une API .NET, mais plutôt d'une API native de type C++.
Note complémentaire : il s'avère que WinRT est "compatible avec les invocations" de COM et qu'il peut être facilement mis en correspondance avec les interfaces Delphi - ce que Embarcadero a fait en offrant une prise en charge directe de cette nouvelle API de plate-forme.
Il y avait d'autres principes clés : une sécurité accrue (car les applications s'exécutent de manière plus isolée et sont plus sûres dans leur gestion de la mémoire), une plus grande stabilité (avec des interfaces utilisateur plus réactives et des processus asynchrones), et cela pourrait permettre à Windows de devenir un écosystème plus stable.
Alors pourquoi tous les développeurs n'ont-ils pas sauté sur UWP et WinRT ? Microsoft a proposé une variété de langages de programmation (C# et .NET, C++, et même JavaScript) et s'attendait à une large adoption. Cependant, l'UWP s'accompagnait de ses propres directives en matière de conception d'interface utilisateur (contrôles très espacés, mode plein écran) et de spécifications techniques (la quasi-totalité du code devant être asynchrone) qui entravaient le développement. Joli, moderne, mais très différent de toute autre API, plateforme et UX - et donc difficile à adopter par les développeurs, en particulier si la cible est plus d'une plateforme. En fait, aucun code existant n'était prêt à fonctionner, quel que soit le langage de programmation choisi. Et une réécriture complète n'est pas quelque chose que les développeurs (et leurs entreprises) sont prêts à faire.
Traverser le pont ou rester du côté de la confiance ?
Après l'adoption initiale lamentable (qui permettait aux développeurs de publier des applications sur le magasin - mais un magasin qui n'était pas bien entretenu), Microsoft a commencé à promouvoir un ensemble de "ponts" pour permettre d'apporter le code existant à la nouvelle plateforme UWP. Il y avait un pont pour le support des applications Android sur Windows Phone, un pour la conversion Objective-C, et un pour permettre aux applications natives Win32 de faire partie de UWP. Il s'agissait là d'applications non universelles de la plateforme UWP, puisqu'elles ne pouvaient fonctionner que sur l'une des versions de Windows 10, bureau ou mobile. Cela n'a fait qu'ajouter à la confusion.
En outre, Microsoft a continué à indiquer que ces passerelles étaient destinées à faciliter la conversion de vos applications vers le nouveau modèle, un formulaire et un module à la fois - plutôt que tous en même temps. Mais la destination était toujours censée être une réécriture complète de votre code. "Si vous avez un million de lignes de code, vous voulez passer à la nouvelle plate-forme au fil du temps", déclarait officiellement Microsoft. Mais il était évident que les développeurs ne voulaient pas vraiment faire TOUTES les réécritures de leur code pour le faire passer de Windows à Windows 10 ! Considérant que toutes les anciennes applications continuaient à fonctionner sans problème et que les toutes nouvelles fonctionnalités offertes par le système d'exploitation étaient assez limitées.
Aujourd'hui encore, RAD Studio (ainsi que Visual Studio) a commencé à offrir un support pour le pont Desktop, mais notre objectif était uniquement de permettre aux développeurs de cibler de nouvelles API disponibles uniquement du côté de WinRT (comme les notifications ou BLE) et d'être en mesure de déployer des applications sur le Windows Store - pour une distribution plus facile, en profitant de commissions réduites et d'options de monétisation supplémentaires (via des abonnements).
Microsoft abandonne-t-il ?
Cela nous amène à aujourd'hui et aux récentes "annonces" de Microsoft. Un point de vue intéressant est disponible à l'adresse suivante : https://mspoweruser.com/uwp-is-dead-because-windows-apps-are-dead/
La société vient apparemment de se rendre compte que, malgré son insistance, les développeurs ne vont pas réécrire les applications pour les adapter au système d'exploitation Windows. En fait, ils continuent à utiliser WinForms et MFC (du côté des outils de développement de Microsoft) ou VCL (du côté de RAD studio) ou d'autres bibliothèques natives. Ces jours-ci, Microsoft minimise clairement l'importance de l'UWP en tant que modèle de développement.
Notez que des rapports indiquent également que les applications XBox sont désormais construites avec Electron, une bibliothèque de bureau JavaScript : https://www.onmsft.com/news/new-electron-powered-xbox-app-leaks-hours-before-e3
L'affirmation selon laquelle le développement de la plate-forme Windows s'est arrêté semble assez exagérée. Il existe encore de nombreuses applications professionnelles écrites pour Windows, ainsi que des systèmes de contrôle en temps réel et des jeux. Alors qu'un grand nombre d'applications grand public ont été transférées vers le web et la téléphonie mobile, l'investissement dans le développement Windows représente toujours une part importante du budget informatique - même si la maintenance des applications existantes en représente probablement une part importante.
Quoi qu'il en soit, il ne s'agit là que d'un aspect du scénario. Le modèle APPX du pont de bureau implique que les applications fonctionnent "partiellement en boîte de sable". Elles ne peuvent pas être élevées au rang d'administrateur, elles ne peuvent accéder qu'à leur "vue" du registre et du système d'exploitation. Il est vrai qu'elles peuvent encore faire des dégâts, mais la procédure de contrôle du magasin devrait également permettre de filtrer les mauvais éléments. Le concept autour de UWP / APPX est que les applications peuvent être plus facilement isolées (et même, avec .NET Core, avoir chacune leur propre copie de toute bibliothèque requise). Elles peuvent être installées sans autorisation de l'administrateur et supprimées en laissant un système d'exploitation propre (ou presque), imitant l'expérience des utilisateurs sur les téléphones.
Il ne s'agit pas seulement d'une survivance du modèle UWP, mais Microsoft a doublé ses efforts avec la technologie MSIX. Cette technologie semble être une technologie "d'installation" et est présentée comme telle, mais il s'agit en fait de la prochaine interaction d'APPX. Les applications MSIX peuvent être distribuées via le Windows Store ou dans le cadre d'un modèle de distribution d'entreprise, permettent une sécurité accrue et ce que Microsoft appelait à l'origine la "virtualisation" et qu'il appelle désormais la "conteneurisation" - pour tirer parti d'une tendance commune.
L'idée que les applications doivent vivre de plus en plus isolées est également soutenue par des changements au niveau de .NET, avec l'idée (un élément clé de .NET Core) que chaque application doit être livrée avec sa propre version de .NET plutôt que de dépendre de la version de la bibliothèque fournie par le système d'exploitation - ce qui présente le grand avantage de réduire les dépendances et de permettre aux utilisateurs de mettre à jour .NET sans craindre de casser les applications existantes sur leurs systèmes.
Et qu'en est-il de RAD Studio ?
C'est ainsi que je conçois l'avenir de la plateforme Windows App - un avenir qui permet aux applications VCL Delphi et C++Builder de jouer sur un pied d'égalité avec les bibliothèques et l'écosystème d'interface utilisateur de Microsoft, avec un degré de compatibilité beaucoup plus élevé avec le code et les investissements existants.
Windows 10 en tant que plateforme cible est vivant et en pleine croissance (dans le total des OS de bureau, si ce n'est en termes absolus) et la VCL avec son support pour l'API Windows, COM, WinRT et le modèle APPX a tout ce dont vous avez besoin pour cibler la plateforme. Nos bibliothèques intègrent les fonctionnalités de Windows 10, le support High DPI et la compatibilité d'une manière inégalée dans l'industrie - sans oublier un large écosystème de contrôles tiers !
