Migrieren Ihrer Apps von der Developer Preview zur Consumer Preview

Entwicklerblog für Windows 8-Apps

Ein Einblick in die Entwicklung von Apps im Metro-Stil – präsentiert vom Windows 8-Entwicklerteam

Migrieren Ihrer Apps von der Developer Preview zur Consumer Preview

  • Comments 0

Hallo, mein Name ist John Sheehan. Ich arbeite als Partner Architect im Windows-Entwicklungsteam.

Wir möchten uns herzlich für die Apps bedanken, die Sie für die Vorabversionen entwickeln. Mit Ihrem Feedback können wir Windows 8 zu etwas ganz Besonderem machen. Wenn Sie an der Entwicklung einer Vorabversion mitarbeiten, müssen Sie Ihre Apps natürlich für jede Veröffentlichung der Vorabversion aktualisieren. Genau darum geht es in diesem Beitrag: um das Migrieren von Projekten aus der Developer Preview in die Consumer Preview. Ich werde hier einige der Änderungen hervorheben. Eine ausführlichere Beschreibung der Änderungen finden Sie in unserem herunterladbaren Whitepaper zum Migrieren von Apps von //Build zur Windows 8 Consumer Preview im Entwicklungscenter.

Wenn Sie sich mit dem Migrieren von Apps zur Consumer Preview beschäftigen, werden sich einige von Ihnen sicher fragen, weshalb wir manche der Änderungen umgesetzt haben. Ich kann Ihnen versichern, dass wir jede Änderung mit Bedacht abwägen. Einige Verbesserungen basieren auf dem direkten Feedback, das wir erhalten: Wenn ein Feature zu kompliziert ist, vereinfachen wir es – oder es fehlen Funktionen, die Sie benötigen. Genauso kann es vorkommen, dass wir ein Feature fertig stellen und bei seiner Verwendung feststellen, dass es nicht den gewünschten Zweck erfüllt. Also verbessern wir es anhand unserer eigenen Erfahrungen. Es gibt viele Faktoren, über die wir nachdenken. Sie können sich sicher sein, dass jede unserer Entscheidungen sorgfältig überdacht wurde, damit wir Ihnen eine großartige Plattform für Ihre Apps im Metro-Stil bieten können.

Ich bin den Migrationsprozess selbst Schritt für Schritt mit der Connect 4-App durchgegangen, die ich für die Developer Preview entwickelt habe. Ich weiß, dass die Migration etwas Aufwand kostet – wenn Sie sich jedoch an die in diesem Beitrag und dem Dokument erläuterten Schritte halten, sollten Sie den Vorgang recht schnell abgeschlossen haben.

Fangen wir an!

Projekte neu anlegen

Sicherlich ist der Gedanke verlockend, Ihr vorhandenes Projekt in seinem Zustand zu belassen und eine Migration zur Consumer Preview durchzuführen. Jedoch hat sich seit der Developer Preview so viel verändert, dass Sie am besten mit einem neuen Projekt beginnen. Beispiel: In Visual Studio wurden einige Änderungen in den Projektdefinitionsdateien vorgenommen: die JavaScript-Projekterweiterung wurde in „JSPROJ“ umbenannt, und die Importanweisung wurde auf CSPROJ-/VBPROJ-Dateien geändert. Ihr vorhandenes Projekt würde sich aufgrund dieser Änderungen nicht einmal öffnen. Wenn Sie ein neues Projekt starten, können Sie Komponenten des alten Projekts in das neue übernehmen.

Diese Schritte bieten eine gute Richtlinie für das Migrieren von Code. Diese Schritte und viele weitere Migrationsdetails sind auch in //Build to Windows 8 Consumer Preview aufgeführt. (Darauf werde ich in diesem Beitrag noch mehrfach hinweisen.)

  1. Erstellen Sie ein neues Projekt in Visual Studio, und wählen Sie die Vorlage aus, die der Benutzeroberfläche Ihrer vorhandenen App am ähnlichsten ist.
  2. Wenn die neuen Elementvorlagen die von Ihnen benötigten Verträge und Features unterstützen, beispielsweise den Vertrag für „Dateiauswahl“ oder „Suche“, sollten Sie diese verwenden, statt Ihren vorhandenen Code erneut zu verwenden.
  3. Nachdem Sie die grundlegenden Elemente Ihrer Benutzeroberfläche mithilfe der neuen Vorlagen wiederhergestellt haben, sollten Sie die Audio- und visuellen Anlagen Ihres alten Projekts in das neue Projekt migrieren. Beschränken Sie den zusätzlichen Code, den Sie zum Projekt hinzufügen, auf die benutzerdefinierte Geschäftslogik, die das Kernstück Ihrer App ausmacht.
  4. Passen Sie Ihre neue Benutzeroberfläche (die Sie durch die neuen Vorlagen strukturiert haben) abschließend an Ihre Audio- und visuellen Anlagen und an Ihre Back-End-Logik an.

Wenn Sie diese Schritte befolgen, werden viele Änderungen von selbst in den Code Ihrer App übernommen. Lassen Sie uns nun einige spezielle Änderungen ansprechen, die möglicherweise auf Ihren Code zutreffen, wenn Sie diesen in die neuen Vorlagen übertragen.

Allgemeine Änderungen für alle Programmiersprachen

Zunächst möchte ich auf einige Änderungen am grundlegenden Programmiermodell eingehen, die Entwickler aller Programmiersprachen betreffen.

Manifest-Änderungen

Das Manifest kann man als elementares Grundgerüst Ihrer App bezeichnen. Wenn Änderungen an der Plattform vorgenommen werden, wirken sich diese häufig auf die Struktur des Manifests aus. Wenn man die Anzahl der Änderungen am Manifest betrachtet, ist es wahrscheinlich am einfachsten, auf Grundlage des neuen Manifests zu beginnen und dieses mit dem Manifest-Editor zu bearbeiten, anstatt ein vorhandenes Manifest zu portieren. Das neue Manifest wird erstellt, wenn Sie ein neues Projekt erstellen.

„Warmstart“ für das asynchrone Modell

In der Developer Preview wurden alle asynchronen Methoden „kalt“ aufgerufen. Beim Aufruf einer asynchronen Methode wurde ein asynchrones Vorgangsobjekt zurückgegeben. Anschließend wurde eine Registrierung für Rückrufe für Vervollständigung und Fortschritt (falls zutreffend) für dieses Vorgangsobjekt ausgeführt und dann IAsyncInfo.Start aufgerufen. Das Problem dieses Modells bestand darin, dass der Aufruf von Start redundant war. Als Entwickler konnten Sie eigentlich davon ausgehen, dass der asynchrone Vorgang mit dem ersten Methodenaufruf gestartet wird.

Um das asynchrone Modell intuitiver zu gestalten, haben wir es nun als „Warmstart“-Modell konzipiert und umgesetzt. Wenn Sie in der Consumer Preview eine asynchrone Methode aufrufen, wird ein asynchrones Vorgangsobjekt zurückgegeben. Es ist jedoch nicht erforderlich, „Start“ aufzurufen. Stattdessen wird der Vorgang beim Aufruf der asynchronen Methode implizit gestartet. Da „Start“ nicht mehr erforderlich ist, wurde es aus IAsyncInfo entfernt.

Wenn Sie bereits zuvor .then() (JavaScript) oder await (C#) verwendet haben, hat diese Veränderung keinerlei Auswirkungen auf Ihre Arbeit.

Außerdem wurden PPL-Tasks hinzugefügt, um das asynchrone Programmieren in C++ zu vereinfachen. Lesen Sie das Dokument //Build to Windows 8 Consumer Preview, und migrieren Sie Ihren asynchronen Code in das PPL-Modell.

Deterministische Verwaltung der Lebensdauer für Windows-Runtime-Objekte (IClosable)

Dank Windows-Runtime-APIs kann Ihre App auf Systemressourcen zugreifen, z. B. Dateihandles und Netzwerksockets. Diese Ressourcen sind begrenzt, und es kommt häufig vor, dass der Benutzer oder andere Apps diese nicht verwenden können, wenn Ihre App darauf zugreift. Ihre App muss also diese Ressourcen wieder freigeben, nachdem sie sie nicht mehr benötigt. Das explizite Freigeben dieser Ressourcen war in der Developer Preview kompliziert, weshalb viele Apps länger als erforderlich auf diese Ressourcen zugriffen.

In der Consumer Preview können Windows-Runtime-APIs, die auf diese Systemressourcen zugreifen, die Zugriffsdauer steuern. In JavaScript machen diese WinRT-Objekte beispielsweise eine Close-Methode verfügbar und implementieren in C# die IDisposable-Schnittstelle. Da die Verwaltung der Lebensdauer direkt für diese WinRT-APIs verfügbar gemacht wird, ist es nun deutlich einfacher, Systemressourcen freizugeben, wenn Ihre App sie nicht mehr verwendet. Verringern Sie mit diesen neuen Möglichkeiten zur Verwaltung der Lebensdauer den Ressourcenverbrauch Ihrer App, und stellen Sie sicher, dass Ihre Kunden jederzeit auf ihre Systemressourcen, z. B. Dateien, zugreifen können, wenn diese nicht durch die App verwendet werden.

Vereinfachtes WinRT-Threadingmodell

In Ihrem Feedback teilten Sie uns mit, dass die zugrunde liegende WinRT des COM-Threadingmodells verwirrend war, da sie Überlegungen enthielt, die in anderen Programmierumgebungen nicht vorhanden sind. Unter anderem wurden folgende Probleme genannt:

  • Die Objektlebensdauer ist an das Apartment gebunden, in dem das Objekt erstellt wurde.
  • Das automatische Marshallingverhalten verstößt gegen das Principle of Least Surprise (Prinzip der geringsten Überraschung).
  • Ereignisrückrufe werden häufig als unerwarteter Thread ausgeführt.
  • Delegaten sind zwischen C++ und C# nicht konsistent.

Um diese Probleme zu beheben, haben wir das Threadingmodell für WinRT-Objekte geändert. Auf hoher Ebene wurden folgende Änderungen umgesetzt:

  • Die Lebensdauer eines Objekts ist nun an offene Verweise gebunden. Das Objekt bleibt gültig, bis der letzte Verweis entfernt wurde.
  • Die meisten Objekte sind agil. Methodenaufrufe für diese Objekte werden direkt im aktuellen Thread ausgeführt.
  • Die häufigsten Ereignisse werden an den Thread zurückverwiesen, bei dem das Ereignis registriert wurde. Dennoch gibt es Fälle, in denen Ereignisrückrufe für einen Arbeitsthread auftreten können, diese sind jedoch weniger verbreitet.
  • C++-Delegaten sind nun standardmäßig agil, wie bereits die C#-Delegaten in der Developer Preview. Delegaten können dennoch ein Marshalling zurück zum Thread ausführen, auf dem sie erstellt wurden, wenn Sie beim Erstellen des Delegaten CallbackContext::Same angeben.

Änderungen an Windows.ApplicationModel (Verträge)

Wir haben bereits mit der Consumer Preview eine Vielzahl von Verbesserungen an den Verträgen eingeführt. Diese Verbesserungen wurden durch Änderungen an den APIs, der Funktionalität, Manifestregistrierungen und der Benutzeroberfläche erzielt. Verträge wie „Suche“, „Freigabe“, „Einstellungen“, „Dateiauswahl“ usw. wurden in auf verschiedene Weisen verbessert. Beispielsweise wurde für „Dateiauswahl“ der neue Vertrag FileSavePickerActivatedEventArgs hinzugefügt, sodass Ihre App für die Funktion „Speichern unter“ ein zulässiger Speicherort ist. Dies ist ein äußerst leistungsfähiges Feature – Sie können so eine Dateiauswahl erstellen, mit der Benutzer Dateien in der Cloud so einfach öffnen und schließen können, als wenn diese auf dem lokalen Datenträger gespeichert wären. Um dieser Änderung Rechnung zu tragen, haben wir den Vertrag für „Dateiauswahl“ in der Consumer Preview in FileOpenPickerActivatedEventArgs umbenannt.

Bei Verträgen, die in Visual Studio unterstützt werden, können die Änderungen am einfachsten eingebunden werden, indem der Vertrag mithilfe der neuen Elementvorlage neu erstellt wird. Anschließend können Sie bestehenden Code, der den Vertrag unterstützt, zur neuen Vorlage hinzufügen.

URI-Protokollschemas

Um auf Inhalte im Paket der App oder in ApplicationData-Statusspeicherorten zugreifen zu können, waren verschiedene Apps auf URI-Protokollschemas angewiesen. Zu diesen APIs zählen Ressourcentags in Apps im Metro-Stil, die mit HTML/CSS/JS erstellt wurden, Live-Kacheln, die ResourceLoader-APIs, die XAML WebView-Steuerung und die Dateispeicherungs-APIs.

Protokollnamen wurden aktualisiert, um für Konsistenz bei allen Apps im Metro-Stil und Windows 8-Integrationspunkten zu sorgen. Außerdem wurden folgende Protokollschemas umbenannt:

Developer Preview-Schema

Consumer Preview-Schema

ms-wwa://

ms-appx://

ms-wwa-web://

ms-appx-web://

localfolder://

ms-appdata://

Zusätzlich wurden XAML-Apps für den Ressourcenzugriff auf die Verwendung unterstützter Protokollschemas beschränkt, z. B. auf ms-appx://.

Wichtige Änderungen an HTML-/CSS-/JS-Apps im Metro-Stil

Mehrere Änderungen in der Consumer Preview gelten speziell für Apps im Metro-Stil, die in HTML/CSS/JS verfasst wurden. Wichtige Änderungen sind:

Änderungen an Steuerelementen

An den JavaScript- und HTML-Steuerelementen, die in der Developer Preview verfügbar sind, wurden in Reaktion auf Ihr Feedback zahlreiche Änderungen vorgenommen. Es ist nun einfacher, Ihrer App diese Steuerelemente hinzuzufügen, und die Methoden zum Verbinden von Steuerelementen mit Inhalten sind intuitiver. Zu den wichtigen Steuerelementen, die verändert wurden und die Sie aktualisieren müssen, zählen ListView, AppBar und FlipView. So können Sie beispielsweise ArrayDataSource nicht mehr verwenden, um eine ListView aufzufüllen. Stattdessen wird zum Auffüllen der ListViews nun WinJS.Binding.List verwendet. Binding.List vereinfacht das Arbeiten mit Speicherdaten Ihrer ListView erheblich.

Es sei erneut darauf hingewiesen, dass sämtliche Änderungen der Steuerelemente in //Build to Windows 8 Consumer Preview aufgeführt sind.

Navigation innerhalb des Dokuments der höchsten Ebene

In der Vergangenheit konnten Sie innerhalb des Dokuments der höchsten Ebene Ihrer App über die lokal gepackten StartPage zu einer webbasierten URL navigieren. Aus diesem Grund war eine Interaktion einer App mit sämtlichen wichtigen Benachrichtigungen, z. B. „Anhalten“ und „Fortsetzen“ nicht möglich, da es sich bei diesen Ereignissen um Windows-Runtime-Ereignisse handelt. Auf WinRT-Objekte kann aus Sicherheitsgründen nicht vom Webkontext aus zugegriffen werden. In der Consumer Preview können Sie nur noch zu Inhalten navigieren, die sich im lokalen Kontext befinden. Anders gesagt: Diese Inhalte müssen aus Ihrem App-Paket stammen, und auf diese muss über das ms-appx://-Protokollschema verwiesen werden.

Das bedeutet, dass Sie möglicherweise Ihre App-Logik neu organisieren müssen, damit diese Ihre Webinhalte mithilfe eines iframes lädt und dabei dauerhaft ein einzelnes, persistentes Dokument höchster Ebene im Speicher behält, das aus dem lokalen Kontext stammt.

WinJS-Seitenmodell und Laden von WinJS-Fragmenten

In der Developer Preview war es für die Navigation zu verschiedenen Seiten innerhalb einer App (bei HTML-/CSS-/JS-Apps im Metro-Stil) erforderlich, Fragmente über APIs zu laden. Dieses Modell war unzuverlässig und erforderte das Schreiben von umfangreichem Code, um z. B. die Initialisierung der Steuerung oder den Seitenstatus zu behandeln.

In der Consumer Preview wurde in der Windows-Bibliothek für JavaScript (WinJS) eine Seitensteuerung auf hoher Ebene eingeführt, mit der Inhalte innerhalb einer Seite geladen werden können. Außerdem wurden die Visual Studio-Vorlagen so aktualisiert, dass sie diese Seitensteuerelemente verwenden. In den meisten Fällen ist es dank der Seitensteuerelemente nicht nötig, die APIs zum Laden von Fragmenten direkt anzusteuern. Dies vereinfacht das Navigieren durch HTML-Fragmente erheblich.

Seitensteuerelemente werden über dem Fragmentladeprogramm erstellt. Diese stellen ein Objekt bereit, das gerenderte Fragmente sichert, bieten einen Speicherort für den Status und behandeln automatisch die Überordnung des Fragments. Ihr Fragment, das dem überordneten DOM-Element angefügt ist, wird von einem WinJS-Steuerelement gesichert, das für einen definierten Lebenszyklus sorgt. Sie können diesem Steuerelement außerdem beliebige Methoden oder einen beliebigen Status hinzufügen.

Beenden von Apps bei Ausnahmefehlern

JavaScript ist kaum anfällig gegen Ausnahmefehler. Das Ausführen von Code innerhalb der Funktion, die die Ausnahme enthält, wird ausgesetzt. Alle anderen Komponenten werden jedoch weiter ausgeführt, dass dieser Ausnahmefehler häufig gar nicht auffällt. Wenn dies geschieht, befindet sich Ihre App jedoch nicht mehr in einem vorhersagbaren Zustand. Dies bedeutet, dass die Daten, auf denen Ihre App beruht, möglicherweise nicht mehr gültig sind oder dass Ihre Benutzeroberfläche sich möglicherweise in einem defekten Zustand befindet. Dies kann im Falle eines Webbrowsers akzeptabel sein, da der Benutzer die Seite einfach aktualisieren kann. Im Falle einer App im Metro-Stil muss der Benutzer jedoch in der Lage sein, diese über Wochen hinweg auszuführen, ohne sie schließen und erneut öffnen zu müssen.

Daher sorgen JavaScript-Ausnahmefehler dafür, dass eine Fehlermeldung in das Ereignisprotokoll eingetragen und die App neu gestartet wird.

Wichtige Änderungen an XAML-Apps im Metro-Stil

Wenn Sie bereits XAML-Apps im Metro-Stil entwickelt haben, werden Sie in der Consumer Preview verschiedene Änderungen feststellen, die sich speziell auf Ihre Programmiersprachen beziehen.

Unterstützung für C++-Datenbindung

In der Consumer Preview haben wir wesentliche Änderungen für C++-Entwickler umgesetzt, um das Binden einer XAML-Benutzeroberfläche an benutzerdefinierte C++-Klassen zu vereinfachen. Wenn Sie mithilfe des Windows.UI.Xaml.Data.Bindable-Attributs Anmerkungen für Ihre Klassen verwenden, wird Ihre Klasse für das Bindungsmodul sichtbar, und Sie müssen die Schnittstelle für diese Klasse nicht mehr implementieren. Diese verringert den zusätzlichen Codeaufwand erheblich.

Navigations-API

Wenn Ihre XAML-App im Metro-Stil Navigations-APIs, z. B. Windows.UI.Xaml.Controls.Frame.Navigate oder Windows.UI.Xaml.Navigation.NavigationEventArgs.Type, verwendet, müssen Sie einige kleine Änderungen vornehmen. Diese APIs akzeptieren nun Type-Objekte als Ziel, d. h. die Klasse muss nicht mehr über ihren Zeichenfolgennamen angegeben werden. Eine vollständige Liste der betroffenen APIs finden Sie in //Build to Windows 8 Consumer Preview.

AppBar

Wir haben zahlreiche Änderungen an der Windows.UI.Xaml.Controls.ApplicationBar-Funktion vorgenommen, damit diese mit der Benutzererfahrung von Apps im Metro-Stil konsistent ist. Außerdem entfällt durch diese Änderungen die Notwendigkeit, die Konsistenz der Implementierungsdetails mit der Benutzererfahrung des Metro-Stils zu gewährleisten.

Eine wesentliche Änderung besteht darin, dass Sie eine AppBar mithilfe der neuen Eigenschaften Windows.UI.Xaml.Controls.Page.TopAppBar und BottomAppBar innerhalb Ihrer App platzieren können. Wir empfehlen, dass Sie diese neuen Eigenschaften verwenden, statt Ihre AppBars direkt im Layout der App zu platzieren. Außerdem wurden verschiedene weitere AppBar-Eigenschaften hinzugefügt, umbenannt oder entfernt.

Semantischer Zoom

„Semantischer Zoom“ bedeutet bei der Windows 8-Plattform, dass der Benutzer Inhalte verkleinern und vergrößern und ihren Kontext ändern kann. Beispielsweise wird beim Vergrößern einer Fotosammlung die Ansicht von kleinen Miniaturansichten zu großen Vorschaubildern mit Name, Datum und weiteren Bildinformationen geändert. Dieser semantische Zoom wurde in der Developer Preview durch das JumpViewer-Steuerelement realisiert, das nun in SemanticZoom umbenannt wurde. Durch den neuen Namen wird das Benutzererlebnis besser veranschaulicht, das Sie durch Implementierung eines dieser Steuerelemente in Ihrer App bereitstellen.

Blick nach vorn

Zusätzlich zu den Änderungen, die in diesem Beitrag angesprochen wurden, haben sich auch viele APIs in der Windows-Runtime und der Windows-Bibliothek für JavaScript geändert. Beispielsweise gibt es in der Windows-Runtime Änderungen an den Namespaces Networking, Media, System, UI, Storage, Devices, ApplicationModel, Globalization, Graphics und Data. Viele dieser Änderungen sind unwesentlich, dennoch sollten Sie beim Migrieren Ihres Codes sicherstellen, dass die erforderlichen Änderungen an Ihrer App umgesetzt wurden. Dieser Beitrag soll Ihnen den Einstieg erleichtern. Er befasst sich jedoch nur mit einem Bruchteil der Änderungen, die wir an der Entwicklungsplattform vorgenommen haben. Wie ich während dieses Beitrags mehrfach betont habe, sollten Sie //Build to Windows 8 Consumer Preview im Entwicklungscenter lesen. In diesem Dokument finden Sie ausführliche Informationen zum Migrieren Ihrer App zur Consumer Preview.

Ich freue mich auf Ihre Kommentare. Sollten Sie eingehendere Fragen zur Vorgehensweise haben, stellen Sie diese am besten in den Entwicklerforen, wo wir Ihnen gerne mit Rat und Unterstützung zur Verfügung stehen.

– John Sheehan, Partner Architect, Windows-Entwicklungsteam

  • Loading...
Leave a Comment
  • Please add 1 and 2 and type the answer here:
  • Post