Echte Migration!

Eine Desktopanwendung auf die UWP migrieren
Keine Kommentare

Das Nebeneinander von Desktop- und Universal-Windows-Platform-Anwendungen nervt. Microsoft pusht die UWP, vielleicht verschwindet in der Zukunft sogar der klassische Desktop. Mit der Desktop Bridge von Microsoft ist es möglich, eine Desktop-App so zu verpacken, dass man sie als UWP-Anwendung über den Store vertreiben kann. Aber es ist eben nur eine Verpackung! Und wie geht eine richtige Migration?

Steht eine neue Version für eine Anwendung an, stellt sich auch die Frage, ob es sich lohnt, mehr Zeit zu investieren und gleich eine richtige App für die Universal Windows Plattform (UWP) aus ihr zu machen. Mit Windows 10 hat zwar eine friedliche Koexistenz beider Anwendungstypen Einzug gehalten, dennoch stellt sich bei jedem neuen Release die eingangs genannte Frage. Klassische Desktopanwendungen haben wir alle über Jahre zur Genüge gebaut, sie sind uns vertraut. Ihre Vor- und Nachteile aufzuzählen, sparen wir uns deshalb. Sehen wir uns zunächst die positiven Eigenschaften der noch immer recht jungen Generation von UWP-Apps an:

  • Optimierte Bereitstellung: Die Apps können direkt über den Store des Betriebssystems bereitgestellt werden. Das gilt für die initiale Version wie auch für spätere Updates. Wenn ein Benutzer die App deinstalliert, wird sie vollständig entfernt, ohne dass irgendwelche Spuren zurückbleiben. Dadurch wird der Zeitaufwand zum Erstellen des Set-ups und zum Bereitstellen von Updates verringert. Das Deployment ist gut standardisiert und damit recht schnell zu erledigen. Benutzer werden über neue Programmversionen benachrichtigt.
  • Höhere Reichweite: Der Store ist der zentrale Anlaufpunkt für neue Apps. Die Abwicklung der Zahlung erfolgt ebenfalls über ihn. Diese Argumente zählen vor allem für auf den Consumer-Markt ausgerichtete Apps. Für Unternehmens-Apps sind sie weniger relevant.
  • Neue Features: UWP-Apps bieten gegenüber den Desktopanwendungen einige Funktionsvorteile wie zum Beispiel Aktualisierungen von Livekacheln und Hintergrundaufgaben.
  • Gerätevielfalt: UWP-Apps laufen auf vielen Gerätetypen, u. a. Smartphones, Tablets, Notebooks, Desktoprechnern und sogar auf der Xbox One und der HoloLens.
  • Benutzerfreundlichkeit: Apps sind von ihrer Oberfläche her auf eine hohe Benutzerfreundlichkeit ausgerichtet. Statt komplizierter Bedienfolgen über Menüs sind Touch-Eingabe, reaktive Oberflächen und ein konzentriertes, dem Content angepasstes Layout angesagt.

Bei den genannten Punkten handelt es sich primär um Argumente, die aus Sicht des Nutzers wichtig sind. Aus Entwicklerperspektive betrachtet, kommt noch das Argument der Zukunftsfähigkeit der Plattform hinzu. Es ist zwar nicht damit zu rechnen, dass auf künftigen Windows-Versionen keine Desktopapplikationen mehr laufen, aber die Frage wird sein, inwieweit künftige Features auch für diese Plattform bereitgestellt werden. Momentan sieht es danach aus, als ob Microsoft die UWP auch als die Zukunft für Line-of-Business-Applikationen sieht.

Wir gehen nachfolgend davon aus, dass wir uns entschieden haben, eine bestehende Windows-Desktopanwendung zu einer echten App für die UWP zu migrieren.

Ausgangspunkt Softwaremigration

Der mögliche Wechsel vom Desktop auf die UWP ist ein klassisches Thema der Softwaremigration und ein Evergreen. Die Ursache ist eindeutig: Die Aktualität einer Technologie ist stets begrenzt. Zwar sind ihre Halbwertzeiten durchaus unterschiedlich, aber grundsätzlich ist der IT-Bereich ein sehr dynamisches Umfeld. Unter Migration versteht man im Allgemeinen die Anpassung einer bestehenden Technologie an den aktuellen Stand. Insgesamt ist die IT im betrieblichen Umfeld meist mehreren technischen Generationen zugehörig, sodass für einige Systeme stets ein Bedarf an Migration besteht. Typische Migrationsziele sind die folgenden:

  • Verbesserter Anwendernutzen
  • Bessere Nutzung vorhandener Ressourcen
  • Verbesserte Integration in die vorhandenen Softwaresysteme
  • Verbesserte Interoperabilität
  • Erweiterung des Funktionsumfangs
  • Erhöhung der Produktivität

Je nachdem, welches Ziel das Migrationsvorhaben verfolgt, sind verschiedene oder alle Teile der Softwarearchitektur von der eigentlichen Migration betroffen:

  • Daten und Datenbanken
  • Programme
  • Benutzerschnittstellen
  • Systemschnittstellen

Der Wechsel vom Desktop auf die UWP ist eine Mischung aus Programm- und Benutzerschnittstellenmigration. Bei der Programmmigration bleiben die Datenstrukturen unverändert. Es erfolgt eine Migration der Programme. Diese können in eine andere Sprache in der gleichen Umgebung, in derselben Sprache in eine andere Umgebung oder in eine andere Sprache in eine andere Umgebung migriert werden. Hier bleibt die Programmiersprache (C#) identisch. Es wird zu einer anderen Teilmenge des .NET Frameworks gewechselt. Bei der Benutzungsschnittstellenmigration bleiben dagegen die Programme und die Daten unverändert. Ausgetauscht werden sollen lediglich die Programmteile, die für die Benutzerinteraktion zuständig sind. Diese Art der Migration ist für den Endanwender am deutlichsten sichtbar. Im Sinne eines umfassenden „Facelifts“ kann eine Auffrischung der Applikation erreicht werden. Voraussetzung für eine auf das UI beschränkte Migration ist, dass die restlichen Programmteile (Logik und Datenhaltung) noch in einem akzeptablen technischen Zustand sind. Das UI erfährt dabei üblicherweise einen erheblichen Refresh. Beispielsweise wird es für die Touch-Bedienung fit gemacht. Dagegen werden die für Desktopprogramme üblichen Menüleisten verdrängt oder ganz aufgelöst.

Softwaremigration ist betriebswirtschaftlich eine Investition. Sie muss sich rechnen und wird unter keinen Umständen zum Selbstzweck der IT durchgeführt. Dieser Umstand begründet auch die Tatsache, dass Unternehmen bei einem Wechsel des Systems eher zögerlich reagieren. Solange eine ältere Version eines Systems seine Anforderungen noch erfüllt, gibt es aus dieser Perspektive keine Begründung für einen Wechsel. Im Fall einer anstehenden Migration bestimmen die Größe des Systems, der Grad der Automatisierung und der Testaufwand die Höhe der entstehenden Kosten. Ebenso soll die Kluft zwischen dem Ist- und Sollzustand in die Betrachtung einbezogen werden. Jedes Migrationsvorhaben weist eine eigene Problematik auf, die Randbedingungen sind jedoch ähnlich. Zusammengefasst: Softwaremigrationsprojekte sind komplex und bedürfen einer guten Planung (Abb. 1).

Abb. 1: Die Schrittfolge der Softwaremigration

Desktop on UWP

Was ist damit gemeint? Microsoft stellt seit einiger Zeit einen Converter zur Verfügung, der es erlaubt, bestehende Desktopanwendungen auf der UWP laufen zu lassen. Das primäre Ziel ist dabei, die Fähigkeit des Deployments über den Store mit den o. g. Vorteilen nutzen zu können. Dieses Tool läuft automatisch oder halbautomatisch ab. Es trägt die Bezeichnung Desktop Bridge. Technisch werden keine Änderungen am ursprünglichen Quellcode vorgenommen. Die Anwendung wird in eine Art Sandkasten gepackt und auf diese Weise auf der UWP lauffähig. Sie kann jedoch zunächst weiterhin nur auf PC bzw. Notebooks ausgeführt werden, denn intern sind immer noch die Win32-Aufrufe notwendig. Microsoft erhofft sich auf diese Weise eine größere Auswahl von Apps im Store. Langfristig wird empfohlen, die App schrittweise in Richtung UWP umzustellen, d. h. nach und nach alle Systemfunktionen und -aufrufe aus dem Desktopumfeld gegen die UWP-Features zu tauschen. Wir bezeichnen dieses Vorgehen als sanfte Migration. Wie man die Desktop Bridge anwendet und welche Hürden dabei auf einen zukommen, ist schon Gegenstand vieler Artikel gewesen. Als Einstieg empfiehlt es sich, die Hinweise zur Desktop Bridge von Microsoft selbst zu lesen. Als Ergebnis ist jedoch festzuhalten:

  1. Die Migration gelingt nicht bei allen Anwendungstypen.
  2. Es entsteht keine echte App für die UWP, d. h. der Migrationsdruck bleibt langfristig bestehen.
  3. Die Zahl der erreichten Plattformen steigt nicht.

Aus diesem Grund sehen wir uns nun den Weg der echten Migration an. Das heißt, wir betrachten die nötigen Schritte für den Prozess, der eine Desktopanwendung zu einer App für die UWP macht, die keine „Altlasten“ mehr enthält.

Desktop to UWP

Ein erster Ansatz auf diesem Weg wäre ein völliges Neuschreiben der App. Das hat mit Migration allerdings nichts zu tun, und der Gesamtaufwand ist nahezu identisch wie bei einer vollständigen Neuentwicklung. Es soll daher darum gehen, welche Schritte für eine Migration notwendig sind. Das Ziel: So viel wie möglich vom bestehenden Code transformieren. Gemäß dem allgemeinen Schema beginnen wir auch mit einer Analyse des Legacy-Systems. Wir müssen uns einen Überblick über die Hauptprobleme verschaffen. Bereits jetzt kann man sagen: Je enger die Technologien miteinander verwandt sind, desto einfacher und besser gelingt eine Migration zu einer App für die UWP. Windows-Desktopanwendungen können auf unterschiedliche Arten und Weisen erstellt werden. Gebräuchlich sind zum Beispiel die folgenden:

  • Microsoft .NET mit Windows Forms, programmiert in C# oder Visual Basic .NET
  • Microsoft .NET mit Windows Presentation Foundation (WPF), programmiert in C# oder Visual Basic .NET
  • MFC-Bibliothek (Microsoft Foundation Class), programmiert in Visual C++
  • RAD Studio, programmiert in Delphi
  • Java-Applikationen
  • Visual Basic (nicht mehr aktuell, aber es sind noch viele Anwendungen im Einsatz)

Wir könnten diese Liste noch fortsetzen, das Ergebnis bliebe jedoch identisch. Wirklich für eine Migration zur UWP sind nur die ersten beiden Anwendungstypen geeignet. Für alle andere Typen sind die Systembrüche zu groß, oder es werden sogar unterschiedliche Programmiersprachen verwendet. An dieser Stelle sei nur kurz angemerkt: RAD Studio bietet in der aktuellen Version die Möglichkeit, die erstellten Applikationen mithilfe der Desktop Bridge in den Store zu bringen. Hier sind wir jedoch wieder bei dem eingangs genannten Punkt: Es ist eben nur eine „Verpackung“ und keine richtige UWP-App.

Windows Forms App

Lange Zeit waren Windows-Forms-Applikationen die Technik der Wahl. Noch heute wird diese Technik umfassend von Visual Studio 2017 unterstützt. Es existieren noch unzählige Anwendungen auf der Basis dieser Technik, auch wenn schon viele auf WPF migriert wurden. Ein Migrieren der Benutzeroberfläche auf die Technologie für UWP-Apps ist nicht wirklich möglich. Zu unterschiedlich sind die technologischen Ansätze. In Windows-Forms-Anwendungen wird das UI direkt im grafischen Editor erstellt und ist gewissermaßen untrennbar mit der Logik über die bekannten Code-behind-Dateien verbunden. Nur wenn die Entwickler wirklich sehr sorgfältig und explizit auf die Trennung der Schichten geachtet haben, wurden Architekturprinzipen wie das Model-View-Controller-Muster verwendet. Für die UWP-App muss das UI also vollständig neu erstellt werden. Das bietet auch gleichzeitig die Chance zu einer umfassenden Modernisierung des UI. Die Bedienmuster einer Windows-Forms-Anwendung waren oft komplexer. Suchen Sie nach einem neuen Konzept für das UI! Kompliziert wird es, wenn das UI und die Businesslogik stark miteinander verwoben sind. Typische Fragen, die dabei helfen, das herauszufinden, sind beispielsweise: Wo erfolgt die Validierung der Eingaben? Und welche Funktionen in den Code-behind-Dateien gehören eigentlich in die Businesslogik?

Kostenlos: Docker mit .NET auf einen Blick

Container unter Linux und Windows nutzen? Unser Cheatsheet zeigt Ihnen wie Sie: Container starten, analysieren und Docker.DotNet (in C#) verwenden. Jetzt kostenlos herunterladen!

Download for free

Das Ziel besteht darin, die Businesslogik und die Datenhaltungsschicht möglichst weitgehend aus der Legacy-App zu isolieren, um diese Anwendungsbestandteile weiter verwenden zu können. Bei ganz „schlimmen“ Fällen von Windows-Forms-Anwendungen muss man ehrlich sagen, dass die Migration zur UWP-App zu komplex ist. Hier ist es besser, komplett neu zu starten und lediglich Teile der Businesslogik und der Datenhaltungsschicht per Copy and Paste zu übertragen.

Windows Presentation Foundation

Erste Idee: WPF- und UWP-Anwendungstypen deklarieren die Benutzeroberfläche mithilfe der Beschreibungssprache XAML. Ein Transfer zwischen beiden Systemen sollte daher einfach möglich sein. Die Ernüchterung kommt schnell und speist sich primär aus den folgenden Punkten:

  • Konzeption: Das unterschiedliche Konzept von Desktopanwendungen und UWP-Apps schlägt sich auch auf die Gestaltung des UI nieder. Es ist i. d. R. wenig sinnvoll, die Oberfläche lediglich auf die neue Technologie zu übertragen. Notwendig und wichtig sind meist auch inhaltliche Anpassungen der Benutzerführung! Diese wirken sich auf den XAML-Code maßgeblich aus. Es wird daher meist dazu kommen, dass das UI der UWP-App vollständig neu konzipiert werden muss.
  • Dialekt: Beide UI-Technologien basieren auf XAML. Sie unterscheiden sich jedoch im Dialekt: Namespaces haben eine andere Bezeichnung, Controls funktionieren etwas anders, die Eigenschaften sind nicht identisch oder ein Control gibt es in der Form gar nicht. Auch das Data Binding ist unterschiedlich realisiert. Komplizierter wird es, wenn man umfangreich auf Controls von Drittanbietern gesetzt hat. Dann gilt: Beim Übertragen des UI von XAML für WPF nach XAML für UWP ist Nacharbeit auch auf Ebene des Quellcodes gefragt!

Dennoch fällt das Fazit für WPF-Anwendungen positiv aus: Die Migration in eine App für die UWP ist relativ leicht machbar, nur nicht vollautomatisch. Ein Converter würde auch nicht wirklich helfen, denn eine UWP-App verlangt meist auch nach einer konzeptionellen Anpassung der Bedienoberfläche.

Architektur

Idealerweise haben wir schon immer die empfohlene Schichtentrennung innerhalb der Applikationen beachtet. View, Businesslayer und Data-Layer lassen sich in den meisten Anwendungen ausmachen. In der Praxis sieht es jedoch oft anders aus. Die Migration in eine UWP-App erzwingt gewissermaßen auch eine Überarbeitung der Architektur. Wie soeben erwähnt, ist das Model-View-Controller-Muster hier unverzichtbar und es wurde für UWP und WPF auf das MVVM-Muster konkretisiert (Abb. 2). Auf Code-behind sollte man für eine UWP-App unbedingt verzichten. Lesern, die regelmäßig Anwendungen für WPF bauen, ist das Pattern mit Sicherheit bereits in Fleisch und Blut übergegangen. Um nicht stets alles eigenständig implementieren zu müssen, stehen auch unterstützende Frameworks wie zum Beispiel Prism oder das MVVM Light Toolkit zur Verfügung.

Abb. 2: Das MVVM-Muster als konkrete Ausprägung des MVC-Musters für XAML

Businesslogik

Den Kern einer jeden Anwendung macht die Businesslogik aus. Windows-Desktopanwendungen und UWP-Apps basieren auf .NET. Auch hier gilt: Es werden unterschiedliche Teilmengen des .NET Framework angesprochen (Abb. 3). Hinzu kommen noch unterschiedliche Versionen.

Abb. 3: .NET Framework und Teilmengen (Quelle: Microsoft)

Während WPF- und Windows-Forms-Anwendungen auf dem klassischen .NET Framework basieren, verwenden Apps für die UWP .NET Core. Beide greifen auf die .NET Standard Library als gemeinsame Basis zurück. .NET Standard ist eine formale Spezifikation von .NET APIs, die für alle .NET-Laufzeiten verfügbar sind. Die Motivation hinter .NET Standard ist das Herstellen einer umfassenderen Einheitlichkeit im .NET-Ökosystem. Die verschiedenen .NET Runtimes implementieren bestimmte Versionen von .NET Standard und unterstützen auch frühere Versionen. Ein Beispiel gefällig? NET Framework 4.6 implementiert .NET Standard 1.3 und macht damit alle APIs verfügbar, die in den Versionen 1.0 bis 1.3 von .NET Standard definiert sind. Auf ähnliche Weise implementiert .NET Framework 4.6.1 .NET Standard 1.5, während .NET Core 1.0 .NET Standard 1.6 implementiert. Die Matrix in Abbildung 4 zeigt das gesamte Versionschaos. Hier durchzublicken, ist wirklich eine Kunst!

Abb. 4: Versionen von .NET Standard und die unterstützten Plattformen

Es muss also auch geprüft werden, auf welchem .NET Framework die Altanwendung basiert. Gibt es die Klassen auch in .NET Core? Und sollte das nicht der Fall sein: welche alternativen Ansätze stehen bereit? Einen größeren Anpassungsbedarf muss man für die Quellcodeteile fürchten, die auf Systemfunktionen wie beispielsweise das Öffnen von Dialogfeldern für die Dateiauswahl zurückgreifen. Die UWP gibt sich hier aus Sicherheitsgründen deutlich reservierter. Welche Teile des Quellcodes wirklich auf der Basis des klassischen .NET Frameworks durch .NET Standard abgedeckt werden, lässt sich vor einer möglichen Migration testen. Dazu installiert man die Extension .NET Portability Analyzer. Damit können bestehende .NET-Projekte automatisch analysiert werden. Das Ergebnis ist ein Bericht, der eine klare Aussage darüber trifft, wie hoch der Grad der Portabilität ist. Den Analyseprozess startet man komfortabel aus dem Projektmappen-Explorer. Es wird dann für alle verwendeten Typen des Programms in einem Bericht angezeigt, ob diese durch .NET Standard abgedeckt werden. In der Summe wird der Grad der Portabilität in Prozent angegeben.

Die Algorithmen für die Fachlogik sollten sich dagegen meist ohne Anpassung übernehmen lassen, da stets die Sprache C# zur Anwendung kommt. Aber auch hier gilt: Nutzen Sie ggf. die Migration auch als Möglichkeit zu einem umfassenden Refactoring des Quellcodes. Die Sprache C# hat sich in den letzten Jahren deutlich weiterentwickelt, sodass man Sachverhalte kompakter und einfacher als noch vor einigen Jahren ausdrücken kann. Grundsätzlich gilt aber: Läuft der Code, sind Anpassungen an diesen Stellen zunächst sekundär.

Datenhaltung

Hier ist zunächst zu klären, inwieweit eingabeintensive Benutzeroberflächen, die zum Beispiel im ursprünglichen Programm mithilfe eines DataGrids realisiert wurden, mit dem Konzept einer UWP-App zusammenpassen. Apps für die UWP sollen ggf. auch mit Touch-Eingabe bedient werden können. Ein DataGrid wird von Haus aus nicht von Microsoft angeboten. Hier ist man auf Controls von Drittanbietern angewiesen. UWP-Apps sind vielmehr auf einen Datenzugriff in der Cloud, zum Beispiel auf der Basis von Microsoft Azure, ausgelegt. Zwar lässt sich eine Datenbankverbindung zu einem SQL Server herstellen, aber das gesamte Portfolio der Datenbankprogrammierung ist zum heutigen Stand nicht für die UWP verfügbar. Möchte man Datenbankapplikationen dennoch umsetzen, findet man Hilfe im Microsoft Dev Center. Hier werden zwei Optionen genannt:

  • Entity Framework Core mit SQLite für C#-Apps
  • SQLite-Datenbanken

Wir kommen daher beim heutigen Stand zu folgendem Fazit: Anwendungen, die primär Datenbankanfragen bedienen, sind heutzutage deutlich besser als WPF-Applikation aufgehoben. Eine Migration zu einer UWP-App ist keine brauchbare Alternative. Der Gewinn an technischem Fortschritt rechtfertigt unseres Erachtens den Aufwand und die zu erwartenden Probleme nicht. Die Technik der Datenbankanwendungen ist unter WPF ausgereift, es ist daher wenig sinnvoll, mit Workarounds zu arbeiten. Liegt noch eine Windows-Form-Anwendung vor, empfehlen wir die Migration nach WPF. Diese Technologie wird sicherlich noch einige Jahre der Stand der Technik für die meisten Line-of-Business-Applikationen bleiben. Irgendwie ist das Konzept von Microsoft an dieser Stelle noch nicht gänzlich rund. Sollen Apps für die UWP langfristig alle Applikationen für den Desktop ersetzen, braucht es deutlich mehr Programmierunterstützung zur Anbindung von Datenbanken. Anderseits gilt aber auch: Was will man mit dieser Art von Apps auf den mobilen Geräten anfangen? Hier muss man einfach mal abwarten, in welche Richtung die Entwicklung geht und ob beide Anwendungsarten in der Zukunft in einem gemeinsamen Strang enden.

Fallbeispiel

Sehen wir uns die Vorgehensweise der Anwendungsmigration an einem kleinen Beispiel an. Es empfiehlt sich, erste Erfahrungen an weniger komplexen Applikationen zu sammeln. Wir wollen uns in groben Schritten die Migration eines kleinen WPF-Tools zur Bildverarbeitung ansehen. Es handelt sich um einen einfachen Bildbetrachter mit der Option, die Dateigrößen von beliebig vielen Bildern (Fileformat: .jpg) im Batch-Betrieb in einem Rutsch zu verringern. Hintergrund: Bei der digitalen Fotografie mit einer Systemkamera sind die Bilddateien aufgrund der hohen Auflösung meist sehr groß. Um die Bilder dennoch schnell zu teilen, sollen sie per E-Mail versendet werden. Auf diese Weise kann man beispielsweise die richtigen Fotos für die weitere Verarbeitung gemeinsam aussuchen, ohne dass man am selben Gerät sitzt. Abbildung 5 zeigt das UI der WPF-Anwendung.

Abb. 5: Das UI des Bildbetrachters in WPF

Wie bereits beschrieben, haben wir für das Beispielprojekt die Portabilität mithilfe des Tools .NET Portability Analyzer geprüft. Das Ergebnis war wenig berauschend: Lediglich knapp 54 Prozent des vorhandenen Codes werden durch .NET Standard abgedeckt. Das ist kein Wunder, denn die Bildverarbeitung verwendet viele spezifische Funktionen des .NET Frameworks.

Hier kommen nicht viele Oberflächenelemente zum Einsatz. Eine Migration zu einer App für die UWP sollte daher relativ einfach machbar sein. Abbildung 6 zeigt das UI nach der Migration.

Abb. 6: Das UI nach Migration zur UWP

Der Weg von Abbildung 5 zu Abbildung 6 hat natürlich mehr als nur einen Schritt. Zuerst wurde ein neues Projekt in Visual Studio angelegt und das UI entworfen. Es empfiehlt sich, beide Applikationen in unterschiedlichen Instanzen von Visual Studio zu öffnen. Nachdem man den Rahmencode für eine neue UWP-App erstellt hat (Assistent, Windows Template Studio), kann man durchaus Strukturen und einzelne Komponenten auf der Basis des XAML-Codes übernehmen. Empfehlung: Testen Sie das UI umfassend in frühen Anwendertests. Fragen Sie auch danach, ob es noch andere Einsatzszenarien gibt. Soll die App auch auf mobilen Geräten genutzt werden? In unserem Beispiel war das nicht der Fall, die neue App sollte weiterhin nur am Notebook bzw. PC verwendet werden.

Kommen wir zur Businesslogik, die primär aus Algorithmen zur Bildverarbeitung besteht. Die Klassen zur Bildverarbeitung sind beim .NET Framework und bei .NET Core verschieden. Nach etwas Recherche im Internet kommt man jedoch schnell dahinter, welche Anpassungen notwendig sind. Wichtig: UWP-Apps müssen stets reaktionsfähig bleiben. Daher wird man sehr oft auf die asynchrone Programmierung zurückgreifen. Die beiden Schlüsselwörter aus C# sind async und await. Für unser Beispiel war es u. a. beim Einlesen der Bilddateien und beim Speichern notwendig. Unter WPF war das Konzept noch nicht verpflichtend. Bei UWP-Apps ist es durchgängig in den Bibliotheken verankert, d. h. viele Methoden stehen nur noch als asynchrone Variante zur Verfügung.

Das Ergebnis ist eine UWP-App mit neuem UI. Die Funktionalität ist grundsätzlich in der ersten Version die gleiche wie bei der Altapplikation. Es empfiehlt sich, auch diese grundsätzlich beizubehalten oder ggf. zu verringern, denn es gilt: Eine Anwendungsmigration und eine Funktionserweiterung sind zwei unterschiedliche Baustellen!

Fazit

Eine Sichtweise ist in unserer Betrachtung allerdings zu kurz gekommen: Was sagt der Nutzer zu alledem? Eigentlich ist es dem fast wurscht! Sowohl für den klassischen Desktop als auch für die UWP lassen sich moderne und ansprechende Apps bauen. Im betrieblichen Umfeld spielt die Vertriebsoption über den öffentlichen Store keine wirkliche Rolle. Apps für UWP können zwar nur auf dem Betriebssystem Windows 10 ausgeführt werden, dafür jedoch ggf. auf mobilen Geräten. Vorherige Versionen von Windows bleiben also außen vor. Ob das Argument der Gerätevielfalt zieht, ist im Einzelfall kritisch zu hinterfragen. Der Grund: Auch im betrieblichen Umfeld dominieren Android und iOS für Smartphones und Tablets, die mit einer UWP-App nichts anfangen können. Es bleiben also die Argumente Zukunftssicherheit und technische Optionen.

Wie lautet nun das Fazit? Eine vollständige Migration einer Desktopanwendung zu einer App gelingt i. d. R., ist aber durchaus aufwändig. Der Aufwand ist umso größer, je mehr spezifische UI Controls verwendet wurden. Manche Anwendungsszenarien wie Datenbankanwendungen und Anwendungen mit komplexen Eingabeformularen sind als WPF-Anwendungen besser aufgehoben. Das Fazit fällt also gemischt aus: Der Desktop ist nicht tot! Alle Line-of-Business-Applikationen zu migrieren, geht noch nicht, und auch der Aufwand wäre aktuell noch nicht gerechtfertigt. Wägen Sie also im Vorfeld gründlich ab. Vielleicht lohnt es sich, zunächst mit kleineren Tools den Schritt zu wagen.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -