Portieren von Windows Phone Silverlight zu XAML: Windows-Runtime 8

Portieren von Windows Phone Silverlight zu XAML: Windows-Runtime 8

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation]

Hinweis  Informationen zum Portieren einer Universal Windows Platform (UWP)-App für Windows 10 finden Sie unter Wechsel von Windows Phone Silverlight zu UWP.
 

Beim Portieren einer Windows Phone Silverlight-App zum Modell für XAML-Windows-Runtime-Apps können Sie auf Ihre Kenntnisse und Erfahrungen sowie einen Großteil Ihres Quellcodes und Ihrer Softwaremuster zurückgreifen. Auch Ihr UI-Markup und -Design lassen sich mühelos portieren. Obwohl es die eine oder andere Herausforderung zu meistern gilt, werden Sie vielleicht überrascht sein, wie einfach der Prozess letztlich ist.

Sie können beim Lesen dieses Handbuchs für das Portieren ggf. weitere Informationen im vorangehenden Thema nachschlagen: Windows Phone Silverlight, Windows-Runtime-Namespace und Klassenzuordnungen. Im Allgemeinen ist die Zuordnung recht einfach, es gibt aber einige Ausnahmen. In der Tabelle mit den Namespace- und Klassenzuordnungen werden sämtliche Ausnahmen beschrieben. Einige Ausnahmen auf Featureebene sind jedoch auch im Hauptthema (Wechsel von Windows Phone Silverlight zu WinRT) aufgeführt.

Weitere Informationen zu XAML-basierten Windows Store-Apps im Allgemeinen finden Sie unter Roadmap für Windows-Runtime-Apps mit C# oder Visual Basic.

Portieren der einzelnen Ebenen

  • Ansicht. Die Ansicht und das Ansichtsmodell bilden die UI Ihrer App. Im Idealfall besteht die Ansicht aus Markup, das an feststellbare Eigenschaften eines Ansichtsmodells gebunden ist. Ein weiteres gängiges, aber nur auf kurze Sicht zweckmäßiges Muster ist das direkte Ändern von UI-Elementen mit imperativem Code in einer CodeBehind-Datei. In beiden Fällen kann ein Großteil des UI-Markups und -Designs – und sogar imperativer Code zum Ändern von UI-Elementen – einfach portiert werden.
  • Ansichtsmodelle und Datenmodelle. Auch wenn Sie Muster zur Trennung der Zuständigkeiten (z. B. MVVM) nicht ausdrücklich anwenden, gibt es in Ihrer App zwangsläufig Code, der die Funktion des Ansichts- und Datenmodells übernimmt. Code für das Ansichtsmodell nutzt Typen in den Namespaces des Benutzeroberflächenframeworks. Sowohl der Code für das Ansichtsmodell als auch der Code für das Datenmodell nutzen zudem nicht visuelle Betriebssystem- und .NET Framework-APIs (darunter APIs für den Datenzugriff). Und da die meisten dieser APIs für Windows-Runtime-Apps verfügbar sind, können Sie davon ausgehen, dass sich ein Großteil dieses Codes ohne Änderungen portieren lässt. Bedenken Sie aber, dass ein Ansichtsmodell ein Modell oder eine Abstraktion einer Ansicht ist. Ein Ansichtsmodell stellt den Zustand und das Verhalten der UI bereit, während die Ansicht selbst die visuellen Elemente bereitstellt. Aus diesem Grund sind wahrscheinlich für jede UI, die Sie an die verschiedenen, von der Windows-Runtime unterstützten Formfaktoren anpassen, entsprechende Änderungen des Ansichtsmodells erforderlich.
  • Cloud-Dienste. Höchstwahrscheinlich werden einige (oder sogar die meisten) Teile Ihrer App in Form von Diensten in der Cloud ausgeführt. Der auf dem Clientgerät ausgeführte Teil der App stellt eine Verbindung mit diesen Diensten her. Dies ist der Teil einer verteilten App, bei dem es am wahrscheinlichsten ist, dass er beim Portieren des Clientteils unverändert bleibt. Falls Sie noch keine Clouddienste nutzen, sind Microsoft Azure Mobile Services eine gute Wahl für Ihre universelle Windows-App. Sie bieten leistungsstarke Back-End-Komponenten, die universelle Windows-Apps für verschiedene Dienste aufrufen können – angefangen bei einfachen Benachrichtigungen für Live-Kachelupdates bis hin zur komplexen Skalierbarkeit, die eine Serverfarm bereitstellen kann.

Überlegen Sie vor oder während der Portierung, ob Ihre App dadurch verbessert werden könnte, wenn Sie sie umgestalten und Code mit einem ähnlichen Zweck in Ebenen zusammenfassen, anstatt ihn willkürlich zu verteilen. Die Aufteilung Ihrer Universal Windows-App in Ebenen wie die oben beschriebenen erleichtert Ihnen das Ausschließen von Fehlern, Testen und spätere Lesen und Warten Ihrer App. Sie können die Wiederverwendbarkeit von Funktionen verbessern – und Probleme mit Unterschieden in den UI-APIs vermeiden –, indem Sie das Model-View-ViewModel (MVVM)-Muster anwenden. Dieses Muster trennt die Daten-, Geschäfts- und UI-Teile der App voneinander. Auch innerhalb der UI kann das Muster Zustand und Verhalten von den visuellen Elementen getrennt halten, sodass diese separat getestet werden können. Das MVVM-Muster bietet Ihnen die Möglichkeit, Ihre Daten- und Geschäftslogik einmal zu schreiben und auf allen Plattformen zu verwenden. Außerdem ist es sehr wahrscheinlich, dass ein Großteil des Ansichtsmodells und der Ansichtsteile plattformübergreifend wiederverwendet werden kann, dies variiert allerdings von App zu App.

Das App-Paketmanifest

Kenntnisse in der Bearbeitung des App-Paketmanifests sind unbedingt von Vorteil, da es in den folgenden Themen um seine Verwendung für verschiedene Deklarationen, Funktionen und andere Einstellungen geht, die für einige Features erforderlich sind. Sie können das Manifest mit dem App-Paketmanifest-Editor von Visual Studio bearbeiten. Falls der Projektmappen-Explorer nicht angezeigt wird, wählen Sie ihn im Menü Ansicht aus. Doppelklicken Sie auf Package.appxmanifest. Dadurch wird das Fenster des Manifest-Editors geöffnet. Klicken Sie auf die gewünschte Registerkarte, nehmen Sie Ihre Änderungen vor, und speichern Sie sie.

Inhalt dieses Abschnitts

ThemaBeschreibung

Portieren des Projekts

Sie beginnen den Portierungsprozess, indem Sie zunächst in Visual Studio ein neues Windows-Runtime-Projekt (eine Art Store-Projekt) erstellen und Ihre Dateien in das Projekt kopieren. Falls Sie sich für ein universelles App-Projekt entscheiden, können Sie mit einer Codebasis sowohl PCs, Tablets als auch Smartphones unterstützen.

Fehlerbehebung

Wir empfehlen dringen, dieses Handbuch für das Portieren vollständig zu lesen, wir wissen jedoch auch, dass Sie möglichst schnell die Phase erreichen möchten, in der Ihr Projekt erstellt und ausgeführt wird. Zu diesem Zweck können Sie einen temporären Fortschritt erzielen, indem Sie allen nicht unbedingt erforderlichen Code auskommentieren und anschließend zurückkehren, um die Schulden später zu bezahlen. Die Tabelle mit Symptomen und Möglichkeiten zur Problembehandlung in diesem Thema kann in dieser Phase hilfreich für Sie sein, ersetzt jedoch nicht das Lesen der nächsten Themen. Sie können die Tabelle jederzeit zu Rate ziehen, während Sie die weiteren Themen lesen.

Portieren von XAML und UI

Die Vorgehensweise zum Definieren einer UI in Form von deklarativem XAML-Markup lässt sich sehr gut von Windows Phone Silverlight- auf Windows-Runtime-Apps übertragen. Sie werden feststellen, dass große Abschnitte Ihres Markups kompatibel sind, sobald Sie Verweise auf Systemressourcenschlüssel aktualisiert, einige Namen von Elementtypen geändert und „clr-namespace“ in „using“ geändert haben.

Portieren: E/A, Gerät und App-Modell

Code, der in das Gerät selbst integriert und auf dessen Sensoren abgestimmt ist, umfasst auch die Eingabe des Benutzers und die Ausgabe für den Benutzer. Auch die Datenverarbeitung kann einbezogen werden. Aber dieser Code wird in der Regel nicht als UI-Ebene oder Datenebene betrachtet. Dieser Code enthält die Integration in Vibrationscontroller, Beschleunigungsmesser, Gyroskop, Mikrofon und Lautsprecher (überschneiden sich mit Spracherkennung und Sprachsynthese), (geografischen) Standort und Eingabemodalitäten, z. B. Touch, Maus, Tastatur und Stift.

Portieren der Geschäfts- und Datenebene

Im Hintergrund Ihrer UI befinden sich Ihre Geschäfts- und Datenebenen. Der Code auf diesen Ebenen ruft Betriebssystem- und .NET Framework-APIs auf (z. B. Hintergrundverarbeitung, Position, Kamera, Dateisystem, Netzwerk und andere Datenzugriffsfunktionen). Die meisten dieser APIs sind für Windows-Runtime-Apps verfügbar. Sie können daher davon ausgehen, dass sich ein Großteil dieses Codes ohne Änderungen portieren lässt.

Portieren für Formfaktor und Benutzerfreundlichkeit

Windows-Apps bieten ein einheitliches Aussehen und Verhalten auf PCs, Tablet PCs und Smartphones. Die Benutzeroberfläche, Eingabe und Interaktionsmuster sind fast identisch, und Benutzer profitieren von einer einheitlichen Umgebung auf allen Geräten. Jedoch gibt es praxisbezogene Unterschiede zwischen Geräten, z. B. physische Größe, Standardausrichtung und effektive Pixelauflösung, die sich auf die Darstellung einer Universal Windows-App auswirken.

Fallstudie: Bookstore1

In diesem Thema wird eine Fallstudie für das Portieren einer sehr einfachen Windows Phone Silverlight-App zu einer Universal Windows-App (mithilfe der Windows-Runtime oder WinRT) vorgestellt. Die App besteht aus einer ListBox, die an ein Ansichtsmodell gebunden ist. Das Ansichtsmodell verfügt über eine Liste von Büchern, die Titel, Autor und Bucheinband anzeigt.

Fallstudie: Bookstore2

Diese Fallstudie baut auf den Informationen aus Bookstore1 auf und beginnt mit einer Windows Phone Silverlight-App, die gruppierte Daten in einem LongListSelector anzeigt. Im Ansichtsmodell stellt jede Instanz der Author-Klasse die Gruppe der vom betreffenden Autor verfassten Titel dar. In LongListSelector können wir dann entweder die Bücherliste nach Autoren gruppiert anzeigen oder die Liste verkleinern, um eine Sprungliste der Autoren zu erhalten.

Fallstudie: Bookstore3

Dies ist die dritte Fallstudie einer Reihe, die erläutert, wie Windows Phone Silverlight-Apps (mithilfe der Windows-Runtime oder WinRT) auf Universal Windows-Apps portiert werden. Sie vervollständigt die Portierungstechniken, die in Bookstore1 und Bookstore2 erläutert wurden. Außerdem werden das Ansichtsmodell und die Benutzeroberfläche der hier vorgestellten App durch wichtige neue Features ergänzt.

 

Verwandte Themen

Windows Phone Silverlight, Windows-Runtime-Namespace und Klassenzuordnungen.
Windows-Runtime-Referenz
Übersicht über .NET für Windows Store-Apps
.NET für Windows Store-Apps
UX-Design für Apps

 

 

Anzeigen:
© 2017 Microsoft