Scott Dickens von Microsoft demonstriert in dieser Session, was Web-Developer wissen müssen, um Metro-Apps zu bauen: What Web Developers Need to Know When Building Metro Style Apps. Witziger Einstieg mit Scott´s erster Webseite “ISDS” aus 1996 (s.u.) – was für eine Evolution hin zu modernen Websites. Das Session-Ziel: Zeigen, wie man “very powerful websites/metro apps in HTML5” bauen kann.
Erstes Metro-Beispiel: Die Stock-App aus Win8 Release Preview.
Metro-Apps haben ein sehr klares Design (und keinen Browser-Frame herum). 
App-Architektur:
In Client-Apps läuft der Code am Client, in HTML und Javascript (im Gegensatz zum serverseitigen ASP.NET).
Packages:
Die Tools: Visual Studio Express. Scott erstellt eine neue Javascript “Blank app” und zeigt den Designer der package.appxmanifest Datei.
Für Metro-Apps muss kein Installer, kein .MSI Paket erstellt werden. Alle Pakete werden signiert (beim ersten Starten von Visual Studio erhält der Developer mit seiner LiveId ein Zertifikat). Code wird zur Laufzeit ausgeführt, daher neutral:
Ausgeführt wird das Paket mit dem erstellten PowerShell Script:
Host:
Die Metro-App läuft dann in IE10 – mit denselben Fähigkeiten wie eine Website. Aber natürlich gibt es ein paar Unterschiede: Der Frame (URl-Adresse, Zurück und Weiter-Buttons, Favoriten, etc). Die Tabs sind ebenfalls entfernt. Ein neuer Host ersetzt diese Komponenten, sozusagen: Ein einziges Fenster. Keine PlugIns wie Silverlight, Flash, etc. Es gibt somit auch keinerlei Browser-Inkompatibilitäten, Legacy, etc. Der Host kommt mit dem OS.
Natürlich sind aber alle HTML5-Funktionen verfügbar. Zur Demo wird gleich mal das HTML5-Beispiel “Touch Effects” von ie.microsoft.com verwendet (und der <body> in der neuen VS-Projektseite default.html eingesetzt und demo.js sowie die Bilder eingebunden ) – es läuft als Metro-App.
Tipp: Ein Dokument beschreibt die Schritte, um eine Website in eine Metro-App zu konvertieren (siehe Bild):
Windows.*
Scott zeigt danach das FilePicker Sample aus dem SDK und in der VS Javascript Console das Javascript “Windows”-Objekt mit allen (neuen) Methoden. Nur JS, kein CodeBehind.
Eigener Code läuft innerhalb der App. Für externen Code: “Use iframes for untrusted content” – dieser kann nicht in der Browser Runtime ausgeführt werden (kein Windows.*). Zwischen ms-appx:///website.html (App) und ext. Code können aber Nachrichten ausgetauscht werden (“post message”).
Siehe dazu SDK Mashup-Beispiel mit zwei iFrames (Austausch über HTL DOM funktioniert natürlich auch – Das ist aber gefährlich: zur Laufzeit folgt ein Exception-Fehler im Debugger, wenn zB. scripts im eingesetzten Element enthalten ist: Scripts werden entfernt.)
Fehlerbehandlung:
BTW: In IE JS Fehler-Debugging einschalten: sehr viele Websites liefern dann Javascript-Exceptions – mal ausprobieren, ist schon fast erstaunlich…
Beim Starten der eigenen Metro-app aus VS wird der Debugger zum Browser attached. Der JS-Debugger kann die Symbole auflösen und springt zum Fehler. Wenn die App installiert ist wird die App bei einem unhandled Error sofort geschlossen! Daher: Try Catch verwenden!!
Hier ein paar Empfehlungen: iframe verwenden und somit fremde Scripts isolieren.
States:
WinRT liefert keine Browser-Plattform – sondern eine App Plattform! Eine App läuft anders als eine Website. Es gibt verschiedene Zustände (states): Running, suspending, resuming, terminating.
Windows liefert Notifications beim Eintritt in einen state – somit kann noch reagiert werden. Apps sollten den Zustand merken. Beispiel: Weather App: Ort wechseln, App via Task Manager beenden, App neu starten: Es folgt nicht – wie erwartet – der letzte Ort, sondern der erste Ort. Das macht die Weather App falsch. Somit: Preserve the properties when entering states.
LOB:
Line of business Apps sollten diese Funktionen verwenden/eingebaut haben:
Der Schritt vom Website-Developer zum Metro-App Developer ist nicht so groß.
Viel Spaß mit Metro-Style-Apps!
Autor: Toni Pohl