Portieren Windows Phone Silverlight-XAML und -UI zu UWP

Das vorherige Thema war Problembehandlung.

Die Vorgehensweise beim Definieren der Benutzeroberfläche in Form von deklarativem XAML-Markup ist von Windows Phone Silverlight in Universelle Windows-Plattform-Apps (UWP) sehr gut übersetzt. 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. Ein Großteil des imperativen Codes in Ihrer Präsentationsebene – Ansichtsmodelle und Code, der UI-Elemente bearbeitet – ist auch einfach zu portieren.

Ein erster Blick auf das XAML-Markup

Im vorherigen Thema wurde gezeigt, wie Sie Ihre XAML- und CodeBehind-Dateien in Ihr neues Windows 10 Visual Studio-Projekt kopieren. Eines der ersten Probleme, die Sie möglicherweise im XAML-Designer von Visual Studio hervorgehoben haben, ist, dass das PhoneApplicationPage Element im Stamm der XAML-Datei für ein Universelle Windows-Plattform (UWP)-Projekt nicht gültig ist. Im vorherigen Thema haben Sie eine Kopie der XAML-Dateien gespeichert, die Visual Studio beim Erstellen des Windows 10-Projekts generiert hat. Wenn Sie diese Version von "MainPage.xaml" öffnen, sehen Sie, dass es sich im Stammverzeichnis um den Typ "Page" handelt, der sich im Namespace "Windows.UI.Xaml.Controls" befindet. Sie können also alle <phone:PhoneApplicationPage> Elemente <Page> ändern (eigenschaftselementsyntax nicht vergessen), und Sie können die xmlns:phone Deklaration löschen.

Für einen allgemeineren Ansatz zum Auffinden des UWP-Typs, der einem Windows Phone Silverlight-Typ entspricht, können Sie auf Namespace- und Klassenzuordnungen verweisen.

XAML-Namespacepräfixdeklarationen

Wenn Sie Instanzen von benutzerdefinierten Typen in Ihren Ansichten verwenden , z. B. eine Ansichtsmodellinstanz oder einen Wertkonverter, verfügen Sie im XAML-Markup über XAML-Namespacepräfixdeklarationen. Die Syntax dieser Unterschiede unterscheidet sich zwischen Windows Phone Silverlight und der UWP. Im Folgenden finden Sie einige Beispiele:

    xmlns:ContosoTradingCore="clr-namespace:ContosoTradingCore;assembly=ContosoTradingCore"
    xmlns:ContosoTradingLocal="clr-namespace:ContosoTradingLocal"

Ändern Sie "clr-namespace" in "using", und löschen Sie alle Assemblytoken und Semikolons (die Assembly wird abgeleitet). Das Ergebnis sieht wie folgt aus:

    xmlns:ContosoTradingCore="using:ContosoTradingCore"
    xmlns:ContosoTradingLocal="using:ContosoTradingLocal"

Möglicherweise verfügen Sie über eine Ressource, deren Typ vom System definiert ist:

    xmlns:System="clr-namespace:System;assembly=mscorlib"
    /* ... */
    <System:Double x:Key="FontSizeLarge">40</System:Double>

Geben Sie in der UWP die Präfixdeklaration "System" aus, und verwenden Sie stattdessen das Präfix "x":

    <x:Double x:Key="FontSizeLarge">40</x:Double>

Imperativer Code

Ihre Ansichtsmodelle sind eine Stelle, an der imperativer Code auf UI-Typen verweist. Ein weiterer Ort ist jede CodeBehind-Datei, die UI-Elemente direkt bearbeiten. Sie können beispielsweise feststellen, dass eine Codezeile wie diese noch nicht kompiliert wird:

    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

BitmapImage befindet sich im System.Windows.Media.Imaging-Namespace in Windows Phone Silverlight, und eine using-Direktive in derselben Datei ermöglicht die Verwendung von BitmapImage ohne Namespacequalifizierung wie im obigen Codeausschnitt. In einem solchen Fall können Sie in Visual Studio mit der rechten Maustaste auf den Typnamen (BitmapImage) klicken und den Befehl "Auflösen" im Kontextmenü verwenden, um der Datei eine neue Namespacedirektive hinzuzufügen. In diesem Fall wird der Windows.UI.Xaml.Media.Imaging-Namespace hinzugefügt, in dem sich der Typ in der UWP befindet. Sie können die Direktive "System.Windows.Media.Imaging " entfernen, und das ist alles, was zum Portieren von Code benötigt wird, wie im obigen Codeausschnitt. Wenn Sie fertig sind, haben Sie alle Windows Phone Silverlight-Namespaces entfernt.

In einfachen Fällen wie diesem können Sie, in denen Sie die Typen in einem alten Namespace den gleichen Typen in einem neuen Namespace zuordnen, den Befehl "Suchen und Ersetzen" von Visual Studio verwenden, um Massenänderungen am Quellcode vorzunehmen. Der Befehl "Auflösen" ist eine hervorragende Möglichkeit, den neuen Namespace eines Typs zu ermitteln. Als weiteres Beispiel können Sie alle "System.Windows" durch "Windows.UI.Xaml" ersetzen. Dadurch werden im Wesentlichen alle verwendeten Direktiven und alle vollqualifizierten Typnamen portieren, die auf diesen Namespace verweisen.

Nachdem alle alten using-Direktiven entfernt und die neuen hinzugefügt wurden, können Sie den Befehl "Organisieren mithilfe von Verwendungen" von Visual Studio verwenden, um Ihre Direktiven zu sortieren und nicht verwendete zu entfernen.

Manchmal ist das Beheben von imperativem Code so klein wie das Ändern des Typs eines Parameters. In anderen Zeiten müssen Sie Windows-Runtime APIs anstelle von .NET-APIs für Windows-Runtime 8.x-Apps verwenden. Um zu ermitteln, welche APIs unterstützt werden, verwenden Sie den Rest dieses Portierungshandbuchs in Kombination mit .NET für Windows-Runtime 8.x-Apps und die Windows-Runtime Referenz.

Und wenn Sie nur zu der Phase gelangen möchten, in der Ihr Projekt erstellt wird, können Sie jeden nicht wesentlichen Code kommentieren oder ausstauen. Durchlaufen Sie dann jeweils ein Problem, und lesen Sie die folgenden Themen in diesem Abschnitt (und das vorherige Thema: Problembehandlung), bis alle Build- und Laufzeitprobleme ausge ironet sind und Ihr Port abgeschlossen ist.

Adaptive/reaktionsfähige UI

Da Ihre Windows 10-App auf einer potenziell breiten Palette von Geräten ausgeführt werden kann – jeweils mit eigener Bildschirmgröße und -auflösung – sollten Sie über die minimalen Schritte zum Portieren Ihrer App hinausgehen und Ihre Benutzeroberfläche so anpassen, dass sie auf diesen Geräten optimal aussieht. Sie können das adaptive Visual State-Manager-Feature verwenden, um die Fenstergröße dynamisch zu erkennen und das Layout als Reaktion zu ändern, und ein Beispiel dafür, wie dies im Abschnitt Adaptive UI im Thema "Bookstore2"-Fallstudie gezeigt wird.

Alarme und Erinnerungen

Code mit den Alarm - oder Reminder-Klassen sollte portiert werden, um die BackgroundTaskBuilder-Klasse zum Erstellen und Registrieren einer Hintergrundaufgabe zu verwenden und ein Popup zum entsprechenden Zeitpunkt anzuzeigen. Siehe Hintergrundverarbeitung und Popups.

Animation

Als bevorzugte Alternative zu Keyframeanimationen und von/zu Animationen ist die UWP-Animationsbibliothek für UWP-Apps verfügbar. Diese Animationen wurden so konzipiert und optimiert, dass sie reibungslos ausgeführt werden, um großartig zu aussehen und ihre App so zu gestalten, dass sie in Windows integriert ist, wie die integrierten Apps. Siehe Schnellstart: Animieren der Benutzeroberfläche mithilfe von Bibliotheksanimationen.

Wenn Sie Keyframeanimationen oder Animationen in Ihren UWP-Apps verwenden, sollten Sie den Unterschied zwischen unabhängigen und abhängigen Animationen verstehen, die die neue Plattform eingeführt hat. Siehe Optimieren von Animationen und Medien. Animationen, die im UI-Thread ausgeführt werden (z. B. Animationen, die Layouteigenschaften animieren), werden als abhängige Animationen bezeichnet, und wenn sie auf der neuen Plattform ausgeführt werden, haben sie keine Auswirkung, es sei denn, Sie tun eine von zwei Dingen. Sie können sie entweder erneut animieren, um verschiedene Eigenschaften wie RenderTransform zu animieren, wodurch sie unabhängig werden. Alternativ können Sie das Animationselement festlegen EnableDependentAnimation="True" , um die Absicht zu bestätigen, eine Animation auszuführen, die nicht garantiert wird, reibungslos ausgeführt werden kann. Wenn Sie Blend für Visual Studio verwenden, um neue Animationen zu erstellen, wird diese Eigenschaft bei Bedarf für Sie festgelegt.

Behandeln von Zurück-Schaltflächen

In einer Windows 10-App können Sie einen einzigen Ansatz verwenden, um die Zurück-Schaltfläche zu behandeln, und sie funktioniert auf allen Geräten. Auf mobilen Geräten wird die Schaltfläche für Sie als kapazitive Schaltfläche auf dem Gerät oder als Schaltfläche in der Shell bereitgestellt. Auf einem Desktopgerät fügen Sie dem Chrome Ihrer App eine Schaltfläche hinzu, wenn die Rückwärtsnavigation innerhalb der App möglich ist, und dies wird in der Titelleiste für Fenster-Apps oder in der Taskleiste für den Tablet-Modus angezeigt (nur Windows 10). Das Ereignis "Zurück-Schaltfläche" ist ein universelles Konzept für alle Gerätefamilien, und Schaltflächen, die in Hardware oder software implementiert sind, lösen dasselbe BackRequested-Ereignis aus .

Das folgende Beispiel funktioniert für alle Gerätefamilien und eignet sich gut für Fälle, in denen die gleiche Verarbeitung für alle Seiten gilt und wo Sie die Navigation nicht bestätigen müssen (z. B. um vor nicht gespeicherten Änderungen zu warnen).

   // app.xaml.cs

    protected override void OnLaunched(LaunchActivatedEventArgs e)
    {
        [...]

        Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested += App_BackRequested;
        rootFrame.Navigated += RootFrame_Navigated;
    }

    private void RootFrame_Navigated(object sender, NavigationEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        // Note: On device families that have no title bar, setting AppViewBackButtonVisibility can safely execute 
        // but it will have no effect. Such device families provide a back button UI for you.
        if (rootFrame.CanGoBack)
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Visible;
        }
        else
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Collapsed;
        }
    }

    private void App_BackRequested(object sender, Windows.UI.Core.BackRequestedEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        if (rootFrame.CanGoBack)
        {
            rootFrame.GoBack();
        }
    }

Es gibt auch einen einzigen Ansatz für alle Gerätefamilien, um die App programmgesteuert zu beenden.

   Windows.UI.Xaml.Application.Current.Exit();

Binden und kompilierte Bindungen mit {x:Bind}

Das Thema bindung umfasst:

• Binden eines UI-Elements an "Daten" (d. a. an die Eigenschaften und Befehle eines Ansichtsmodells)
• Binden eines UI-Elements an ein anderes UI-Element
• Schreiben eines Ansichtsmodells, das feststellbar ist (d. a. er löst Benachrichtigungen aus, wenn sich ein Eigenschaftswert ändert und sich die Verfügbarkeit eines Befehls ändert)

All diese Aspekte werden weitgehend noch unterstützt, aber es gibt Namespaceunterschiede. System.Windows.Data.Binding ordnet beispielsweise Windows.UI.Xaml.Data.Binding, System.ComponentModel.INotifyPropertyChanged windows.UI.Xaml.Data.INotifyPropertyChanged und System.Collections.Specialized.INotifyPropertyChanged zu Windows.UI.Xaml.Interop.INotifyCollectionChanged zu.

Windows Phone Silverlight-App-Leisten und App-Leistenschaltflächen können nicht wie in einer UWP-App gebunden werden. Möglicherweise verfügen Sie über imperativen Code, der Ihre App-Leiste und ihre Schaltflächen erstellt, sie an Eigenschaften und lokalisierte Zeichenfolgen bindet und deren Ereignisse behandelt. Wenn ja, haben Sie jetzt die Möglichkeit, diesen imperativen Code zu portieren, indem Sie ihn durch deklaratives Markup ersetzen, das an Eigenschaften und Befehle gebunden ist, und durch statische Ressourcenverweise, wodurch Ihre App inkrementell sicherer und wartungsfähiger wird. Sie können Visual Studio oder Blend für Visual Studio verwenden, um UWP-App-Leistenschaltflächen wie jedes andere XAML-Element zu binden und zu formatieren. Beachten Sie, dass in einer UWP-App die typnamen, die Sie verwenden, CommandBar und AppBarButton sind.

Die bindungsbezogenen Features von UWP-Apps weisen derzeit die folgenden Einschränkungen auf:

• Es gibt keine integrierte Unterstützung für die Dateneingabeüberprüfung und die IDataErrorInfo- und INotifyDataErrorInfo-Schnittstellen.
• Die Binding-Klasse enthält nicht die erweiterten Formatierungseigenschaften, die in Windows Phone Silverlight verfügbar sind. Sie können jedoch weiterhin IValueConverter implementieren, um benutzerdefinierte Formatierungen bereitzustellen.
• Die IValueConverter-Methoden verwenden Sprachzeichenfolgen als Parameter anstelle von CultureInfo-Objekten.
• Die CollectionViewSource-Klasse bietet keine integrierte Unterstützung für Sortierung und Filterung, und die Gruppierung funktioniert anders. Weitere Informationen finden Sie unter "Datenbindung" im Detail und im Datenbindungsbeispiel.

Obwohl dieselben Bindungsfeatures weiterhin weitgehend unterstützt werden, bietet Windows 10 die Option eines neuen und leistungsfähigeren Bindungsmechanismus, der als kompilierte Bindungen bezeichnet wird, die die {x:Bind}-Markuperweiterung verwenden. Siehe Datenbindung: Steigern Sie die Leistung Ihrer Apps durch neue Verbesserungen an der XAML-Datenbindung und das x:Bind-Beispiel.

Binden eines Bilds an ein Ansichtsmodell

Sie können die Image.Source-Eigenschaft an eine beliebige Eigenschaft eines Ansichtsmodells binden, das vom Typ ImageSource ist. Hier ist eine typische Implementierung einer solchen Eigenschaft in einer Windows Phone Silverlight-App:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

In einer UWP-App verwenden Sie das URI-Schema "ms-appx ". Damit Sie den Restlichen Code unverändert halten können, können Sie eine andere Überladung des System.Uri-Konstruktors verwenden, um das URI-Schema "ms-appx" in einen Basis-URI zu setzen und den Rest des Pfads an diesen anzufügen. Dies sieht folgendermaßen aus:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(new Uri("ms-appx://"), this.CoverImagePath));

Auf diese Weise können der Rest des Ansichtsmodells, die Pfadwerte in der Bildpfadeigenschaft und die Bindungen im XAML-Markup alle identisch bleiben.

Steuerelemente und Steuerelementstile/-vorlagen

Windows Phone Silverlight-Apps verwenden Steuerelemente, die im Namespace "Microsoft.Phone.Controls " und im Namespace "System.Windows.Controls " definiert sind. XAML-UWP-Apps verwenden Steuerelemente, die im Windows.UI.Xaml.Controls-Namespace definiert sind. Die Architektur und der Entwurf von XAML-Steuerelementen in der UWP sind nahezu identisch mit Windows Phone Silverlight-Steuerelementen. Es wurden jedoch einige Änderungen vorgenommen, um den Satz verfügbarer Steuerelemente zu verbessern und sie mit Windows-Apps zu vereinheitlichen. Hier sind spezifische Beispiele.

Steuerelementname	Change
ApplicationBar	Die Page.TopAppBar-Eigenschaft .
ApplicationBarIconButton	Die UWP-Entsprechung ist die Glypheneigenschaft . PrimaryCommands ist die Inhaltseigenschaft von CommandBar. Der XAML-Parser interpretiert die innere XML eines Elements als Wert seiner Inhaltseigenschaft.
ApplicationBarMenuItem	Die UWP-Entsprechung ist das AppBarButton.Label-Set auf den Menüelementtext.
ContextMenu (im Windows Phone Toolkit)	Verwenden Sie für ein einzelnes Auswahl-Flyout Flyout.
ControlTiltEffect.TiltEffect-Klasse	Animationen aus der UWP-Animationsbibliothek sind in die Standardformatvorlagen der allgemeinen Steuerelemente integriert. Siehe die Animation von Zeigeraktionen.
LongListSelector mit gruppierten Daten	Die Windows Phone Silverlight LongListSelector funktioniert auf zwei Arten, die in Konzerten verwendet werden können. Zunächst können Daten angezeigt werden, die nach einem Schlüssel gruppiert sind, z. B. eine Liste mit Namen, die nach Anfangsbuchstaben gruppiert sind. Zweitens ist es in der Lage, zwischen zwei semantischen Ansichten zu zoomen: der gruppierten Liste der Elemente (z. B. Namen) und einer Liste mit nur den Gruppenschlüsseln selbst (z. B. Anfangsbuchstaben). Mit der UWP können Sie gruppierte Daten mit den Richtlinien für Listen- und Rasteransichtssteuerelemente anzeigen.
LongListSelector mit flachen Daten	Aus Leistungsgründen empfehlen wir bei sehr langen Listen LongListSelector anstelle eines Windows Phone Silverlight-Listenfelds auch für flache, nicht gruppierte Daten. In einer UWP-App werden GridView für lange Listen von Elementen bevorzugt, unabhängig davon, ob die Daten gruppieren können.
Panorama	Das Windows Phone Silverlight Panorama-Steuerelements ist den Richtlinien für Hubsteuerelemente in Windows-Runtime 8.x-Apps und Richtlinien für das Hubsteuerelement zugeordnet. Beachten Sie, dass ein Panorama-Steuerelement vom letzten Abschnitt zum ersten umgebrochen wird und das Hintergrundbild in Parallax relativ zu den Abschnitten verschoben wird. Hubabschnitte werden nicht umbrochen, und Parallax wird nicht verwendet.
Pivotieren	Die UWP-Entsprechung des Windows Phone Silverlight-Pivot-Steuerelements ist "Windows.UI.Xaml.Controls.Pivot". Sie ist für alle Gerätefamilien verfügbar.

Hinweis : Der visuelle Zustand "PointerOver" ist in benutzerdefinierten Stilen/Vorlagen in Windows 10-Apps relevant, aber nicht in Windows Phone Silverlight-Apps. Es gibt andere Gründe, warum Ihre vorhandenen benutzerdefinierten Stile/Vorlagen möglicherweise nicht für Windows 10-Apps geeignet sind, einschließlich Systemressourcenschlüsseln, die Sie verwenden, Änderungen an den verwendeten visuellen Zuständen und Leistungsverbesserungen an den Standardstilen/Vorlagen von Windows 10. Es wird empfohlen, eine neue Kopie der Standardvorlage eines Steuerelements für Windows 10 zu bearbeiten und dann ihre Format- und Vorlagenanpassung erneut darauf anzuwenden.

Weitere Informationen zu UWP-Steuerelementen finden Sie unter Steuerelemente nach Funktion, Steuerelementliste und Richtlinien für Steuerelemente.

Entwurfssprache in Windows 10

Es gibt einige Unterschiede bei der Entwurfssprache zwischen Windows Phone Silverlight-Apps und Windows 10-Apps. Alle Details finden Sie unter "Entwurf". Trotz der Änderungen der Designsprache bleiben unsere Designprinzipien konsistent: Achten Sie auf Details, bemühen Sie sich aber immer um Einfachheit, indem Sie sich auf Inhalte konzentrieren, nicht Chrom, stark reduzieren visuelle Elemente und bleiben für die digitale Domäne authentisch; verwenden Sie visuelle Hierarchie insbesondere bei Typografie; Design auf einem Raster; und erwecken Sie Ihre Erfahrungen mit flüssigen Animationen zum Leben.

Lokalisierung und Globalisierung

Für lokalisierte Zeichenfolgen können Sie die RESX-Datei aus Ihrem Windows Phone Silverlight-Projekt in Ihrem UWP-App-Projekt erneut verwenden. Kopieren Sie die Datei, fügen Sie sie dem Projekt hinzu, und benennen Sie sie in "Resources.resw" um, damit der Nachschlagemechanismus sie standardmäßig findet. Legen Sie die Buildaktion auf PRIResource fest, und kopieren Sie das Ausgabeverzeichnis auf "Nicht kopieren".Set Build Action to PRIResource and Copy to Output Directory to Do not copy. Anschließend können Sie die Zeichenfolgen im Markup verwenden, indem Sie das x:Uid-Attribut für Ihre XAML-Elemente angeben. Siehe Schnellstart: Verwenden von Zeichenfolgenressourcen.

Windows Phone Silverlight-Apps verwenden die CultureInfo-Klasse , um eine App zu globalisieren. UWP-Apps verwenden MRT (Modern Resource Technology), wodurch das dynamische Laden von App-Ressourcen (Lokalisierung, Skalierung und Design) sowohl zur Laufzeit als auch in der Visual Studio-Entwurfsoberfläche ermöglicht wird. Weitere Informationen finden Sie unter Richtlinien für Dateien, Daten und Globalisierung.

Im Thema "ResourceContext.QualifierValues " wird beschrieben, wie Gerätefamilienspezifische Ressourcen basierend auf dem Auswahlfaktor der Gerätefamilienressource geladen werden.

Medien und Grafiken

Beachten Sie beim Lesen von UWP-Medien und -Grafiken, dass die Windows-Designprinzipien eine heftige Reduzierung aller überflüssigen Elemente fördern, einschließlich grafischer Komplexität und Unübersichtlichkeit. Das Windows-Design wird durch klare und klare visuelle Elemente, Typografie und Bewegung eingegeben. Wenn Ihre App dieselben Prinzipien befolgt, sieht sie eher wie die integrierten Apps aus.

Windows Phone Silverlight verfügt über einen RadialGradientBrush-Typ , der in der UWP nicht vorhanden ist, obwohl andere Pinseltypen vorhanden sind. In einigen Fällen können Sie einen ähnlichen Effekt mit einer Bitmap erzielen. Beachten Sie, dass Sie einen radialen Farbverlaufpinsel mit Direct2D in einer UWP in Microsoft DirectX und XAML erstellen können.

Windows Phone Silverlight verfügt über die System.Windows.UIElement.OpacityMask-Eigenschaft, diese Eigenschaft ist jedoch kein Element des UWP UIElement-Typs. In einigen Fällen können Sie einen ähnlichen Effekt mit einer Bitmap erzielen. Außerdem können Sie in einer UWP-App von Microsoft DirectX und XAML eine Deckkraftmaske mit Direct2D erstellen. Ein gängiger Anwendungsfall für OpacityMask ist jedoch die Verwendung einer einzelnen Bitmap, die sich sowohl an helle als auch dunkle Designs anpasst. Für Vektorgrafiken können Sie designfähige Systempinsel (z. B. die unten dargestellten Kreisdiagramme) verwenden. Um jedoch eine designfähige Bitmap (z. B. die unten dargestellten Häkchen) zu erstellen, ist ein anderer Ansatz erforderlich.

In einer Windows Phone Silverlight-App besteht die Technik darin, eine Alphamaske (in Form einer Bitmap) als OpacityMask für ein Rechteck zu verwenden, das mit dem Vordergrundpinsel gefüllt ist:

    <Rectangle Fill="{StaticResource PhoneForegroundBrush}" Width="26" Height="26">
        <Rectangle.OpacityMask>
            <ImageBrush ImageSource="/Assets/wpsl_check.png"/>
        </Rectangle.OpacityMask>
    </Rectangle>

Die einfachste Möglichkeit, dies zu einer UWP-App zu portieren, besteht darin, ein BitmapIcon wie folgt zu verwenden:

    <BitmapIcon UriSource="Assets/winrt_check.png" Width="21" Height="21"/>

Hier ist winrt_check.png eine Alphamaske in Form einer Bitmap, wie wpsl_check.png ist, und es könnte sehr gut dieselbe Datei sein. Sie können jedoch mehrere verschiedene Größen von winrt_check.png bereitstellen, die für verschiedene Skalierungsfaktoren verwendet werden sollen. Weitere Informationen hierzu und eine Erläuterung der Änderungen an den Werten "Breite" und "Höhe" finden Sie unter "Ansicht" oder "Effektive Pixel", "Abstand zum Bildschirm" und "Skalierungsfaktoren" in diesem Thema.

Eine allgemeinere Vorgehensweise, die geeignet ist, wenn es Unterschiede zwischen der hellen und dunklen Designform einer Bitmap gibt, besteht darin, zwei Bildressourcen zu verwenden– eine mit einem dunklen Vordergrund (für helles Design) und eine mit einem hellen Vordergrund (für dunkles Design). Weitere Informationen zum Benennen dieser Bitmapressourcen finden Sie unter Anpassen der Ressourcen für Sprache, Skalierung und andere Qualifizierer. Sobald eine Gruppe von Bilddateien richtig benannt wurde, können Sie auf sie im Abstract verweisen, indem Sie ihren Stammnamen wie folgt verwenden:

    <Image Source="Assets/winrt_check.png" Stretch="None"/>

In Windows Phone Silverlight kann es sich bei der UIElement.Clip-Eigenschaft um ein beliebiges Shape handeln, das Sie mit einer Geometrie ausdrücken können und in der Regel in XAML-Markup in der Minisprache StreamGeometry serialisiert wird. In der UWP ist der Typ der Clip-Eigenschaft "RectangleGeometry", sodass Sie nur einen rechteckigen Bereich ausschneiden können. Das Zulassen, dass ein Rechteck mithilfe von Minisprache definiert werden kann, wäre zu freizügig. Um einen Clippingbereich im Markup zu portieren, ersetzen Sie die Clip-Attributsyntax , und machen Sie ihn in eine Eigenschaftselementsyntax ähnlich der folgenden:

    <UIElement.Clip>
        <RectangleGeometry Rect="10 10 50 50"/>
    </UIElement.Clip>

Beachten Sie, dass Sie beliebige Geometrie als Maske in einer Ebene mit Direct2D in einer UWP-App von Microsoft DirectX und XAML verwenden können.

Navigation

Wenn Sie zu einer Seite in einer Windows Phone Silverlight-App navigieren, verwenden Sie ein URI-Adressierungsschema (Uniform Resource Identifier):

    NavigationService.Navigate(new Uri("/AnotherPage.xaml", UriKind.Relative)/*, navigationState*/);

In einer UWP-App rufen Sie die Frame.Navigate-Methode auf und geben den Typ der Zielseite an (wie durch das x:Class-Attribut der XAML-Markupdefinition der Seite definiert):

    // In a page:
    this.Frame.Navigate(typeof(AnotherPage)/*, parameter*/);

    // In a view model, perhaps inside an ICommand implementation:
    var rootFrame = Windows.UI.Xaml.Window.Current.Content as Windows.UI.Xaml.Controls.Frame;
    rootFrame.Navigate(typeof(AnotherPage)/*, parameter*/);

Sie definieren die Startseite für eine Windows Phone Silverlight-App in WMAppManifest.xml:

    <DefaultTask Name="_default" NavigationPage="MainPage.xaml" />

In einer UWP-App verwenden Sie imperativen Code, um die Startseite zu definieren. Hier ist ein Code aus App.xaml.cs, der veranschaulicht, wie:

    if (!rootFrame.Navigate(typeof(MainPage), e.Arguments))

URI-Zuordnung und Fragmentnavigation sind URI-Navigationstechniken und gelten daher nicht für die UWP-Navigation, die nicht auf URIs basiert. Die URI-Zuordnung ist als Reaktion auf die schwach typografische Art der Identifizierung einer Zielseite mit einer URI-Zeichenfolge vorhanden, was zu Fragilitäts- und Wartungsbarkeitsproblemen führt, wenn die Seite in einen anderen Ordner und damit auf einen anderen relativen Pfad verschoben wird. UWP-Apps verwenden typbasierte Navigation, die stark typisch und compilergecheckt ist, und weist nicht das Problem auf, das die URI-Zuordnung löst. Der Anwendungsfall für die Fragmentnavigation besteht darin, einen Kontext an die Zielseite zu übergeben, sodass die Seite dazu führen kann, dass ein bestimmtes Fragment des Inhalts in die Ansicht verschoben oder anderweitig angezeigt wird. Dasselbe Ziel kann durch Übergeben eines Navigationsparameters erreicht werden, wenn Sie die Navigate-Methode aufrufen.

Weitere Informationen finden Sie unter "Navigation".

Ressourcenschlüsselreferenz

Die Entwurfssprache wurde für Windows 10 weiterentwickelt und folglich wurden bestimmte Systemstile geändert, und viele Systemressourcenschlüssel wurden entfernt oder umbenannt. Der XAML-Markup-Editor in Visual Studio hebt Verweise auf Ressourcenschlüssel hervor, die nicht aufgelöst werden können. Der XAML-Markup-Editor unterstreicht z. B. einen Verweis auf den Stilschlüssel PhoneTextNormalStyle mit einem roten Wellenzeichen. Wenn dies nicht korrigiert wird, wird die App sofort beendet, wenn Sie versuchen, sie im Emulator oder Gerät bereitzustellen. Daher ist es wichtig, an der Korrektheit von XAML-Markups teilzunehmen. Und Sie werden feststellen, dass Visual Studio ein hervorragendes Tool zum Abfangen solcher Probleme ist.

Siehe auch "Text" weiter unten.

Statusleiste (Taskleiste)

Die Taskleiste (im XAML-Markup mit shell:SystemTray.IsVisible) wird jetzt als Statusleiste bezeichnet und standardmäßig angezeigt. Sie können die Sichtbarkeit im imperativen Code steuern, indem Sie die Methoden "Windows.UI.ViewManagement.StatusBar.ShowAsync" und "HideAsync" aufrufen.

Text

Text (oder Typografie) ist ein wichtiger Aspekt einer UWP-App, und beim Portieren sollten Sie die visuellen Designs Ihrer Ansichten überprüfen, damit sie mit der neuen Entwurfssprache in Einklang stehen. Verwenden Sie diese Abbildungen, um die verfügbaren UWP TextBlock-Systemstile zu finden. Suchen Sie die Formatvorlagen, die den verwendeten Windows Phone Silverlight-Formatvorlagen entsprechen. Alternativ können Sie eigene universelle Formatvorlagen erstellen und die Eigenschaften aus den Windows Phone Silverlight-Systemstilen in diese Formatvorlagen kopieren.

SystemtextBlock-Formatvorlagen für Windows 10-Apps

In einer Windows Phone Silverlight-App ist die Standardschriftartfamilie Segoe WP. In einer Windows 10-App ist die Standardschriftartfamilie Segoe UI. Daher sieht die Schriftartmetrik in Ihrer App möglicherweise anders aus. Wenn Sie das Aussehen Ihres Windows Phone Silverlight-Texts reproduzieren möchten, können Sie ihre eigenen Metriken mithilfe von Eigenschaften wie LineHeight und LineStackingStrategy festlegen. Weitere Informationen finden Sie unter Richtlinien für Schriftarten und Entwerfen von UWP-Apps.

Designänderungen

Bei einer Windows Phone Silverlight-App ist das Standarddesign standardmäßig dunkel. Für Windows 10-Geräte wurde das Standarddesign geändert, Sie können jedoch das Design steuern, das verwendet wird, indem Sie ein angefordertes Design in "App.xaml" deklarieren. Wenn Sie beispielsweise ein dunkles Design auf allen Geräten verwenden möchten, fügen Sie RequestedTheme="Dark" das Stammelement "Application" hinzu.

Kacheln

Kacheln für UWP-Apps weisen Verhaltensweisen auf, die mit Live-Kacheln für Windows Phone Silverlight-Apps vergleichbar sind, obwohl es einige Unterschiede gibt. Beispiel: Code, der die Microsoft.Phone.Shell.ShellTile.Create-Methode aufruft, um sekundäre Kacheln zu erstellen, sollte portiert werden, um SecondaryTile.RequestCreateAsync aufzurufen. Hier ist ein Vor- und Nachher-Beispiel, zuerst die Windows Phone Silverlight-Version:

    var tileData = new IconicTileData()
    {
        Title = this.selectedBookSku.Title,
        WideContent1 = this.selectedBookSku.Title,
        WideContent2 = this.selectedBookSku.Author,
        SmallIconImage = this.SmallIconImageAsUri,
        IconImage = this.IconImageAsUri
    };

    ShellTile.Create(this.selectedBookSku.NavigationUri, tileData, true);

Und die UWP-Entsprechung:

    var tile = new SecondaryTile(
        this.selectedBookSku.Title.Replace(" ", string.Empty),
        this.selectedBookSku.Title,
        this.selectedBookSku.ArgumentString,
        this.IconImageAsUri,
        TileSize.Square150x150);

    await tile.RequestCreateAsync();

Code, der eine Kachel mit der Microsoft.Phone.Shell.ShellTile.Update-Methode oder der Microsoft.Phone.Shell.ShellTileSchedule-Klasse aktualisiert, sollte portiert werden, um die Klassen "TileUpdater", "TileUpdater", "TileNotification" und/oder "ScheduledTileNotification" zu verwenden.

Weitere Informationen zu Kacheln, Popups, Signalen, Bannern und Benachrichtigungen finden Sie unter Erstellen von Kacheln und Arbeiten mit Kacheln, Signalen und Popupbenachrichtigungen. Einzelheiten zu den Größen visueller Ressourcen, die für UWP-Kacheln verwendet werden, finden Sie unter visuelle Ressourcen für Kacheln und Popups.

Toaste

Code, der ein Popup mit der Microsoft.Phone.Shell.ShellToast-Klasse anzeigt, sollte portiert werden, um die Klassen ToastNotificationManager, ToastNotifier, ToastNotification und/oder ScheduledToastNotification zu verwenden. Beachten Sie, dass auf mobilen Geräten der verbraucherorientierte Begriff für "Popup" "Banner" ist.

Siehe Arbeiten mit Kacheln, Signalen und Popupbenachrichtigungen.

Anzeigen oder effektive Pixel, Abstand zum Bildschirm und Skalierungsfaktoren

Windows Phone Silverlight-Apps und Windows 10-Apps unterscheiden sich in der Art und Weise, wie sie die Größe und das Layout von UI-Elementen von der tatsächlichen physischen Größe und Auflösung von Geräten abstrahieren. Dazu verwendet eine Windows Phone Silverlight-App Anzeigepixel. Mit Windows 10 wurde das Konzept von Ansichtspixeln auf die effektiven Pixel optimiert. Hier ist eine Erläuterung dieses Begriffs, was es bedeutet, und den zusätzlichen Wert, den es bietet.

Der Begriff "Auflösung" bezieht sich auf ein Maß der Pixeldichte und nicht, wie allgemein angenommen, Pixelanzahl. "Effektive Auflösung" ist die Art und Weise, wie die physischen Pixel, die ein Bild oder eine Glyphe bilden, in das Auge aufgelöst werden, wenn unterschiede in der Anzeigeabstand und der physischen Pixelgröße des Geräts (Pixeldichte ist die Kehrwertgröße der physischen Pixelgröße). Effektive Auflösung ist eine gute Metrik, um eine Umgebung zu erstellen, da sie benutzerorientiert ist. Indem Sie alle Faktoren verstehen und die Größe von UI-Elementen steuern, können Sie die Benutzerfreundlichkeit gut gestalten.

Für eine Windows Phone Silverlight-App sind alle Smartphonebildschirme genau 480 Ansichtspixel breit, unabhängig davon, wie viele physische Pixel der Bildschirm hat, oder welche Pixeldichte oder physische Größe der Bildschirm hat. Dies bedeutet, dass ein Image-Element genau Width="48" ein Zehntel der Breite des Bildschirms eines beliebigen Smartphones ist, das die Windows Phone Silverlight-App ausführen kann.

Bei einer Windows 10-App ist es nicht der Fall, dass alle Geräte eine feste Anzahl von effektiven Pixeln breit sind. Das ist wahrscheinlich offensichtlich, da die breite Palette von Geräten, auf denen eine UWP-App ausgeführt werden kann, ausgeführt werden kann. Verschiedene Geräte sind eine andere Anzahl effektiver Pixel breit, von 320 Epx für die kleinsten Geräte bis hin zu 1024 Epx für einen bescheidenen Monitor und weit darüber hinaus bis hin zu viel höheren Breiten. Alles, was Sie tun müssen, besteht weiterhin darin, Elemente mit automatischer Größe und dynamische Layoutpanels wie immer zu verwenden. Es gibt auch einige Fälle, in denen Sie die Eigenschaften Ihrer UI-Elemente auf eine feste Größe im XAML-Markup festlegen. Je nachdem, auf welchem Gerät sie ausgeführt wird, und den vom Benutzer vorgenommenen Anzeigeeinstellungen wird automatisch ein Skalierungsfaktor auf Ihre App angewendet. Und dieser Skalierungsfaktor dient dazu, alle UI-Elemente mit einer festen Größe beizubehalten, die eine mehr oder weniger konstante Toucheingabe (und Leseziel) für den Benutzer über eine Vielzahl von Bildschirmgrößen hinweg darstellt. Und zusammen mit dem dynamischen Layout wird Ihre Benutzeroberfläche nicht nur auf verschiedenen Geräten optisch skaliert, sondern tun stattdessen, was erforderlich ist, um die entsprechende Menge an Inhalt in den verfügbaren Platz zu passen.

Da 480 früher die feste Breite in Ansichtspixeln für einen Smartphonebildschirm war und dieser Wert in der Regel in effektiven Pixeln kleiner ist, besteht eine Faustregel darin, jede Dimension in Ihrem Windows Phone Silverlight-App-Markup mit einem Faktor von 0,8 zu multiplizieren.

Damit Ihre App für alle Displays am besten geeignet ist, empfehlen wir, jede Bitmapressource in einer Reihe von Größen zu erstellen, die jeweils für einen bestimmten Skalierungsfaktor geeignet sind. Wenn Sie Ressourcen auf einer Skalierung von 100 %, einer Skalierung von 200 % und einer Skalierung von 400 % (in dieser Prioritätsreihenfolge) bereitstellen, erhalten Sie in den meisten Fällen hervorragende Ergebnisse bei allen Zwischenskalenfaktoren.

Hinweis: Wenn Sie aus irgendeinem Grund keine Ressourcen in mehr als einer Größe erstellen können, erstellen Sie dann Ressourcen mit einer Skalierung von 100 %. In Microsoft Visual Studio stellt die Standardprojektvorlage für UWP-Apps Brandingressourcen (Kachelbilder und Logos) in nur einer Größe bereit, sie sind jedoch nicht auf 100 %skaliert. Befolgen Sie beim Erstellen von Ressourcen für Ihre eigene App die Anleitungen in diesem Abschnitt, und stellen Sie 100 %, 200 % und 400 % größen bereit, und verwenden Sie Asset Packs.

Wenn Sie komplexe Grafiken haben, sollten Sie Ihre Ressourcen in noch mehr Größen bereitstellen. Wenn Sie mit Vektorgrafiken beginnen, ist es relativ einfach, qualitativ hochwertige Ressourcen zu einem beliebigen Skalierungsfaktor zu generieren.

Es wird nicht empfohlen, alle Skalierungsfaktoren zu unterstützen, aber die vollständige Liste der Skalierungsfaktoren für Windows 10-Apps beträgt 100 %, 125 %, 150 %, 200 %, 250 %, 300 % und 400 %. Wenn Sie sie bereitstellen, wählt der Store die ressourcenspezifischen Ressourcen für jedes Gerät aus, und nur diese Ressourcen werden heruntergeladen. Der Store wählt die Ressourcen aus, die heruntergeladen werden sollen, basierend auf dem DPI-Wert des Geräts.

Weitere Informationen finden Sie unter Responsive Design 101 für UWP-Apps.

Fenstergröße

In Ihrer UWP-App können Sie eine Mindestgröße (sowohl Breite als auch Höhe) mit imperativem Code angeben. Die Standardmäßige Mindestgröße beträgt 500 x 320epx, und das ist auch die kleinste Mindestgröße, die akzeptiert wird. Die größte akzeptierte Mindestgröße beträgt 500x500epx.

   Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().SetPreferredMinSize
        (new Size { Width = 500, Height = 500 });

Das nächste Thema ist das Portieren für E/A, Gerät und App-Modell.

Zugehörige Themen

• Namespace- und Klassenzuordnungen