Portieren Windows Phone Silverlight zu UWP für E/A, Gerät und App-Modell

Im vorherigen Thema wurde XAML und UI portiert.

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.

Anwendungslebenszyklus (Prozesslebensdauer-Verwaltung)

Ihre Windows Phone Silverlight-App enthält Code zum Speichern und Wiederherstellen des Anwendungszustands und des Ansichtszustands, um das Grabsteinen und anschließende erneute Aktivieren zu unterstützen. Der App-Lebenszyklus von Universelle Windows-Plattform-Apps (UWP) weist starke Parallelen mit der Windows Phone Silverlight-Apps auf, da beide mit demselben Ziel entwickelt wurden, die ressourcen zu maximieren, die der Benutzer für die app verfügbar hat, die der Benutzer jederzeit im Vordergrund haben soll. Sie werden feststellen, dass Sich Ihr Code leicht an das neue System anpasst.

Hinweis: Durch Drücken der Hardwaretaste "Zurück " wird automatisch eine Windows Phone Silverlight-App beendet. Durch Drücken der Hardwaretaste "Zurück " auf einem mobilen Gerät wird keine UWP-App automatisch beendet. Stattdessen wird sie angehalten und kann dann beendet werden. Diese Details sind jedoch für eine App transparent, die entsprechend auf Anwendungslebenszyklusereignisse reagiert.

Ein "Entprenkfenster" ist der Zeitraum zwischen dem Inaktivwerden der App und dem System, das das Anhalteereignis auslöst. Für eine UWP-App gibt es kein Entprenkfenster; das Anhalteereignis wird ausgelöst, sobald eine App inaktiv wird.

Weitere Informationen finden Sie im App-Lebenszyklus.

Kamera

Windows Phone Silverlight-Kameraaufnahmecode verwendet die Klassen "Microsoft.Devices.Camera", "Microsoft.Devices.PhotoCamera" oder "Microsoft.Phone.Tasks.CameraCaptureTask ". Um diesen Code zum Universelle Windows-Plattform (UWP) zu portieren, können Sie die MediaCapture-Klasse verwenden. Im Thema "CapturePhotoToStorageFileAsync" ist ein Codebeispiel vorhanden. Mit dieser Methode können Sie ein Foto in einer Speicherdatei aufnehmen, und sie erfordert, dass die Mikrofon- und Webcamgerätefunktionen im App-Paketmanifest festgelegt werden.

Eine weitere Option ist die CameraCaptureUI-Klasse, die auch die Mikrofon- und Webcamgerätefunktionen erfordert.

Objektiv-Apps werden für UWP-Apps nicht unterstützt.

Erkennen der Plattform, auf der Ihre App ausgeführt wird

Die Herangehensweise an die Zielausrichtung von Apps ändert sich mit Windows 10. Das neue konzeptionelle Modell besteht darin, dass eine App auf die Universelle Windows-Plattform (UWP) ausgerichtet ist und auf allen Windows-Geräten ausgeführt wird. Es kann sich dann dafür entscheiden, Features aufzuhellen, die für bestimmte Gerätefamilien exklusiv sind. Bei Bedarf hat die App auch die Möglichkeit, sich auf eine oder mehrere Gerätefamilien zu beschränken. Weitere Informationen dazu, was Gerätefamilien sind – und wie Sie entscheiden, welche Gerätefamilie als Ziel verwendet werden soll – finden Sie in der Anleitung zu UWP-Apps.

Beachten Sie , dass Sie kein Betriebssystem oder keine Gerätefamilie verwenden, um das Vorhandensein von Features zu erkennen. Die Identifizierung des aktuellen Betriebssystems oder der Gerätefamilie ist in der Regel nicht die beste Methode, um zu ermitteln, ob ein bestimmtes Betriebssystem oder ein Bestimmtes Gerätefamilienfeature vorhanden ist. Anstatt das Betriebssystem oder die Gerätefamilie (und Versionsnummer) zu erkennen, testen Sie das Vorhandensein des Features selbst (siehe Bedingte Kompilierung und adaptiven Code). Wenn Sie ein bestimmtes Betriebssystem oder eine bestimmte Gerätefamilie benötigen, müssen Sie es unbedingt als mindestens unterstützte Version verwenden, anstatt den Test für diese version zu entwerfen.

Um die Benutzeroberfläche Ihrer App auf verschiedene Geräte anzupassen, gibt es verschiedene Techniken, die empfohlen werden. Verwenden Sie weiterhin elemente mit automatischer Größe und dynamische Layoutpanels wie immer. Verwenden Sie in Ihrem XAML-Markup weiterhin Größen in effektiven Pixeln (vormals Ansichtspixel), sodass sich die Benutzeroberfläche an verschiedene Auflösungen und Skalierungsfaktoren anpasst (siehe Ansichts-/Effektive Pixel, Abstand zum Bildschirm und Skalierungsfaktoren).) Und verwenden Sie die adaptiven Trigger und Setter von Visual State Manager, um Ihre Benutzeroberfläche an die Fenstergröße anzupassen (siehe Anleitung zu UWP-Apps).)

Wenn Sie jedoch ein Szenario haben, in dem es unvermeidbar ist, die Gerätefamilie zu erkennen, können Sie dies tun. In diesem Beispiel verwenden wir die AnalyticsVersionInfo-Klasse , um nach Bedarf zu einer Seite zu navigieren, die auf die Mobilgerätefamilie zugeschnitten ist. Andernfalls stellen wir sicher, dass sie auf eine Standardseite zurückfallen.

   if (Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Mobile")
        rootFrame.Navigate(typeof(MainPageMobile), e.Arguments);
    else
        rootFrame.Navigate(typeof(MainPage), e.Arguments);

Ihre App kann auch die Gerätefamilie ermitteln, auf der sie ausgeführt wird, aus den tatsächlichen Ressourcenauswahlfaktoren. Das folgende Beispiel zeigt, wie sie dies imperative ausführen können, und im Thema "ResourceContext.QualifierValues " wird der typischere Anwendungsfall für die Klasse beim Laden von gerätefamilienspezifischen Ressourcen basierend auf dem Gerätefamilienfaktor beschrieben.

var qualifiers = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues;
string deviceFamilyName;
bool isDeviceFamilyNameKnown = qualifiers.TryGetValue("DeviceFamily", out deviceFamilyName);

Siehe auch die bedingte Kompilierung und adaptiven Code.

Gerätestatus

Eine Windows Phone Silverlight-App kann die Microsoft.Phone.Info.DeviceStatus-Klasse verwenden, um Informationen zum Gerät abzurufen, auf dem die App ausgeführt wird. Obwohl es keine direkte UWP-Entsprechung für den Microsoft.Phone.Info Namespace gibt, sind hier einige Eigenschaften und Ereignisse, die Sie in einer UWP-App anstelle von Aufrufen an Member der DeviceStatus-Klasse verwenden können.

Location

Wenn eine App, die die Standortfunktion im App-Paketmanifest deklariert, unter Windows 10 ausgeführt wird, fordert das System den Endbenutzer zur Zustimmung auf. Wenn Ihre App also eine eigene benutzerdefinierte Zustimmungsaufforderung anzeigt oder eine Ein-/Aus-Umschaltfläche bereitstellt, sollten Sie dies entfernen, damit der Endbenutzer nur einmal dazu aufgefordert wird.

Ausrichtung

Die UWP-App-Entsprechung der PhoneApplicationPage.SupportedOrientations- und Orientation-Eigenschaften ist das uap:InitialRotationPreference-Element im App-Paketmanifest. Wählen Sie die Registerkarte "Anwendung" aus, wenn sie noch nicht aktiviert ist, und aktivieren Sie unter "Unterstützte Drehungen" mindestens ein Kontrollkästchen, um Ihre Einstellungen aufzuzeichnen.

Sie werden jedoch ermutigt, die UI Ihrer UWP-App zu entwerfen, um unabhängig von der Geräteausrichtung und Bildschirmgröße großartig zu aussehen. Darüber hinaus gibt es in der Portierung für Formfaktoren und benutzererfahrungen weitere Informationen. Dies ist das Thema danach.

Das nächste Thema ist das Portieren von Geschäfts- und Datenebenen.