Blog von Marco Cantù: UWP und Windows App Plattform
UWP und Windows App-Plattform
Wie Sie wahrscheinlich mitbekommen haben, gab es im letzten Monat einige Diskussionen über die UWP (Universal Windows Platform) und den aktuellen Schwerpunkt bzw. die Änderung des Schwerpunkts von Microsoft in Bezug auf die Art und Weise, wie Entwickler Anwendungen für ihr Mainstream-Betriebssystem, Windows 10, entwickeln sollten. Es gab Behauptungen und Gegenbehauptungen, was die ganze Debatte recht interessant macht.
Es ist überflüssig zu erwähnen, dass die Microsoft-Richtlinien für die Erstellung von Windows-Anwendungen für die meisten unserer Kunden und auch für uns bei Embarcadero von entscheidender Bedeutung sind, da RAD Studio einen starken Fokus auf die Windows-Entwicklung hat.
Eine Zusammenfassung des Standpunkts von Microsoft finden Sie in diesem Interview von Mary Jo Foley mit Kevin Gallo, Corporate Vice President of the Windows Developer Platform von Microsoft: https://www.zdnet.com/article/microsoft-wants-to-close-the-uwp-win32-divide-with-windows-apps/
Aber lassen Sie mich von Anfang an beginnen und die Pläne von Microsoft rekapitulieren (und wie Embarcadero diese umgesetzt hat).
UWP Heiliger Gral und WinRT
Als Microsoft vor einigen Jahren Windows 10 für den Desktop einführte, setzte das Unternehmen noch große Hoffnungen in sein Zwillingsbetriebssystem Windows 10 Phone. Wir wissen, dass das Telefon am Ende ein großer Misserfolg für Microsoft war, aber zu dieser Zeit setzte man stark darauf. Die Idee hinter UWP war es, eine neue gemeinsame API und eine Kerninfrastruktur für das Betriebssystem zu schaffen, mit der dieselbe Anwendung auf allen Versionen von Windows (einschließlich Xbox und HoloLens) ausgeführt werden kann. Technisch gesehen verfügt Windows 10 über einen neuen "Kern" namens WinRT (der ursprünglich in Windows 8 eingeführt wurde), ein Subsystem, auf das Sie mit einer spezifischen API zugreifen können. Dabei handelt es sich nicht um eine .NET-API, sondern eher um eine native C++-API.
Anmerkung am Rande: Es hat sich herausgestellt, dass WinRT mit COM "aufrufkompatibel" ist und leicht auf Delphi-Schnittstellen abgebildet werden kann - was Embarcadero getan hat, indem es direkte Unterstützung für diese neue Plattform-API angeboten hat.
Es gab noch weitere wichtige Punkte: mehr Sicherheit (da Anwendungen isolierter laufen und sicherer in ihrer Speicherverwaltung sind), mehr Stabilität (mit reaktionsschnelleren Benutzeroberflächen und asynchronen Prozessen), und das könnte Windows zu einem stabileren Ökosystem machen.
Warum sind dann nicht alle Entwickler auf UWP und WinRT umgestiegen? Microsoft bot eine Vielzahl von Programmiersprachen an (C# und .NET, C++, sogar JavaScript) und erwartete eine große Akzeptanz. UWP hatte jedoch seine eigenen Richtlinien für das UI-Design (weit auseinander liegende Steuerelemente, Vollbildmodus) und technische Spezifikationen (fast der gesamte Code musste asynchron sein), die die Entwicklung behinderten. Schön, modern, aber ganz anders als alle anderen APIs, Plattformen und UX - und daher von den Entwicklern schwer zu übernehmen, vor allem, wenn das Ziel mehr als eine Plattform ist. Im Grunde genommen war keiner der vorhandenen Codes dort lauffähig, egal welche Programmiersprache Sie gewählt haben. Und eine vollständige Neuprogrammierung ist nichts, worauf Entwickler (und ihre Unternehmen) scharf sind.
Die Brücke überqueren oder auf der vertrauenswürdigen Seite bleiben?
Nach der anfänglichen mäßigen Akzeptanz (die es Entwicklern erlaubte, Apps im Store zu veröffentlichen - einem Store, der jedoch nicht gut gepflegt wurde) begann Microsoft mit der Förderung einer Reihe von "Brücken", die es ermöglichen sollten, vorhandenen Code auf die neue UWP-Plattform zu bringen. Es gab eine Brücke für die Unterstützung von Android-Apps auf Windows Phone, eine für die Konvertierung von Objective-C und eine, die es ermöglichte, dass native Win32-Apps Teil von UWP wurden. Nun waren dies nicht-universelle UWP-Plattform-Apps, da sie nur auf einer der Versionen von Windows 10, Desktop oder Mobile, laufen konnten. Das hat die Verwirrung nur noch vergrößert.
Außerdem wies Microsoft immer wieder darauf hin, dass diese Brücken dazu dienen sollten, Ihre Anwendungen auf das neue Modell umzustellen, und zwar ein Formular und ein Modul nach dem anderen - und nicht alles auf einmal. Aber das Ziel sollte immer noch eine komplette Neuschreibung Ihres Codes sein. "Wenn Sie eine Million Codezeilen haben, wollen Sie im Laufe der Zeit auf die neue Plattform umsteigen", hieß es offiziell von Microsoft. Aber es war offensichtlich, dass die Entwickler ihren Code nicht wirklich neu schreiben wollten, um ihn von Windows auf Windows 10 zu übertragen! Denn alle alten Anwendungen liefen weiterhin reibungslos und die brandneuen Funktionen, die das Betriebssystem bot, waren ziemlich begrenzt.
Auch jetzt bietet RAD Studio (wie auch Visual Studio) Unterstützung für die Desktop Bridge, aber unser Ziel war es, Entwicklern die Möglichkeit zu geben, neue, nur auf der WinRT-Seite verfügbare APIs (wie Benachrichtigungen oder BLE) zu nutzen und Anwendungen im Windows Store bereitzustellen - für eine einfachere Verteilung, die Nutzung niedriger Provisionen und zusätzliche Monetarisierungsoptionen (über Abonnements).
Gibt Microsoft auf?
Das bringt uns zum heutigen Tag und den jüngsten "Ankündigungen" von Microsoft. Ein interessanter POV ist bei: https://mspoweruser.com/uwp-is-dead-because-windows-apps-are-dead/
Das Unternehmen ist offenbar zu der Erkenntnis gelangt, dass die Entwickler trotz ihrer Beharrlichkeit keine Anwendungen für das Windows-Betriebssystem umschreiben werden. Vielmehr verwenden sie weiterhin WinForms und MFC (auf Seiten der Microsoft-Entwicklertools) oder VCL (auf Seiten von RAD Studio) oder andere native Bibliotheken. Heutzutage spielt Microsoft die UWP als Entwicklungsmodell eindeutig herunter.
Beachten Sie, dass es auch Berichte darüber gibt, dass XBox-Apps jetzt mit Electron, einer JavaScript-Desktop-Bibliothek, erstellt werden: https://www.onmsft.com/news/new-electron-powered-xbox-app-leaks-hours-before-e3
Die Behauptung, die Entwicklung für die Windows-Plattform sei zum Stillstand gekommen, scheint ziemlich übertrieben zu sein. Es werden immer noch viele Geschäftsanwendungen für Windows geschrieben, ebenso wie Echtzeitsteuerungssysteme und Spiele. Während viele Verbraucheranwendungen ins Web und auf Mobilgeräte verlagert wurden, machen Investitionen in die Windows-Entwicklung immer noch einen erheblichen Teil des IT-Budgets aus - auch wenn die Wartung bestehender Anwendungen wahrscheinlich einen großen Teil davon ausmacht.
In jedem Fall ist dies nur eine Seite des Szenarios. Das APPX-Modell der Desktop-Bridge impliziert, dass Anwendungen "teilweise in einer Sandbox" laufen. Sie können nicht mit Administratorrechten ausgestattet werden und haben nur Zugriff auf ihre "Sicht" der Registrierung und des Betriebssystems. Zugegeben, sie können immer noch Schaden anrichten, aber das Store-Überprüfungsverfahren sollte auch dazu beitragen, die bösen Buben herauszufiltern. Das Konzept von UWP / APPX besteht darin, dass Anwendungen leichter isoliert werden können (und mit .NET Core sogar jede ihre eigene Kopie jeder benötigten Bibliothek hat). Sie können ohne Administratorrechte installiert und wieder entfernt werden, so dass ein sauberes (oder fast komplett sauberes) Betriebssystem zurückbleibt, das die Erfahrung der Benutzer auf Telefonen imitiert.
Nun ist dies nicht nur ein Überbleibsel des UWP-Modells, sondern Microsoft hat seine Bemühungen mit der MSIX-Technologie verdoppelt. Das hört sich an wie eine "Installations"-Technologie und wird auch so beworben, aber in Wirklichkeit ist es die nächste Interaktion von APPX. MSIX-Apps können über den Windows Store oder im Rahmen eines Unternehmensverteilungsmodells vertrieben werden, ermöglichen zusätzliche Sicherheit und das, was Microsoft ursprünglich "Virtualisierung" nannte und jetzt als "Containerisierung" bezeichnet - um einen allgemeinen Trend aufzugreifen.
Der Gedanke, dass Anwendungen mehr und mehr isoliert leben sollten, wird auch durch Änderungen auf der .NET-Ebene unterstützt. Die Idee (ein Schlüsselelement von .NET Core) ist, dass jede Anwendung mit ihrer eigenen Version von .NET ausgeliefert werden sollte, anstatt sich auf die Version der Bibliothek zu verlassen, die das Betriebssystem bereitstellt - mit dem großen Vorteil, dass Abhängigkeiten reduziert werden und Benutzer .NET aktualisieren können, ohne befürchten zu müssen, dass bestehende Anwendungen auf ihren Systemen kaputt gehen.
Und was ist mit RAD Studio?
So stelle ich mir die Zukunft der Windows App-Plattform vor - eine Zukunft, in der Delphi- und C++Builder-VCL-Anwendungen auf Augenhöhe mit den Microsoft-eigenen UI-Bibliotheken und dem Ökosystem spielen können, mit einem viel höheren Grad an Kompatibilität mit bestehendem Code und Investitionen.
Windows 10 als Zielplattform ist lebendig und wächst (innerhalb der Desktop-Betriebssysteme insgesamt, wenn auch nicht in absoluten Zahlen) und die VCL mit ihrer Unterstützung für Windows API, COM, WinRT und APPX-Modell hat alles, was Sie brauchen, um die Plattform anzusteuern. Unsere Bibliotheken integrieren Windows 10-Funktionen, High DPI-Unterstützung und Kompatibilität in einer Weise, die in der Branche ihresgleichen sucht - ohne dabei ein großes Ökosystem großartiger Drittanbieter-Steuerelemente zu vergessen!
