Migrieren von Silverlight- oder WPF XAML-Code in eine Windows Store-App

Applies to Windows and Windows Phone

Wenn Sie mit anderen XAML-basierten Plattformen wie Windows Presentation Foundation (WPF), Microsoft Silverlight oder Silverlight für Windows Phone vertraut sind, können Sie auf Ihre Kenntnisse zurückgreifen, um Windows Store-Apps zu erstellen. In diesem Artikel werden grundlegende Unterschiede beschrieben, über die Sie sich bei der Migration des Codes und der XAML aus der ursprünglichen WPF oder Silverlight-App bewusst sein sollten.

Hinweis  Wenn Sie eine Windows Phone-App migrieren, die XAML verwendet, lesen Sie Ressourcen für Windows Phone-Entwickler.

Roadmap: Wie hängt dieses Thema mit anderen zusammen? Siehe: Roadmap für Windows-Runtime-Apps mit C# oder Visual Basic

Allgemeine Verfahren zum Portieren von XAML und Code

Das Migrieren von Code und XAML, der zuvor für ein anderes UI-Framework (z. B. WPF oder Silverlight) geschrieben wurde, ist umfangreicher als beispielsweise das Aktualisieren zwischen verschiedenen Versionen desselben Frameworks. Sie können jedoch Teile des Codes und XAML wiederverwenden, indem Sie die Bereiche mit Unterschieden in den APIs und Programmiermodellen wie in diesem Thema beschrieben identifizieren. Um die Teile wiederzuverwenden, integrieren Sie sie am besten in den Code und die XAML-Struktur, die Sie mit einer neuen Microsoft Visual Studio-Vorlage für eine Windows Store-App in C++, C# oder Visual Basic erhalten. Sie verfügen somit über eine entsprechende Navigationsstruktur für die XAML-Seiten, und die Windows-Runtime-Namespaces für Ihr CodeBehind sind bereits enthalten. Wenn Sie weitere XAML-Seiten oder weiteren Code benötigen, verwenden Sie die Optionen unter Neu hinzufügen, um mit einer Windows Store-App-Seite oder Codedatei zu beginnen. Kopieren Sie die ursprüngliche XAML bzw. den Code, und fügen Sie die XAML bzw. den Code als Segmente in die neue Seite/Datei ein. Führen Sie anschließend ggf. Konvertierungen auf Zeilenebene durch.

In den übrigen Abschnitten dieses Themas werden verschiedene Funktionsbereiche behandelt, die sowohl für ursprüngliche UI-Frameworks als auch für Windows Store-Apps gelten. Lesen Sie die einzelnen Abschnitte durch, um einen Überblick über relevante Unterschiede und über Ihre Möglichkeiten zum Migrieren von XAML und Code für einen Windows Store-App zu erhalten.

Neues Design und Verhalten

Windows Store-Apps haben ein einzigartiges Erscheinungsbild und Verhalten (Charakter), durch das sie sich von anderen Apps abheben, unter anderem von solchen, die mit anderen XAML-basierten Plattformen erstellt wurden. Nehmen Sie sich etwas Zeit, um sich mit den bewährten Methoden für die Erstellung einer großartigen Windows Store-App vertraut zu machen. Um die Designaspekte beim Erstellen einer Windows Store-App zu berücksichtigen, müssen grundlegende Bestandteile der UI häufig neu zusammengestellt werden. Insbesondere der Umgang mit Dialogfeldern, Menüs, Eingabebefehlen und Listen muss u. U. angepasst werden, um die Designrichtlinien zu erfüllen. Weitere Informationen finden Sie unter Erstellen großartiger Windows Store-Apps und Richtlinien für die UX von Windows Store-Apps.

Anwendungsobjekt und App-Modell

  • Das Anwendungsmodell für Aktivierung und App-Lebensdauer ist anders, da Apps angehalten und fortgesetzt werden können. Weitere Informationen finden Sie unter Starten, Fortsetzen und Multitasking.
  • Das Application-Tag in app.xaml kann nicht verwendet werden, um Ereignisse in der App-Lebensdauer anzufügen. Die Ereignisverknüpfung für Ereignisse wie Suspending muss als Bestandteil der Startlogik in der CodeBehind-Datei app.xaml festgelegt werden.
  • Verglichen mit der Microsoft Win32-Programmierung ist das Window-Objekt eine weniger direkte Entsprechung zum HWND einer ausgeführten Anwendung. Einige der erweiterten Windowing-Features werden von einem separaten Objekt dargestellt, das Sie mit dem Wert der Window.CoreWindow-Eigenschaft abrufen können.
  • Im Vergleich mit einer Silverlight-App hingegen wird nicht mehr der Browserhost als zwischengeschaltete Programmierungsgrenze verwendet. Vielmehr wird die Windows Store-App direkt in Windows-Runtime ausgeführt. Dies vereinfacht die Dinge, da Probleme im Zusammenhang mit dem Browserhosting, die bei Silverlight bestanden, entfallen – z. B. die Eingabebehandlung durch eine Programmzugriffsschicht hindurch, begrenzter Speicherzugriff und ein auf das Internet ausgerichtetes Sicherheits- und Zwischenspeicherungsmodell.
  • Bei Silverlight-Apps konnten entweder Teile der Anwendung als externe Teile in das Bereitstellungspaket aufgenommen oder Komponenten bei Bedarf heruntergeladen werden. Bei einer Windows Store-App gibt es diese Auswahlmöglichkeiten ebenfalls, jedoch werden andere APIs für den Zugriff auf die Paketteile verwendet. Wo bei Silverlight Application.GetResourceStream verwendet wird, kommt in einer Windows Store-App ein eher generalisiertes Modell zum Einsatz, bei dem das installierte Paket einfach ein Speicherordner ist. So können Sie beispielsweise zunächst den Package.InstalledLocation-Eigenschaftswert abrufen und dann verschiedene StorageFolder-APIs aufrufen (die meisten davon asynchron), um beliebige weitere Paketkomponenten abzurufen. Weitere Informationen finden Sie im Artikel zum Erstellen und Abrufen von Ressourcen in Windows Store-Apps.
  • Das App-Modell der Windows-Runtime verwendet ein Funktionskonzept. Sie müssen eine Funktion im Rahmen Ihres Entwicklungs- und Bereitstellungsprozesses deklarieren und ein Benutzer kann in der Windows Store-Benutzeroberfläche sehen, dass eine bestimmte Funktion von Ihrer App angefordert wurde. Für den Zugriff auf den Bibliotheksspeicher für einen Benutzer, zur Verwendung von Webcam-APIs usw. müssen Sie möglicherweise Funktionen anfordern. Für bestimmten Code, der zuvor in Silverlight und WPF funktioniert hat, müssen Sie möglicherweise auch dann eine Windows-Runtime-Funktion anfordern, wenn Sie ihn auf Syntaxebene korrekt konvertiert haben, um darauf zugreifen zu können. Weitere Informationen finden Sie unter Deklaration der App-Funktionen.
  • Das Starten einer App direkt über eine Kachel ist nicht die einzige Möglichkeit zur Aktivierung einer Windows Store-App. Beispielsweise kann Ihre App den Aufruf durch Dateizuordnungen, etwa ein Vertrag für "Wiedergeben auf", unterstützen. Dies sollten Sie einplanen, indem Sie den App-Status als App-Daten aufrechterhalten und sicherstellen, dass Ihre App auf alle Daten zugreifen kann, die sie zum Start in allen möglichen Aktivierungsszenarien benötigt. Weitere Informationen finden Sie unter So wird's gemacht: Aktivieren einer App und anderen Themen unter Starten, Fortsetzen und Multitasking.

.NET-Programmierung und -Typprojektion

Die Architektur von Windows-Runtime basiert auf dem Prinzip, dass Entwickler verschiedene Sprachen verwenden können, um auf dieselben zugrunde liegenden Funktionen und Konzepte von Windows-Runtime zuzugreifen. Ein Aspekt der Programmierung in verschiedenen Sprachen für Windows-Runtime, wobei einige der Merkmale und Muster der vom Entwickler gewählten Sprache erhalten bleiben, ist die Typprojektion. Entwickler, die Microsoft .NET-Sprachen verwenden, sind mit dem .NET-Typsystem und den von der .NET-Assembly mscorlib implementierten Primitiven, Typen und Konzepten vertraut.

Es gibt eine Reihe speziell für .NET projizierter Typen bei der Programmierung für die Windows-Runtime. Diese Typen sind entweder in der mscorlib-Assembly und im System-Namespace enthalten oder werden eigens einer der WindowsRuntime-Assemblys hinzugefügt, die als .NET-Verweisassemblys für die Windows-Runtime-Programmierung zur Verfügung stehen.

  • Allgemeine Auflistungsschnittstellen werden als die Auflistungsschnittstellen projiziert, die .NET-Programmierern vertraut sind. IVector<T> wird projiziert als IList<T>. IMap<K,V> wird projiziert als IDictionary<TKey,TValue>. Enumerable-Typen unterstützen foreach-Syntax und zugehörige Erweiterungsmethoden durch System.Linq. Für verwandte Ansichtsklassen und schreibgeschützte Varianten gibt es ähnliche Projektionen. Durch diese Projektionen kann jede Windows-Runtime-Klasse, die eine Auflistungsschnittstelle implementiert, die API der projizierten .NET-Auflistungsschnittstelle unterstützen.

  • Uri wird projiziert als System.Uri. (Es gibt jedoch einige wichtige Unterschiede, siehe Abschnitt "URIs".)

  • Allgemeine "Primitive" werden als der mscorlib-/System-Typ projiziert, der Entwicklern aus der .NET-Programmierung vertraut ist. So kann z. B. bei der Programmierung mit einer .NET-Sprache für beliebigen App-Code mit einem double-Wert die für System.Double bereitgestellte API verwendet werden.

  • .NET APIs, die mit dem Typsystem interagieren, können auf die .NET-System.Type verweisen und Sie können den typeof-Operator im Windows-Runtime-Code nutzen. (Hinweis: Wenn Sie Interoperationen durchführen oder C++ für einen Teil Ihres Codes verwenden, verfügt C++ zwar über einen typeid-Operator, dieser ist jedoch im Vergleich zu typeof eingeschränkt.)

  • IReference<T> wird als Nullable<T> für .NET projiziert und ermöglicht es, einen booleschen Nullable-Typ mit einer Programmiersprachensyntax wie bool? darzustellen.

  • EventHandler<T> wird als System.EventHandler<TEventArgs> für .NET projiziert.

  • HResult wird als System.Exception für .NET projiziert. Auch die Extraktion der Meldungsinformation aus einem Windows-Runtime-Fehler wird auf Pro-API-Basis unterstützt und bietet einem .NET-Entwickler eine entsprechend typisierte Ausnahme auf der Basis einer System.Exception. Sie können try-catch und ähnliche Verfahren für die Ausnahmebehandlung verwenden, und Sie können viele der .NET-Standardausnahmen behandeln, mit denen Sie bereits vertraut sind. Weitere Informationen hierzu finden Sie unter Ausnahmebehandlung für Windows-Runtime-Apps in C# oder Visual Basic.

  • Für ICommand-Muster wird die .NET-Definition (System.Windows.Input.ICommand) verwendet.
  • Die Schnittstellen, die Sie für in .NET geschriebene bindbare Geschäftsobjekte verwendet haben, werden übersetzt, wenn Sie das Objekt als Windows-Runtime-Datenquelle verwenden. Je nach Implementierung in einer Geschäftsobjektklasse, die ursprünglich für WPF oder Silverlight geschrieben wurde, kann eine Bindung z. B. auf PropertyChanged oder CollectionChanged reagieren.

  • Viele der Strukturen, die üblicherweise als Werttypen für die XAML-UI-Programmierung verwendet werden, werden als Strukturen projiziert, für die Hilfsmethoden verfügbar sind. Diese Strukturen haben denselben Namen und dieselbe Namespaceposition, verweisen aber auf eine WindowsRuntime-Assembly, sodass die Hilfsmethoden für .NET unterstützt werden. .NET-Programmierer können z. B. eine Hilfsprogramm-API von Matrix3D (z. B. HasInverse) oder die integrierten Operatoren verwenden. (C++/CX unterstützt auch einige Hilfsprogramme für die Strukturen, die ebenfalls als Projektion implementiert sind, diese Unterstützung ist jedoch begrenzt.)

  • Ein verwandtes Konzept ist, dass ein als .NET-Typ projizierter Typ .NET-Erweiterungsmethoden unterstützen kann. Dadurch können .NET-Erweiterungsmethoden genutzt werden, die speziell für die Programmierung von Windows Store-Apps konzipiert sind. Ein vorhandener .NET-Typ wie StreamReader kann z. B. Methoden unterstützen, die async-Muster wie die in Windows.Storage-APIs verwenden.

  • Der Basistyp für alle Runtime-Objekte ist System.Object. Er verfügt über die erwartete System.Object-API, z. B. ToString. Es bestehen jedoch geringfügige Unterschiede bei der Implementierung dieser Methoden zur Ausführung in der Windows-Runtime. Diese Unterschiede werden in der Regel in der .NET-Referenzdokumentation unter Hinweise für Windows-Runtime beschrieben.

Hinweis  Typprojektionen sollen Ihnen die XAML- und Codemigrationsszenarien, vor allem bei der Migration von CodeBehind für XAML-Seiten, Geschäftsobjekte oder eigenständige Logikklassen, erleichtern. In der Regel müssen Sie nicht untersuchen, ob es sich bei einem Typ aus Ihrem Originalcode tatsächlich um einen projizierten Typ in der Windows-Runtime handelt. Die Compiler und Projektvorlagen führen automatisch die richtigen Vorgänge aus.

Bei der Verwendung von projizierten Typen benötigen Sie unter Umständen dennoch Namespaceverweise für Fälle, in denen die Projektionen für die Laufzeitunterstützung vorliegen, aber nicht zu den .NET-Hauptframeworkbibliotheken gehören und nicht in vorhandenen .NET-Namespaces wie System.Collections.Generic definiert sind. Bei C#-Code beispielsweise, der die Point-Struktur nutzt, benötigen Sie dennoch eine using-Anweisung, die auf den Windows.Foundation-Namespace verweist, da so auch der projizierte Point definiert ist.

Weitere Informationen zu .NET und Windows Store-Apps mit Programmierung in C++, C# oder Visual Basic finden Sie unter Übersicht über .NET für Windows Store-Apps.

Allgemeines Programmiermodell

  • Wenn Sie nicht mit einer .NET-Sprache, sondern mit Visual C++-Komponentenerweiterung (C++/CX) programmieren, weisen Strukturen eine einfache Definition im C-Stil auf, die keine Nichtdatenmember unterstützt.
  • In das Programmiermodell ist Syntax für asynchrone Vorgänge integriert. Asynchrone Vorgänge sind bei diesem Programmiermodell weiter verbreitet als bei WPF oder Silverlight. Die Absicht hinter den asynchronen APIs besteht darin, Muster durchzusetzen, die das Blockieren eines UI-Thread in einem Ereignishandler oder Rückruf erschweren. Weitere Informationen finden Sie unter Schnellstart: Aufrufen asynchroner APIs in C# oder Visual Basic.
  • Aufgrund von asynchronen Mustern oder anderen Hintergrundaufgaben, die sich nicht im UI-Thread befinden, besteht vielleicht eine Notwendigkeit, Aufrufe von anderen Threads auszuführen, die letztendlich den UI-Thread asynchron aktualisieren. Die zum threadübergreifenden Arbeiten (gewöhnlich von einem Hintergrundthread oder einem UI-Thread aus) verwendete API entspricht der API in Silverlight, DependencyObject.Dispatcher.
  • Der Datei- und Speicherzugriff, der mit mscorlib- und system-Assembly-APIs hätte realisiert werden können, wird nun mit einer dedizierten System-API wie StorageFile realisiert.
  • Wenn Sie mit einer .NET-Sprache programmieren, können Sie auch vorhandene auf System.IO.Stream basierende Logik verwenden. Sie können auf Erweiterungsmethoden zugreifen, die einen Stream von ähnlichen Windows-Runtime-Typen zurückgeben, z. B. Aufrufen der AsStream-Erweiterungsmethode für eine IRandomAccessStream-Instanz. In einem Code-Editor wird die System.IO.Stream-API immer als Optionen in den Microsoft IntelliSense-Dropdownlisten angezeigt, wenn Stream-Instanzen aus zugehörigen Stream-/Puffertypen abgerufen werden.

Navigation

Beim Silverlight-Navigationsmodell dienten XAML-Seiten (lose oder im Paket) als Grundlage für die Auswahl des Inhalts, zu dem navigiert werden sollte. Windows Store-Apps verwenden Typen und insbesondere den als x:Class angegebenen Typ für eine XAML-Seite. Sinnvoll wäre es, mithilfe der Funktion Neu hinzufügen im Projektmappen-Explorer neue XAML-Seiten in der gewünschten Projektvorlage für die Windows Store-App zu erstellen. Importieren Sie die Elemente unterhalb der Stammebene der ursprünglichen Silverlight-Seite und bearbeiten Sie nacheinander weitere ggf. bestehende Konvertierungsprobleme. Bauen Sie dann die Navigationsstruktur mit einem Frame auf der Hauptseite auf. Alternativ dazu können Sie ein neues Projekt auch mithilfe der Vorlagen Raster-App oder Geteilte App erstellen. Darin sind Seiten enthalten, die bereits über ein Navigationsframework und außerdem über Vorlagen für den Ansichtszustand und Anhalten/Fortsetzen-Logik verfügen. Sie können auch die Vorlage und Navigationsstrategie für die Hub App verwenden. Weitere Informationen finden Sie unter Teil 3: Navigation, Layout und Ansichten oder Hinzufügen einer Seitensteuerung.

Die Windows-Runtime enthält die Klassen Page und Frame im standardmäßigen Steuerelementsatz. In Silverlight hingegen stammen sie aus den Bibliotheken des SDK und müssen verteilt werden. Wenn Sie eine XAML migrieren, die eine Page oder einen Frame enthält, können Sie das "sdk:"-Präfix der Elemente sowie die xmlns-Zuordnung des "sdk:"-Präfixes entfernen. Seiten können OnNavigatedTo und OnNavigatedFrom außer Kraft setzen, wenn von den Seiten während einer Navigationsaktion eine Bereinigung ausgeführt werden muss. Aber auch in der Frame-Klasse sind Ereignisse und Außerkraftsetzungen verfügbar, beispielsweise Navigated, daher sollten Sie überlegen, anstelle einzelner Seiten eine Navigationslogik in den Frame einzufügen. Der Frame in Silverlight enthielt einfache Navigationsschaltflächen in der Steuerelementvorlage, die Windows-Runtime-Navigationsfeatures sind jedoch in die Seitenvorlagen integriert und verwenden bestimmte Stile und Vorlagen für die Schaltflächen selbst. Weitere Informationen finden Sie unter Schnellstart: Navigation zwischen Seiten.

Kacheln und Benachrichtigungen

Kachel- und Benachrichtigungsfeatures boten in vorherigen XAML-Frameworks unterschiedliche Unterstützung, daher gibt es keine allgemeine Anleitung zu ihrer Konvertierung. Weitere Informationen zur Funktionsweise der Features in einer Windows Store-App finden Sie unter Verwenden von Kacheln, Signalen und Popupbenachrichtigungen. Wenn Ihre App Pushbenachrichtigungen für Windows Phone verwendet, beachten Sie Ressourcen für Windows Phone-Entwickler.

Verwenden von .NET Framework

Für Windows Store-Apps, die .NET-Sprachen (C# oder Microsoft Visual Basic) verwenden, sind die .NET Framework-APIs, die Sie aufrufen, Teil eines bestimmten .NET Framework-Profils. Dieser Zusammenhang wird im Thema Übersicht über .NET für Windows Store-Apps ausführlich erklärt.

Funktionen der Sprache XAML

XAML für Windows-Runtime stimmt zum großen Teil mit XAML für Silverlight Ressourcen für Windows Phone-Entwickler überein, was die Funktionen betrifft, die Teil der eigentlichen Sprache XAML sind, und ist auch XAML für WPF sehr ähnlich. Doch es gibt einige Unterschiede.

  • Verwenden Sie anstelle des clr-namespace:/assembly=-Qualifizierersatzes nur den using:-Qualifizierer, um vom Code auf den XAML-Namespace zu verweisen. XAML-Namespaces verweisen nicht mehr auf bestimmte Assemblys. Die Qualifizierung und Einbeziehung von Assemblys ist abhängig vom Anwendungsmodell sowie von der Zusammenstellung Ihres App-Pakets.
  • Da Sie keine bestimmten Assemblys zuordnen können, funktionieren einige der zur Unterstützung von CLR (Common Language Runtime)-Primitiven vorgenommenen Verweise auf mscorlib nicht mehr. Stattdessen können Sie die XAML-internen Typen wie x:String verwenden. Weitere Informationen finden Sie unter Systeminterne XAML-Datentypen. Bedenken Sie auch, dass viele der Zeichenfolgen, die Sie zuvor als x:String in einem ResourceDictionary gespeichert haben, möglicherweise besser als Zeichenfolge in einer Ressourcendatei für das Projekt aufgehoben sind. Weitere Informationen finden Sie unter Globalisieren Ihrer App.
  • XAML für Windows-Runtime unterstützt keine benutzerdefinierten Markuperweiterungen.
  • In seltenen Fällen ist für XAML möglicherweise ein x:Name-Attribut erforderlich, wo in Silverlight ein Name-Attribut ausreichend war.
  • Einige Fälle, in denen ein überqualifiziertes Setter.Property-Element für Silverlight-XAML funktioniert hat, sind mit der Windows-Runtime-XAML nicht möglich. Für die meisten Setter.Property-Werte sollte nur der einfache Name der Abhängigkeitseigenschaft festgelegt und nicht versucht werden, den Besitzer zu qualifizieren. (Angefügte Eigenschaften stellen eine Ausnahme dar, für diese sollte weiterhin der Besitzer qualifiziert werden.)
  • Bei der Migration von XAML aus WPF gibt es, zusätzlich zu den bereits beschriebenen Unterschieden zur Silverlight-XAML, Konstrukte, die von XAML für die Windows-Runtime nicht unterstützt werden. Dazu gehören: DynamicResource-Markuperweiterung (und die zugrunde liegende Ressourcensuche), x:ClassModifier und x:Subclass, x:Array und die entsprechende Unterstützung von XAML 2009-Generika, x:Code, x:Static, x:Type, explizit verwendet (für Eigenschaften, bei denen dies erforderlich ist, steht eine x:Type-Auswertung zur Verfügung), VisualTree-Knoten in Vorlagen sowie einige weitere kleinere Unterschiede. Basierend auf XAML-Analyseausnahmen sollten Sie XAML-Kompatibilitätsprobleme in der Entwurfsphase ermitteln können.

Finger- und andere Eingabe

  • Es gibt keine mausspezifischen Eingabeereignisse wie MouseLeftButtonDown. Diese Ereignisse sind – zusammen mit fingereingabespezifischen Ereignissen – unter Pointer-Ereignissen zusammengefasst. In den meisten Fällen können Sie das relevante Mausereignis in PointerPressed, PointerReleased, PointerEntered oder PointerExited konvertieren. Weitere Informationen finden Sie unter Reagieren auf Benutzerinteraktionen. Verwenden Sie für MouseWheel das PointerWheelChanged-Ereignis. Der Deltawert für das Mausrad befindet sich im PointerPointProperties-Element für den primären PointerPoint in den Ereignisdaten.
  • Wenn Sie Manipulationen von Rohdaten zum Aktivieren von Aktionen in Steuerelementen behandeln und visuelle Zustände für die Manipulationsbehandlung erstellt haben, sollten Sie sicherstellen, dass die verwendeten Steuerelemente nicht bereits integrierte Unterstützung für Manipulationen oder Gesten bieten. In der Windows-Runtime-ListBox sind bereits mehrere Interaktionen als Designübergänge aktiviert.
  • Im Hinblick auf Interaktionen im Allgemeinen sollten Sie darüber nachdenken, eher die Gestikereignisse als die Zeigerereignise zu behandeln, denn dies ist in der Regel einfacher. So ist beispielsweise Tapped im Rahmen des Windows-Runtime-Ereignismodells oft ein besseres Ereignis für Interaktionen, die in Silverlight von einem mausspezifischen Ereignis behandelt worden wären.
  • Einzelne Interaktionen per Fingereingabe können pro Element mithilfe von Eigenschaften aktiviert oder deaktiviert werden. So können Sie IsRightTapEnabled z. B. auf false festlegen, woraufhin das Element kein RightTapped-Ereignis verursacht. So sollen potenzielle Probleme mit der Erkennung von Gesten und Bearbeitungen verhindert werden, wenn in der visuellen Struktur der Steuerelementzusammensetzung das Bubbling für Ereignisse erfolgt.
  • Bei Tasten für Tastenereignisse gibt es keine Trennung zwischen PlatformKeyCode und Key. Für die gemeldete Taste aus den Ereignisdaten wird eine andere Enumeration verwendet, nämlich VirtualKey. Weitere Tastenereignisdaten sind als KeyStatus verfügbar.
  • Bei der Zeigererfassung für UIElement können mehrere Zeiger erfasst werden, um Manipulationen per Fingereingabe zu unterstützen, die die Erfassung initiieren. Verwenden Sie eine zeigerbezogene Ereignisdatenklasse, z. B. PointerRoutedEventArgs, um den richtigen Zeigerverweis abzurufen.
  • Aufrufe von Control.Focus sollten einen Aufzählungswert enthalten, der angibt, dass die Fokusaktion programmgesteuert war. Windows-Runtime trennt die Fokusaufrufe, da deren visuelle Zustände für programmgesteuerte Fokusaufrufe ein anderes Verhalten verwenden. Sie müssen vielleicht neue benutzerdefinierte visuelle Zustände für den nicht tastaturbezogenen Fokus zu Ihren Vorlagen hinzufügen.
  • Bestimmte Steuerelemente der Windows-Runtime verfügen über eine integrierte Behandlung von Manipulationen. Zum Beispiel behandelt ein ScrollViewer Interaktionen für Bildlauf, Verschieben und Zoomen intern, sodass das Steuerelement entsprechend mit einer Aktion reagiert. Die Behandlung durch das Steuerelement kann verhindern, dass Zeigerereignisse auf den unteren Ebenen ausgelöst werden. Sie können zum Außerkraftsetzen dieses Verhaltens CancelDirectManipulations aufrufen. Sie sollten aber auch die Eingabebehandlung Ihrer Steuerelemente insgesamt überprüfen. Vielleicht wird Ihr Szenario bereits durch eine integrierte Verhaltensweise abgedeckt. In diesem Fall ist kein Handler auf der Zeigerebene mehr erforderlich.

Grafiken und Layout/Komposition von Elementen

  • Um den Elementsatz für die Funktionen des neuen Grafikstapels soweit wie möglich zu optimieren, haben wir einige APIs/Konzepte herausgenommen, die das Rendering verlangsamen würden. Hierzu zählen z. B. OpacityMask, nicht rechteckige Clips, benutzerdefinierte Beschleunigungsfunktionen und Bitmapeffekte.
  • In der Windows-Runtime werden weder VideoBrush noch RadialGradientBrush unterstützt.
  • Die Bildverarbeitungs-API der Windows-Runtime enthält eine andere und leistungsfähigere zugrunde liegende Bildverarbeitungskomponente (Windows Imaging Component, WIC). Der Vorteil für Sie besteht darin, dass diese Komponente mehr Quellformate für Bilder unterstützt als Silverlight oder WPF. Außerdem stehen einfach zu verwendende Encoder- und Decodertypen sowie eine bereits in die WIC integrierte zusätzliche API für die Bildbearbeitung zur Verfügung. Weitere Informationen finden Sie im Windows.Graphics.Imaging-Namespace.
  • BitmapCache weist eine andere zugrunde liegende Logik als in Silverlight, Silverlight für Windows Phone oder WPF auf. Es kann auch eine Beziehung zwischen der Bitmapzwischenspeicherung und Animationen bestehen und dazu führen, dass einige Animationen als unabhängig angesehen werden. Falls Sie UIElement.CacheMode verwenden, sollten Sie das Profil der App neu erstellen und prüfen, ob eine UIElement.CacheMode-Einstellung für Teile der UI eine Leistungssteigerung für die Windows Store-App ergibt. Weitere Informationen finden Sie unter UIElement.CacheMode und DebugSettings.IsOverdrawHeatMapEnabled.
  • In einigen Szenarien, in denen Sie WriteableBitmap verwendet haben, ist auch die Verwendung von RenderTargetBitmap möglich.

Steuerelemente

  • Windows Store-Apps und andere Frameworks mit XAML-basierter Benutzeroberflächendefinition enthalten die gleichen grundlegenden Steuerelemente (z. B. Button und ListBox) und grundlegenden Layoutcontainer (z. B. Border, Grid und StackPanel). Die Windows-Runtime verfügt ebenfalls über viele auflistungsfähige Steuerelemente wie SemanticZoom und FlipView. Außerdem ist GridView ein eigenständiges Steuerelement und keine Komponente, die in einer ListView verwendet wird, wobei der einzige wirkliche Unterschied zwischen GridView undListView in der dominanten Ausrichtung der jeweils präsentierten Elemente besteht. Weitere Informationen finden Sie unter Steuerelemente nach Funktion.
  • Obwohl es oft möglich ist, das gleiche Steuerelement wie in der ursprünglichen Silverlight- oder WPF-App zu verwenden, und vielleicht sogar eine ganze Benutzeroberfläche auf entsprechende Komponenten migriert werden kann, ist dies nicht immer der beste Ansatz. Insbesondere beim Definieren der Benutzeroberfläche Ihrer App sollten Sie gegebenenfalls noch einmal innehalten und den Entwurfsleitfaden für Windows Store-Apps zu Rate ziehen. Es kann z. B. sein, dass die ursprüngliche App und die Steuerelemente ihrer Benutzeroberfläche nicht in erster Linie für Fingereingabe entworfen wurden, während dies bei der Windows Store-App unbedingt der Fall sein sollte. Die Handhabung der UI im Allgemeinen fällt ebenfalls ganz anders aus, da Sie keinen Browser mehr als Host verwenden. Weitere Informationen zum Entwurf finden Sie unter UX-Design für Apps. Weitere Informationen zu Richtlinien für die UX für Steuerelemente finden Sie unter Index der Richtlinien für die UX.

Animationen, Übergänge, visuelle Zustände, Stile

  • Mit der Windows-Runtime wird das Konzept der Charakteranimationen hinzugefügt. Diese können für XAML als Übergangsanimationen und Designanimationen verwendet werden, die direkt auf UI-Elemente angewendet werden, ohne dass eine Ausrichtung auf mehrere Eigenschaften des Elements erforderlich ist. Storyboardanimationen funktionieren nahezu genauso. Nicht alle Storyboardanimationen sind jedoch standardmäßig aktiviert. Mit dem standardmäßigen Deaktivieren abhängiger Animationen sollen Entwickler für die Leistungsanforderungen von Animationen sensibilisiert werden, die eine erhebliche Auswirkung auf den UI-Hauptthread haben. Falls die Animation nicht erwartungsgemäß ausgeführt wird, können Sie versuchen, EnableDependentAnimations auf true festzulegen. Gehen Sie dabei jedoch mit Bedacht vor, weil die Ausführung abhängiger Animationen auch einen Leistungsaufwand erfordert. Weitere Informationen finden Sie unter Animieren der Benutzeroberfläche, Storyboardanimationen und Erzielen flüssiger Animationen.
  • Falls Ihre XAML-Definitionen für den Ansichtszustand Präfixe vom Typ "vsm:" enthalten, entfernen Sie die Präfixverwendungen und die entsprechende Definition. Präfixe für den Ansichtszustand und Namespaces müssen nicht mehr separat zugeordnet werden.
  • Achten Sie beim Konvertieren von Ansichtszuständen darauf, "Mouse"-Konzepte in "Pointer"-Konzepte zu konvertieren. Orientieren Sie sich dabei an der Vorgehensweise zum Ändern der Ereignisbehandlung auf Elementebene. Unter Umständen empfiehlt es sich, sowohl die Namen des visuellen Zustands zu ändern als auch die Eigenschaften anzupassen, die der Zustand ändert. Beachten Sie die vorhandenen XAML-Ressourcenverzeichnisse, etwa generic.xaml im Unterordner include/winrt/xaml/design einer Installation des Windows SDK. Hier finden Sie möglicherweise Empfehlungen zu Mustern, an denen Sie sich bei visuellen Zuständen und den zugehörigen Ereignissen orientieren können.
  • Falls Sie für ein konvertiertes benutzerdefiniertes Steuerelement bereits über ein Design mit hohem Kontrast verfügen, müssen Sie die Vorgaben des ThemeDictionaries-Modells befolgen, wenn Sie die Designs mit der Steuerelementdefinition verknüpfen. Es kann z. B. ratsam sein, die in der HighContrastScheme-Enumeration benannten Designs zu unterstützen. Weitere Informationen finden Sie unter XAML-Beispiel für hohen Kontrast.
  • Sie sollten eine Vorlage für ein helles und für ein dunkles Design für Ihre Steuerelemente unterstützen, wenn Ihre App Designwechsel zulässt. Dies ist bei den Standardvorlagen der Fall, aber möglicherweise müssen Sie den benutzerdefinierten Vorlagen, die Sie importiert haben, ein Design hinzufügen.
  • WPF und Silverlight unterstützten die Möglichkeit zum Verwenden eines Binding-Ausdruck, um das Value-Element für einen Setter in einem Style-Element anzugeben. Die Windows-Runtime unterstützt keine Binding-Verwendung für Setter.Value (die Binding führt keine Bewertung aus, und der Setter hat keine Auswirkung. Es werden keine Fehler angezeigt, Sie erhalten jedoch auch nicht die gewünschten Ergebnisse). Ersetzen Sie beim Konvertieren von XAML-Stilen aus WPF- oder Silverlight-XAML-Code alle Binding-Ausdrucksverwendungen durch Zeichenfolgen oder Objekte, die Werte festlegen. Gestalten Sie alternativ die Werte als freigegebene StaticResource-Werte und nicht als durch die Binding abgerufene Werte um.

Medien

  • Die Medien-APIs sind ähnlich, aber die Verwaltung digitaler Rechte (DRM) ist auf andere Weise in die Medien-APIs integriert. Im Gegensatz zu Silverlight besitzt Windows ein austauschbares DRM-Modell. Eines von mehreren möglicherweise unterstützten Modellen ist PlayReady. Daher werden andere APIs verwendet, um einen Inhaltsschutz-Manager berücksichtigen zu können.

  • MediaElement ist weitgehend damit identisch, wahrscheinlich möchten Sie aber eine neue XAML-Vorlage für vorherige MediaElement-Transportsteuerelementvorlagen erstellen, damit die Benutzeroberfläche Fingereingaben unterstützt. Sie können auch mithilfe von AreTransportControlsEnabled einige standardmäßige Transportsteuerelemente abrufen. Interessante neue Funktionen der Windows-Runtime für die MediaElement-API sind, dass Sie ein "Poster" für das Laden hinzufügen, Verpackungsmodi für Video in Stereo erkennen und verwenden sowie Videoeffekte hinzufügen können.
  • Bei der Kameraaufnahme der Plattformen bestehen grundsätzliche Unterschiede. Falls Sie über dieses Features verfügen, schreiben Sie Code eher neu, als ihn zu konvertieren. Weitere Informationen finden Sie unter So wird's gemacht: Anzeigen einer Videovorschau von einer Webcam und Beispiel für die Medienaufnahme mit einem Aufnahmegerät. Sie verwenden wahrscheinlich ein CaptureElement als Anzeigeoberfläche, da VideoBrush nicht verfügbar ist.

URIs

Die Behandlung von URIs (Uniform Resource Identifier) für Dateiverweise funktioniert in Windows-Runtime etwas anders. Relative URIs werden nicht unterstützt, zumindest nicht auf der Ebene der reinen URI-Typen. Bei bestimmten API-Aufrufen wird möglicherweise System.Uri von .NET angezeigt, um Ihnen die Auswahl von RelativeOrAbsolute zu ermöglichen, aber in der Praxis sind alle derartigen URIs absolut und werden anhand von Konzepten und Speicherorten, z. B. anhand des App-Pakets, der benutzerdefinierten Speicherorte, der App-Daten usw., ausgewertet.

Möglicherweise müssen alle Eigenschaftswerte mit einem URI überprüft werden. Sie können keine URIs nach dem file:-Schema verwenden. Gegebenenfalls lässt sich das XAML mit URI-Verweisen auf Werte wie Image.Source-Dateien übertragen, ohne dass Sie sich dabei Gedanken über URIs machen müssen, und als neue Windows-UI verwenden. Das hängt jedoch davon ab, wie Ihre ursprüngliche App strukturiert war. Ein in XAML angegebener URI erscheint oftmals wie ein relativer URI, aber diese Zeichenfolgen werden vom XAML-Parser verarbeitet und ausgeführt, bevor irgendwelche Eigenschaften zur Laufzeit festgelegt werden. Um dieses Verhalten im CodeBehind zu reproduzieren, verwenden Sie den FrameworkElement.BaseUri als baseUri-Parameterwert im Uri-Konstruktor, der einen Basis-URI mit einem relativen URI kombiniert. Weitere Informationen finden Sie unter Definieren von App-Ressourcen.

Datei- und Speicher-APIs

Die Techniken, die Sie in der Windows-Runtime für den Zugriff auf Dateien und Speicher verwenden, haben nicht viel mit denen in .NET gemein. Dies ist insbesondere darauf zurückzuführen, dass viele der APIs ein asynchrones Muster und async/await-Schlüsselwörter verwenden. Weitere Informationen finden Sie unter Zugreifen auf Daten und Dateien.

XML und XMLDOM

Der für eine Windows Store-App mit C++, C# oder Visual Basic verfügbare Bereich von .NET beinhaltet weder XML-DOM-APIs des Frameworks, noch leitet er Basistypen an den Linq-Namespace weiter. Suchen Sie in Windows.Data.Xml.Dom und System.Xml.Linq nach ähnlichen APIs.

Gehostete und parallel angeordnete HTML

Bei Silverlight liegt die parallel angeordnete HTML auf der Hand, da das Silverlight-Steuerelement innerhalb eines DOM-Elements gehostet wird und die anderen HTML-Inhalte sich ein einem anderen DOM-Element oder einem iframe befinden. Für WPF haben Sie möglicherweise das WebBrowser-Steuerelement verwendet. Bei einer Windows Store-App, die XAML für ihre UI verwendet, sollte das Steuerelement WebView verwendet werden, um HTML-Inhalte anzuzeigen. Das WebView-Modell besteht darin, dass die HTML in einem Bereich innerhalb der allgemeinen XAML-UI angezeigt wird. Die HTML-Inhalte, die Sie in einer Windows Store-App anzeigen lassen, müssen aus Gründen der Benutzererfahrung und der Sicherheit überprüft werden. Sie können dem im iframe einer Silverlight-App dargestellten Inhalt nicht einfach ein neues Ziel zuweisen, damit er zur Source eines WebView wird. Sie müssen außerdem ermitteln, welche Logik in JavaScript-Code für das HTML verbleiben soll, anstatt ihn als CodeBehind für Ihre Seite auszuführen. Die hier getroffenen Entscheidungen hängen davon ab, wie die Windows-Runtime die Benutzerinteraktionsereignisse innerhalb der WebView-Grenzen verarbeitet. Weitere Informationen finden Sie unter WebView.

Konvertieren von Projekten

Grundsätzlich beginnen Sie zum Konvertieren eines vollständigen Projekts am besten mit einer der vorhandenen Projektvorlagen für eine Windows Store-App. Verwenden Sie dann die Funktion Hinzufügen im Projektmappen-Explorer, um neue oder vorhandene XAML-Seiten und CodeBehind-Dateien hinzuzufügen. Migrieren Sie zum Schluss bestimmte Codeblöcke in die XAML- und Codedateien. Wenn Sie so vorgehen, umgehen Sie möglicherweise unbeabsichtigt vorhandene Implementierungsdetails und eine u. U. vorhandene Infrastruktur für Projekte und Builds aus dem vorherigen Framework. Sie können die using-/Imports-Anweisungen mit den richtigen "Windows"-Namespaces verwenden, auf die aktuellen Buildtypen verweisen und auf das .resw-Ressourcensystem zugreifen, da all diese Funktionen in neuen Projekten und Seiten mit Vorlagen zur Verfügung stehen.

Falls Sie für Ihr Silverlight-Projekt das Binding-basierte Lokalisierungssystem wie unter So wird's gemacht: Sicherstellen der Lokalisierbarkeit von XAML-Inhalten beschrieben verwendet haben, sollten Sie für das Lokalisierungsverfahren die Umstellung auf die Verwendung von Zeichenfolgen erwägen, die im System für den Paketressourcenindex (Package Resource Index, PRI) deklariert werden. Das Binding-basierte Lokalisierungssystem funktioniert weiterhin, aber es verfügt bei Weitem nicht über die Toolunterstützung, die mit PRI- und .resw-Dateien möglich ist. Dies gilt sowohl in Visual Studio als auch für alle dedizierten Lokalisierungsprozesse oder -tools, die auf der Lokalisierungsmethodik von Visual Studio basieren.

Wenn Sie versuchen möchten, ganze Codedateien zu übertragen, ist es oft möglich, nach using-/Imports-Anweisungen oder vollqualifizierten Verweisen zu suchen und sie zu ersetzen. "System.Windows" muss z. B. durch "Windows.UI.Xaml" ersetzt werden. Es gibt einige Ausnahmen von dieser allgemeinen Regel für die Bezüge von Silverlight-/WPF-Typen zu den Windows-Runtime-Typen und zu den entsprechenden Namespaces. Wir weisen auf diese Fälle in der API-Dokumentation (unter "Hinweise") hin.

Weitere Informationen zu den Projektvorlagen finden Sie unter C#-, VB- und C++-Projektvorlagen für Windows Store-Apps.

Weitere Ressourcen zum Migrieren von Apps

Verwandte Themen

Ressourcen für Windows Phone-Entwickler
Roadmap für Windows Store-Apps mit C# oder Visual Basic
Richtlinien für die UX von Windows Store-Apps
C#-, VB- und C++-Projektvorlagen für Windows Store-Apps
Übersicht über .NET für Windows Store-Apps
.NET Framework-Unterstützung für Windows Store-Apps und die Windows-Runtime

 

 

Anzeigen:
© 2014 Microsoft