Die Entwicklung von Windows 8
Windows Store-Blog für Entwickler
IEBlog – Deutsch
Visual Studio-Blog
Windows-Teamblogs
Blog „Inside Windows Live“
Windows 8 Release Preview herunterladen
Dev Center – Apps im Metro-Stil
Folgen Sie uns @windevs
//build/-Konferenz
Foren zu Windows-Apps im Metro-Stil
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!
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.)
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.
Zunächst möchte ich auf einige Änderungen am grundlegenden Programmiermodell eingehen, die Entwickler aller Programmiersprachen betreffen.
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.
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.
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.
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:
Um diese Probleme zu beheben, haben wir das Threadingmodell für WinRT-Objekte geändert. Auf hoher Ebene wurden folgende Änderungen umgesetzt:
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.
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://.
Mehrere Änderungen in der Consumer Preview gelten speziell für Apps im Metro-Stil, die in HTML/CSS/JS verfasst wurden. Wichtige Änderungen sind:
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.
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.
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.
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.
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.
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.
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.
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“ 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.
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