Portieren Windows-Runtime 8.x 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)

Bei einer universellen 8.1-App gibt es ein Zwei-Sekunden-Zeitfenster zwischen inaktiver App und dem System, das das Anhalteereignis auslöst. Wenn Sie dieses Entprunkfenster als zusätzliche Zeit zum Anhalten des Zustands verwenden, ist unsicher, und für eine Universelle Windows-Plattform (UWP)-App gibt es überhaupt kein Entprenkfenster. Das Anhalteereignis wird ausgelöst, sobald eine App inaktiv wird.

Weitere Informationen finden Sie im App-Lebenszyklus.

Hintergrundaudio

Für die MediaElement.AudioCategory-Eigenschaft sind ForegroundOnlyMedia und BackgroundCapableMedia für Windows 10-Apps veraltet. Verwenden Sie stattdessen das Windows Phone Store-App-Modell. Weitere Informationen finden Sie unter "Hintergrundaudio".

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.

Wenn Sie Code in Ihrer universellen 8.1-App haben, der erkennt, auf welchem Betriebssystem es ausgeführt wird, müssen Sie dies je nach Grund für die Logik möglicherweise ändern. Wenn die App den Wert durchgibt und nicht darauf wirkt, sollten Sie die Betriebssysteminformationen weiterhin sammeln.

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 ihre Benutzeroberfläche an unterschiedliche Auflösungen und Skalierungsfaktoren anpasst (siehe 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.

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. Dies gilt unabhängig davon, ob es sich bei der App um eine Windows Phone Store-App oder eine Windows 10-App handelt. 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.