Freigeben über

Wechsel von Windows Phone Silverlight zur UWP

  • Artikel

Entwickler, die über eine Windows Phone Silverlight-App verfügen, können beim Wechsel zu Windows 10 auf Ihre Kenntnisse und Fähigkeiten zurückgreifen und Ihren vorhandenen Quellcode umfassend nutzen. Mit Windows 10 können Sie eine Universelle Windows-Plattform (UWP)-App erstellen, bei der es sich um ein einzelnes App-Paket handelt, das Ihre Kunden auf jeder Art von Gerät installieren können. Weitere Hintergrundinformationen zu Windows 10, UWP-Apps und den Konzepten von adaptivem Code und adaptiver UI, die in diesem Portierungshandbuch erwähnt werden, finden Sie in der Anleitung zu Universelle Windows-Plattform (UWP)-Apps.

Wenn Sie Ihre Windows Phone Silverlight-App zu einer Windows 10-App portieren, können Sie sich über die in Windows Phone 8.1 eingeführten mobilen Features informieren und weit darüber hinausgehen, um die Universelle Windows-Plattform (UWP) zu verwenden, deren App-Modell und Benutzeroberflächenframework auf allen Windows 10-Geräten universell sind. Dies ermöglicht es, PCs, Tablets, Smartphones und eine große Anzahl anderer Gerätearten von einer Codebasis und mit einem App-Paket zu unterstützen. Und das multipliziert die potenzielle Zielgruppe Ihrer App und schafft neue Möglichkeiten mit freigegebenen Daten, gekauften Verbrauchsartikeln usw. Weitere Informationen zu neuen Features finden Sie unter What's new for developers in Windows 10.

Wenn Sie sich dafür entscheiden, kann die Windows Phone Silverlight-Version Ihrer App und die Windows 10-Version gleichzeitig für Kunden verfügbar sein.

Hinweis : Dieser Leitfaden soll Ihnen helfen, Ihre Windows Phone Silverlight-App manuell zu Windows 10 zu portieren. Zusätzlich zur Verwendung der Informationen in diesem Handbuch zum Portieren Ihrer App können Sie die Entwicklervorschau der Silverlight-Brücke von Mobilize.NET ausprobieren, um den Portierungsprozess zu automatisieren. Dieses Tool analysiert den Quellcode Ihrer App und konvertiert Verweise auf Windows Phone Silverlight-Steuerelemente und -APIs in ihre UWP-Entsprechungen. Da sich dieses Tool noch in der Entwicklervorschau befindet, werden noch nicht alle Konvertierungsszenarien behandelt. Die meisten Entwickler sollten jedoch einige Zeit und Mühe sparen können, indem Sie mit diesem Tool beginnen. Um die Entwicklervorschau zu testen, besuchen Sie die Website von Mobilize.NET.

XAML und .NET oder HTML?

Windows Phone Silverlight verfügt über ein XAML-UI-Framework, das auf Silverlight 4.0 basiert, und Sie programmieren mit einer Version von .NET Framework und einer kleinen Teilmenge von Windows-Runtime-APIs. Da Sie extensible Application Markup Language (XAML) in Ihrer Windows Phone Silverlight-App verwendet haben, ist es wahrscheinlich, dass XAML für Ihre Windows 10-Version Ihre Wahl ist, da die meisten Kenntnisse und Erfahrungen übertragen werden, wie der Großteil Ihres Quellcodes und der verwendeten Softwaremuster. Selbst Ihr UI-Markup und -Design können problemlos portieren. Sie finden die verwalteten APIs, das XAML-Markup, das UI-Framework und die Tools, die alle vertraut sind, und Sie können C++, C# oder Visual Basic zusammen mit XAML in einer UWP-App verwenden. Vielleicht sind Sie überrascht, wie relativ einfach der Prozess ist, auch wenn es auf dem Weg eine oder zwei Herausforderungen gibt.

Siehe Roadmap für Universelle Windows-Plattform (UWP)-Apps mit C# oder Visual Basic.

Hinweis: Windows 10 unterstützt viel mehr .NET Framework als eine Windows Phone Store-App. Windows 10 verfügt beispielsweise über mehrere System.ServiceModel.* Namespaces sowie System.Net, System.Net.NetworkInformation und System.Net.Sockets. Jetzt ist also ein guter Zeitpunkt, Um Ihre Windows Phone Silverlight zu portieren und Ihren .NET-Code einfach kompilieren und auf der neuen Plattform arbeiten zu lassen. Siehe Namespace und Klassenzuordnungen. Ein weiterer guter Grund, den vorhandenen .NET-Quellcode in eine Windows 10-App neu zu kompilieren, besteht darin, dass Sie von .NET Native profitieren, von einer Vorabkompilierungstechnologie, die MSIL in systemeigenem Computercode konvertiert. .NET Native-Apps starten schneller, verbrauchen weniger Arbeitsspeicher und benötigen weniger Akkuenergie als ihre MSIL-Gegenstücke.

Dieses Portierungshandbuch konzentriert sich auf XAML. Alternativ können Sie eine funktional gleichwertige App erstellen, die viele der gleichen Windows-Runtime-APIs aufruft– mit JavaScript, Cascading StyleSheets (CSS) und HTML5 zusammen mit der Windows-Bibliothek für JavaScript. Obwohl sich die Windows-Runtime UI-Frameworks von XAML und HTML unterscheiden sich voneinander, je nachdem, welches Sie auswählen, wird universell über die gesamte Palette von Windows-Geräten hinweg funktionieren.

Adressierung der universellen oder mobilen Gerätefamilie

Eine Möglichkeit besteht darin, Ihre App zu einer App zu portieren, die auf die universelle Gerätefamilie ausgerichtet ist. In diesem Fall kann die App auf der breitesten Palette von Geräten installiert werden. Wenn Ihre App APIs aufruft, die nur in der Mobilgerätfamilie implementiert sind, können Sie diese Aufrufe mit adaptivem Code schützen. Alternativ können Sie Ihre App zu einer App portieren, die auf die Mobilgerätefamilie ausgerichtet ist. In diesem Fall müssen Sie keinen adaptiven Code schreiben.

Anpassen der App an mehrere Formfaktoren

Die Option, die Sie im vorherigen Abschnitt auswählen, bestimmt den Bereich der Geräte, auf denen Ihre App oder Apps ausgeführt werden, und dies kann eine sehr breite Palette von Geräten sein. Auch wenn Sie Ihre App auf die Mobilgerätefamilie beschränken, bleiben Sie immer noch mit einer Vielzahl von Bildschirmgrößen zur Unterstützung. Da Ihre App also auf Formfaktoren ausgeführt wird, die sie bisher nicht unterstützt haben, testen Sie die Benutzeroberfläche auf diesen Formfaktoren, und nehmen Sie alle erforderlichen Änderungen vor, damit sich die Benutzeroberfläche entsprechend an den einzelnen Formularfaktoren anpasst. Sie können sich dies an eine Aufgabe nach der Portierung oder ein Portierungsdehnungsziel vorstellen, und es gibt ein Beispiel dafür in der Bookstore2-Fallstudie .

Näherung der Portierung layer-by-Layer

  • Ansicht. Die Ansicht (zusammen mit dem Ansichtsmodell) besteht aus der Benutzeroberfläche Ihrer App. Im Idealfall besteht die Ansicht aus Markup, das an feststellbare Eigenschaften eines Ansichtsmodells gebunden ist. Ein weiteres Muster (allgemein und bequem, aber nur kurzfristig) ist für imperativen Code in einer CodeBehind-Datei, um UI-Elemente direkt zu bearbeiten. In beiden Fällen ist ein Großteil ihres UI-Markups und Designs – und sogar imperativer Code, der UI-Elemente bearbeitet – einfach portierbar.
  • Ansichtsmodelle und Datenmodelle. Selbst wenn Sie Muster für Trennungsaspekte (z. B. MVVM) nicht formal nutzen, gibt es in Ihrer App zwangsläufig Code, der die Funktion des Ansichtsmodells und des Datenmodells ausführt. Der Ansichtsmodellcode verwendet Typen in den Ui-Framework-Namespaces. Sowohl ansichtsmodell- als auch Datenmodellcode verwenden auch nicht visuelle Betriebssystem- und .NET-APIs (einschließlich APIs für den Datenzugriff). Und die meisten dieser Apps sind für eine UWP-App verfügbar, sodass Sie davon ausgehen können, dass Sie einen Großteil dieses Codes ohne Änderung portieren können. Denken Sie jedoch daran: Ein Ansichtsmodell ist ein Modell oder eine Abstraktion einer Ansicht. Ein Ansichtsmodell stellt den Zustand und das Verhalten der Benutzeroberfläche bereit, während die Ansicht selbst die visuellen Elemente bereitstellt. Aus diesem Grund benötigen alle Ui, die Sie an die verschiedenen Formfaktoren anpassen, mit denen die UWP ausgeführt werden kann, wahrscheinlich entsprechende Ansichtsmodelländerungen. Bei Netzwerken und Aufrufen von Clouddiensten haben Sie in der Regel die Möglichkeit, .NET- oder Windows-Runtime-APIs zu verwenden. Informationen zu den Faktoren, die bei der Entscheidungsfindung beteiligt sind, finden Sie unter Clouddienste, Netzwerk und Datenbanken.
  • Clouddienste: Es ist wahrscheinlich, dass einige Ihrer Apps (vielleicht eine große Menge davon) in der Cloud in Form von Diensten ausgeführt werden. Der Teil der App, der auf dem Clientgerät ausgeführt wird, stellt eine Verbindung mit diesen verbindungen bereit. Dies ist der Teil einer verteilten App, der wahrscheinlich beim Portieren des Clientparts unverändert bleibt. Wenn Sie noch nicht über eine Option verfügen, ist eine gute Clouddiensteoption für Ihre UWP-App Microsoft Azure Mobile Services, die leistungsstarke Back-End-Komponenten bereitstellt, die universelle Windows-Apps für Dienste aufrufen können, von einfachen Benachrichtigungen für Live-Kachelupdates bis hin zu der Art von schwerer Skalierbarkeit, die eine Serverfarm bereitstellen kann.

Überlegen Sie vor oder während der Portierung, ob Ihre App verbessert werden könnte, indem Sie sie umgestalten, sodass Code mit einem ähnlichen Zweck in Ebenen zusammengefasst und nicht willkürlich verteilt wird. Das Aufteilen Ihrer UWP-App in Ebenen wie die oben beschriebenen erleichtert Es Ihnen, Ihre App korrekt zu machen, sie zu testen und anschließend zu lesen und zu verwalten. Sie können die Funktionalität wiederverwendbar machen und einige Probleme der UI-API-Unterschiede zwischen Plattformen vermeiden, indem Sie dem Model-View-ViewModel (MVVM)-Muster folgen. Mit diesem Muster werden die Daten-, Geschäfts- und UI-Teile Ihrer App voneinander getrennt. Auch innerhalb der Benutzeroberfläche kann der Zustand und das Verhalten von den visuellen Elementen getrennt und separat getestet werden. Mit MVVM können Sie Ihre Daten und Geschäftslogik einmal schreiben und auf allen Geräten verwenden, unabhängig von der Benutzeroberfläche. Es ist wahrscheinlich, dass Sie auch einen Großteil des Ansichtsmodells und der Ansichtsteile auf allen Geräten wiederverwenden können.

Eine oder zwei Ausnahmen von der Regel

Während Sie dieses Portierungshandbuch lesen, können Sie auf Namespace und Klassenzuordnungen verweisen. Die einfache Zuordnung ist die allgemeine Regel, und in der Tabelle mit Namespace- und Klassenzuordnungen werden alle Ausnahmen beschrieben.

Auf Featureebene ist die gute Nachricht, dass es sehr wenig gibt, das in der UWP nicht unterstützt wird. Der Großteil Ihres Qualifikationssatzes und Quellcodes übersetzt sich sehr gut in UWP-Apps, wie Sie im restlichen Portierungshandbuch lesen werden. Hier sind jedoch die wenigen Windows Phone Silverlight-Features, die Sie möglicherweise verwendet haben, für die es keine UWP-Entsprechung gibt.

Feature, für das keine UWP-Entsprechung vorhanden ist Windows Phone Silverlight-Dokumentation für das Feature
Microsoft XNA. Im Allgemeinen ist Microsoft DirectX mit C++ der Ersatz. Siehe Entwickeln von Spielen und DirectX- und XAML-Interoperabilität. XNA Framework-Klassenbibliothek
Objektiv-Apps Linsen für Windows Phone 8

 

Thema Beschreibung
Namespace- und Klassenzuordnungen Dieses Thema enthält eine umfassende Zuordnung von Windows Phone Silverlight-APIs zu ihren UWP-Entsprechungen.
Portieren des Projekts Sie beginnen mit dem Portierungsprozess, indem Sie ein neues Windows 10-Projekt in Visual Studio erstellen und Ihre Dateien in das Projekt kopieren.
Problembehandlung Es wird dringend empfohlen, das Ende dieses Portierungshandbuchs zu lesen, aber wir wissen auch, dass Sie sich darauf freuen, voranzuschreiten und in die Phase zu gelangen, in der Ihr Projekt erstellt und ausgeführt wird. Zu diesem Zweck können Sie temporäre Fortschritte erzielen, indem Sie alle nicht unbedingt benötigten Code kommentieren oder verstören und dann später zurückkehren, um diese Verschuldung abzuzahlen. Die Tabelle der Problembehandlungssymptome und Heilmittel in diesem Thema kann ihnen in diesem Stadium hilfreich sein, obwohl es kein Ersatz zum Lesen der nächsten Themen ist. Sie können immer wieder auf die Tabelle verweisen, während Sie die späteren Themen durcharbeiten.
Portieren von XAML und Benutzeroberfäche Die Vorgehensweise zum Definieren der Benutzeroberfläche in Form von deklarativem XAML-Markup übersetzt äußerst gut von Windows Phone Silverlight in UWP-Apps. Sie werden feststellen, dass große Abschnitte Ihres Markups kompatibel sind, nachdem Sie Verweise auf Systemressourcenschlüssel aktualisiert, einige Elementtypnamen geändert und "clr-namespace" in "using" geändert haben.
Portieren für E/A, Gerät und App-Modell Code, der in das Gerät selbst und seine Sensoren integriert wird, umfasst Eingaben und Ausgaben für den Benutzer. Sie kann auch die Verarbeitung von Daten umfassen. Dieser Code wird jedoch im Allgemeinen nicht als UI-Ebene oder als Datenebene betrachtet. Dieser Code umfasst die Integration mit dem Vibrationscontroller, Beschleunigungsmesser, Gyroskop, Mikrofon und Lautsprecher (die sich mit Spracherkennung und Synthese schneiden), (geo)position und Eingabemodalitäten wie Toucheingabe, Maus, Tastatur und Stift.
Portieren von Geschäfts- und Datenebenen Hinter der Benutzeroberfläche befinden sich Ihre Geschäfts- und Datenebenen. Der Code in diesen Ebenen ruft Betriebssystem- und .NET Framework-APIs auf (z. B. Hintergrundverarbeitung, Standort, Kamera, Dateisystem, Netzwerk und anderer Datenzugriff). Die meisten dieser Apps sind für eine UWP-App verfügbar, sodass Sie davon ausgehen können, dass Sie einen Großteil dieses Codes ohne Änderung portieren können.
Portieren für Formfaktor und UX Windows-Apps weisen auf PCs, Mobilgeräten und vielen anderen Arten von Geräten ein einheitliches Erscheinungsbild auf. Die Benutzeroberfläche, Eingabe und Interaktionsmuster sind fast identisch, und Benutzer profitieren von einer einheitlichen Umgebung auf allen Geräten.
Fallstudie: Bookstore1 In diesem Thema wird eine Fallstudie zum Portieren einer sehr einfachen Windows Phone Silverlight-App zu einer Windows 10-UWP-App erläutert. Mit Windows 10 können Sie ein einzelnes App-Paket erstellen, das Ihre Kunden auf einer vielzahl von Geräten installieren können, und das tun wir in dieser Fallstudie.
Fallstudie: Bookstore2 Diese Fallstudie , die auf den Informationen in Bookstore1 basiert, beginnt mit einer Windows Phone Silverlight-App, die gruppierte Daten in einem LongListSelector anzeigt. Im Ansichtsmodell stellt jede Instanz der Klasse Author die Gruppe der Bücher dar, die von diesem Autor geschrieben wurden, und im LongListSelector können wir entweder die Liste der Bücher nach Autor gruppiert anzeigen, oder wir können verkleinern, um eine Sprungliste von Autoren anzuzeigen.

Dokumentation

Magazinartikel

Darbietungen

  • Die Geschichte, Nokia-Musik von Windows Phone auf Windows 8 zu bringen