Blog door Marco Cantù: UWP en Windows App Platform

UWP en Windows App Platform

Zoals je waarschijnlijk al hebt gezien, is er de afgelopen maand wat discussie geweest rond UWP (Universal Windows Platform) en de huidige focus, of verandering van focus, voor Microsoft als het gaat om de manier waarop ontwikkelaars toepassingen moeten bouwen voor hun mainstream besturingssysteem, Windows 10. Er zijn beweringen en tegenbeweringen geweest, waardoor het hele debat erg interessant is. Er zijn beweringen en tegenbeweringen geweest, wat het hele debat erg interessant maakt.

Onnodig te zeggen, Microsoft aanwijzingen voor het bouwen van Windows-applicaties is van cruciaal belang voor de meeste van onze klanten, en ook voor ons als op Embarcadero, gezien RAD Studio heeft een sterke focus op Windows-ontwikkeling.

Voor een samenvatting van het standpunt van Microsoft kun je dit interview lezen door Mary Jo Foley van Microsoft Corporate Vice President van het Windows Developer Platform Kevin Gallo: https://www.zdnet.com/article/microsoft-wants-to-close-the-uwp-win32-divide-with-windows-apps/

Maar laat ik bij het begin beginnen en de plannen van Microsoft nog eens op een rijtje zetten (en hoe Embarcadero die heeft aangepakt).

UWP Heilige Graal en WinRT

Een paar jaar geleden, toen Microsoft Windows 10 voor desktop introduceerde, had het bedrijf nog steeds hoge verwachtingen van zijn tweelingbesturingssysteem Windows 10 Phone. We weten dat de telefoon uiteindelijk een grote mislukking werd voor Microsoft, maar op dat moment zetten ze er zwaar op in. Het idee achter UWP was om een nieuwe gemeenschappelijke API en kerninfrastructuur voor het besturingssysteem te maken waarmee dezelfde toepassing op alle versies van Windows zou kunnen draaien (inclusief Xbox en HoloLens). Technisch gezien kwam Windows 10 met een nieuwe "kern" genaamd WinRT (oorspronkelijk geïntroduceerd in Windows 8), een subsysteem waarop je je kunt richten met een specifieke API. Dit is geen .NET API, maar meer een native API van het type C++.

Kanttekening: het blijkt dat WinRT "invocatie compatibel" is met COM en het kan gemakkelijk worden toegewezen aan Delphi interfaces - dat is wat Embarcadero deed door directe ondersteuning te bieden voor deze nieuwe platform-API.

Er waren nog andere belangrijke uitgangspunten: meer veiligheid (omdat apps meer geïsoleerd draaien en veiliger zijn in hun geheugenbeheer), meer stabiliteit (met beter reagerende UI's en async-processen), en dat zou ervoor kunnen zorgen dat Windows een stabieler ecosysteem wordt.

Dus waarom zijn niet alle ontwikkelaars overgestapt op UWP en WinRT? Microsoft bood een verscheidenheid aan programmeertalen (C# en .NET, C++, zelfs JavaScript) en verwachtte een grote acceptatie. UWP kwam echter met zijn eigen richtlijnen voor UI-ontwerp (brede regelaars, volledige schermmodus) en technische specificaties (bijna alle code moet asynchroon zijn) die de ontwikkeling belemmerden. Mooi, modern, maar heel anders dan elke andere API, platform en UX - en dus moeilijk te adopteren door ontwikkelaars, vooral als het doel meer dan één platform is. In principe was geen enkele bestaande code klaar om daar te draaien, ongeacht de programmeertaal die je koos. En een volledige herschrijving is niet iets wat ontwikkelaars (en hun bedrijven) graag doen.

De brug over of aan de vertrouwde kant blijven?

Na de aanvankelijke sombere adoptie (waardoor ontwikkelaars apps konden publiceren in de store - maar een store die niet goed werd onderhouden) begon Microsoft een reeks "bruggen" te promoten om bestaande code naar het nieuwe UWP-platform te brengen. Er was een bridge voor ondersteuning van Android-apps op Windows Phone, een bridge voor Objective-C conversie en een bridge om Win32 native apps deel te laten uitmaken van UWP. Nu waren dit niet-universele UWP-platform apps, aangezien ze alleen konden draaien op een van de versies van Windows 10, desktop of mobiel. Dit maakte de verwarring alleen maar groter.

Bovendien bleef Microsoft aangeven dat deze bruggen bedoeld waren om je applicaties te helpen converteren naar het nieuwe model, één formulier en één module per keer - in plaats van alles in één keer. Maar het doel was nog steeds een volledige herschrijving van je code. "Als je een miljoen regels code hebt, wil je na verloop van tijd overgaan naar het nieuwe platform", stelde Microsoft officieel. Maar het was duidelijk dat ontwikkelaars hun code helemaal niet wilden herschrijven om deze van Windows naar Windows 10 te verplaatsen! Aangezien alle oude applicaties probleemloos bleven draaien en de gloednieuwe functies die het besturingssysteem bood vrij beperkt waren.

Nu opnieuw, RAD Studio (evenals Visual Studio) begonnen met het aanbieden van ondersteuning voor de Desktop Bridge, maar ons doel was alleen om ontwikkelaars te richten op nieuwe API's die alleen beschikbaar zijn op de WinRT kant (zoals meldingen of BLE) en in staat zijn om toepassingen te implementeren op de Windows Store - voor een eenvoudigere distributie, profiteren van lage commissies, en extra monetization opties (via abonnementen).

Geeft Microsoft het op?

Dit brengt ons bij vandaag en de recente "aankondigingen" van Microsoft. Een interessante POV is te vinden op: https://mspoweruser.com/uwp-is-dead-because-windows-apps-are-dead/

Het bedrijf is blijkbaar tot het besef gekomen dat, ongeacht hun aandringen, ontwikkelaars niet van plan zijn om toepassingen te herschrijven voor het Windows-besturingssysteem. In feite blijven ze WinForms en MFC (aan de kant van de Microsoft ontwikkelaarstools) of VCL (aan de kant van RAD studio) of andere native bibliotheken gebruiken. Tegenwoordig is Microsoft UWP duidelijk aan het bagatelliseren als ontwikkelmodel.

Merk op dat er ook berichten zijn over het feit dat XBox-apps nu worden gebouwd met Electron, een JavaScript-desktopbibliotheek: https://www.onmsft.com/news/new-electron-powered-xbox-app-leaks-hours-before-e3

De bewering dat de ontwikkeling voor het Windows-platform is gestopt, lijkt nogal overdreven. Er worden nog steeds veel zakelijke toepassingen geschreven voor Windows, en ook realtime besturingssystemen en games. Hoewel veel consumentenapps naar het web en mobiel zijn verhuisd, is de investering in Windows-ontwikkeling nog steeds een aanzienlijk deel van het IT-budget - ook al maakt het onderhoud van bestaande applicaties er waarschijnlijk een aanzienlijk deel van uit.

In elk geval is dit slechts één kant van het scenario. Het APPX model van de desktop bridge impliceert dat apps "gedeeltelijk in een zandbak" draaien. Ze kunnen niet worden verhoogd met adminrechten, ze hebben alleen toegang tot hun "weergave" van het register en het besturingssysteem. Toegegeven, ze kunnen nog steeds schade aanrichten, maar de store doorlichtingsprocedure zou ook moeten helpen om de slechteriken eruit te filteren. Het concept rond UWP / APPX is dat toepassingen gemakkelijker kunnen worden geïsoleerd (en met .NET Core zelfs elk hun eigen kopie van een vereiste bibliotheek hebben). Ze kunnen worden geïnstalleerd zonder toestemming van de beheerder en worden verwijderd met een schoon (of bijna helemaal schoon) besturingssysteem als resultaat, wat de ervaring van gebruikers op telefoons nabootst.

Nu is dit niet alleen overleven aan het UWP-model, maar Microsoft heeft zijn inspanningen verdubbeld met de MSIX-technologie. Dit klinkt en wordt gepromoot als een "installatie" technologie, maar het is in feite de volgende interactie van APPX. MSIX-apps kunnen worden gedistribueerd via Windows Store of binnen een bedrijfsdistributiemodel, zorgen voor extra beveiliging en wat Microsoft oorspronkelijk "virtualisatie" noemde en nu "containerisatie" noemt - om mee te liften op een algemene trend.

Het idee dat apps meer en meer in isolatie moeten leven, wordt ook ondersteund door veranderingen op .NET-niveau, met het idee (een sleutelelement van .NET Core) dat elke app moet worden geleverd met zijn eigen versie van .NET in plaats van te vertrouwen op de versie van de bibliotheek die het besturingssysteem levert - met het grote voordeel dat er minder afhankelijkheden zijn en dat gebruikers .NET kunnen updaten zonder bang te hoeven zijn dat bestaande toepassingen op hun systemen kapot gaan.

En hoe zit het met RAD Studio?

Dit is hoe ik de toekomst van het Windows App platform zie - een toekomst die Delphi en C++Builder VCL applicaties gelijk laat spelen met Microsoft eigen UI bibliotheken en ecosysteem, met een veel hogere mate van compatibiliteit met bestaande code en investeringen.

Windows 10 als doelplatform leeft en groeit (binnen het totaal van desktopbesturingssystemen, zo niet in absolute zin) en de VCL met zijn ondersteuning voor Windows API, COM, WinRT en APPX-model heeft alles wat je nodig hebt om dit platform doelgericht te gebruiken. Onze bibliotheken integreren Windows 10 functies, High DPI ondersteuning en compatibiliteit op een manier die ongeëvenaard is in de industrie - zonder een groot ecosysteem van geweldige besturingselementen van derden te vergeten!