Metro: Wie die Golem.de-App für Windows 8 entstanden ist
Die neue, für Touchbedienung optimierte Metro-Oberfläche für Windows 8 basiert auf der neuen Windows Runtime (WinRT), einem komplett neuen API zur Entwicklung von Windows-Apps für unterschiedliche Hardwarearchitekturen. Schließlich läuft Windows 8 auf x86- und ARM-Prozessoren. Wir haben uns das neue API aus der Perspektive eines Webentwicklers angesehen und eine Windows-8-App für Golem.de entwickelt.
Sie zeigt die aktuellen Artikel von Golem.de in einer fast endlosen Übersicht im Metro-Stil an. Die Artikel selbst werden, ebenfalls im neuen Metro-Stil, in mehreren Spalten dargestellt, einschließlich Videos und Bildergalerien. Letztere werden auf Klick geöffnet, mit einem Wisch geht es dann jeweils zum nächsten Bild.
Warum eine App für Windows 8?
Apps für Windows 8 lassen sich komplett mit Webtechnik wie HTML, CSS und Javascript erstellen. Und so ist die App aus unserer Sicht nicht mehr als eine alternative Ansicht der Webseite, ähnlich wie smartphone- und tabletoptimierte Varianten von Golem.de. Dennoch handelt es sich um eine native App für Windows 8.
Bei der Entwicklung der App ging es uns auch darum, mehr über Windows 8 und Microsofts komplett neuen Ansatz zu lernen. Microsoft hat uns bei der Entwicklung unterstützt: Wir haben das Angebot der Darkside Bakery(öffnet im neuen Fenster) genutzt, ein von Microsoft temporär betriebenes Co-Working-Loft in Berlin. Im Mai und Juni 2012 fanden darin regelmäßig technische Vorträge zur WinRT-Programmierung statt, und täglich haben erfahrene Microsoft-Angestellte ihre Hilfe bei der Entwicklung angeboten, kostenlos und offen für jeden. Auch nach der Markteinführung von Windows 8 soll es entsprechende Schulungsangebote(öffnet im neuen Fenster) bundesweit geben.
Im Folgenden wollen wir einen Einblick in die bei der Entwicklung der App gewonnenen Erkenntnisse geben.
Die Windows Runtime
WinRT unterstützt Sprachen wie C++, C#, VB.net und Javascript direkt. Dadurch lassen sich Apps für Windows 8 komplett mit Webtechnik wie HTML, CSS und Javascript entwickeln.
Microsoft versucht mit dem neuen Ansatz einerseits, modernen Paradigmen (zum Beispiel Klassenorientierung, Sandbox-Prinzip und asynchrone Programmierung) Rechnung zu tragen, andererseits soll ein Gegengewicht zum Funktionen- und Parameter-Wildwuchs(öffnet im neuen Fenster) des Win32-API geschaffen werden, der nicht nur Microsoft zu umfangreichen Zusatzschichten wie dem MFC und den Windows Forms inspirierte – erinnert sich noch jemand an Borlands OWL(öffnet im neuen Fenster) und VCL(öffnet im neuen Fenster)?
Mit WinRT kommt aber noch ein weiteres Konzept ins Spiel, das den Gedanken von COM(öffnet im neuen Fenster) endlich mal elegant umsetzt: Projections. Damit soll das WinRT-API möglichst einfach in jeder beliebigen Programmiersprache nutzbar sein – und vor allem sollen ohne Verzögerung Ergänzungen des API in der jeweiligen Sprache bereitstehen. Bisher – das gilt nicht nur für Windows – werden APIs und Systembibliotheken zumeist durch C-basierte Wrapper in die jeweilige Programmiersprache eingebunden: Wrapper übersetzen die verwendeten Datentypen und rufen die jeweilige Systemfunktion auf. Teils erfolgt der Bau der Wrapper per Hand, teils automatisiert. Projections ersetzen das durch einen vollautomatisierten Vorgang, der Compiler oder Interpreter einer Sprache muss lediglich einen COM-artigen Mechanismus unterstützen, um das WinRT-API zu nutzen. Eine entsprechende Erweiterung hat Microsoft unter anderem in seine Javascript-Engine Chakra integriert. Der Implementierung in weitere Sprachen will Microsoft wohl nicht entgegenstehen.
Javascript und HTML
In Javascript steht durch den Projections-Mechanismus also das vollständige WinRT-API zur Verfügung – und zwar stets die beim Nutzer aktuell installierte Version, nicht diejenige, die der Entwickler beim Erstellen der App installiert hat.
Die mit Javascript erstellten Apps laufen nicht etwa innerhalb einer Internet-Explorer-Instanz, sondern sind tatsächlich eigenständige Programme. Es ist korrekt, von "nativen" Apps zu sprechen, auch wenn der Javascript-Code erst auf dem Zielsystem von der Javascript-Engine nach dem JIT-Prinzip kompiliert wird und nicht schon vom Entwickler, wie es bei C# und C++ der Fall ist.
Und noch mehr Unterstützung
Für komplexere Anwendungen macht reines Javascript ohne weitere Unterstützung wenig Spaß. Die Bibliothek Windows Library für Javascript(öffnet im neuen Fenster) (WLJS) enthält Sprachergänzungen, UI-Widgets und Klassen zur Datenverwaltung, wie sie erforderlich sind, um typische Webanwendungen zu erstellen. Es handelt sich um eine klassische Javascript-Bibliothek: Wer mit ExtJS beziehungsweise Sencha(öffnet im neuen Fenster) oder YUI(öffnet im neuen Fenster) vertraut ist, wird sich schnell heimisch fühlen.
Die Bibliothek enthält vor allem auch Elemente, um eine Oberfläche gemäß der UI-Vorgaben von Microsoft zu erstellen, denn Microsoft macht bei Apps keine Abstriche bei den Anforderungen, nur weil es sich um eine Javascript-App handelt. In der Praxis ist in der Handhabung auch kein Unterschied zwischen einer Javascript-App und C#-basierten Apps festzustellen.
Es ist kein Problem, auch andere Javascript-Bibliotheken zu verwenden, wie zum Beispiel jQuery. Der Entwickler muss lediglich darauf achten, diese mit ins Programmpaket zu packen, da eine Einbindung von einer anderen Quelle aus Sicherheits- und Geschwindigkeitsgründen nicht zulässig ist.
Und HTML?
WinRT propagiert eine Trennung von Code und der formalen Beschreibung der Anwendungsoberfläche: Bei Javascript liegt die Nutzung von HTML nahe (C# verwendet dafür XAML). In der Praxis kann eine Anwendung natürlich auch HTML im Code erzeugen und in ein existierendes HTML-Dokument einhängen. Bei DOM-Operationen im HTML-Dokument sind keine Besonderheiten zu beachten, die Javascript-Engine hält sich an die W3C-Standards.
Die Golem.de-App
Der folgende Teil soll keine Anleitung für eine Nachprogrammierung der Golem.de-App darstellen und ist erst recht kein vollwertiger Kurs für Windows-8-Programmierung. Wir wollen lediglich einen kleinen Einblick geben.
Die App besteht derzeit aus vier sichtbaren Bestandteilen. Praktisch handelt es sich dabei tatsächlich um vier HTML-Seiten mit je einer dazugehörigen Javascript-Datei:
- die Übersichtsseite für einen Überblick über die Artikel
- die Artikelseite, die einen Artikel darstellt
- die Suchseite, die aufgerufen wird, wenn das Such-Charm aufgerufen wird
- die Galerieseite, welche die Bildergalerie eines Artikels darstellt, sofern vorhanden
Dazu kommen noch statische HTML-Seiten für das Impressum und die Datenschutzerklärung sowie eine "unsichtbare" Seite, welche die überall verfügbare App-Navigationsbar bereitstellt. Hinzu kommen noch je eine Javascript-Datei für die Verwaltung des App-Lebenszyklus und Hilfsfunktionen zur Navigation sowie eine Datei für Javascript-Klassen zum Datenhandling. Die letzten beiden werden in jede der HTML-Seiten eingebunden.
Die Übersichtsseite
Die Übersichtsseite verwendet ein WinJS.UI.Listview-Widget(öffnet im neuen Fenster). Wird dem Listview eine Datenquelle übergeben, so stellt es die vom Win8-Startbildschirm bekannte horizontal scrollende Liste dar. Gibt es Änderungen an der Datenquelle – zum Beispiel weil Einträge hinzugefügt wurden -, dann aktualisiert sich der Listview automatisch.
Wie ein einzelnes Element in dieser Liste dargestellt wird, ist dem Programmierer überlassen. Die einzige Einschränkung: Die Größe muss einem festen Raster folgen. In der Golem.de-App ist das Raster 340 x 140 Pixel. Elemente können in diesem Raster auch größer dargestellt werden, sie müssen aber in das Raster passen, also einem Vielfachen eines Rasterelements zuzüglich der Zwischenräume entsprechen. Der große Eintrag am Anfang der Übersichtsseite entspricht deshalb den Abmaßen 340 x 290 Pixel.
Wer unterschiedliche Größen im Raster nutzen will, kommt nicht umhin, eine Callback-Funktion für das Widget zu schreiben, um ein Element mit der gewünschten Größe zu erzeugen. Wer darauf verzichtet, kann weitgehend die komplette Verknüpfungslogik von Daten und Widget als Teil der Templates im HTML unterbringen. WLJS bringt dafür entsprechende Funktionen mit.
Die Datenquelle für die Liste ist im leichtesten Fall ein WinJS.Binding.List-Objekt(öffnet im neuen Fenster), dem ein Array mit den darzustellenden Daten übergeben wird. Damit Nutzer in der Golem.de-App durch alle Artikel scrollen können, ohne dass immer alle geladen werden müssen, was den initialen Ladevorgang sehr langsam machen und entsprechend viel Speicher brauchen würde, haben wir eine eigene Version der Datenquelle geschrieben. Diese lädt immer nur eine begrenzte Anzahl an Einträgen vom Server. Damit der Listview die Quelle nutzen kann, muss sie das Interface WinJS.UI.VirtualizedDataSource(öffnet im neuen Fenster) implementieren.
Im Zusammenhang mit der Implementierung wird auch das ressourcenschonende Verhalten des Listview deutlich: Es wird nur ein Bruchteil der Einträge tatsächlich gerendert. Nicht sichtbare Elemente werden aus dem Speicher entfernt und bei Bedarf neu geladen. Deshalb wird der Listview auch nicht langsamer, selbst wenn er vermeintlich zehntausende Einträge enthält.
Suchen und Anzeigen
Die Suchseite ist ähnlich aufgebaut wie die Übersichtsseite, inklusive einer eigenen Klasse für die Kapselung der Suchabfrage auf dem Server. Ansonsten ist die Seite etwas einfacher aufgebaut: Alle Elemente werden im Raster gleich groß dargestellt.
Der wichtigste "Trick" für die Einbindung der Suchseite ist die Verknüpfung mit dem Suchen-Charm. Dazu muss in der Manifest-Datei der App die "Suchen"-Deklaration aktiviert werden und wir müssen die Callback-Methode anmelden. Diese wird von Windows mit dem zu suchenden Text als Parameter aufgerufen.
Die Galerie
Die Galerie ist eigentlich nur ein großes Widget: WinJS.UI.FlipView(öffnet im neuen Fenster). Es zeigt aus einer Datenquelle genau einen Eintrag an. Zwischen den Einträgen kann entweder per Wischgeste oder über die Anfasser links und rechts gewechselt werden. Das Flipview hat eine feste Größe und die Bilder werden auf diese Größe skaliert, wenn sie größer als der verfügbare Platz sind.
Bei der Datenquelle gab es keinen Grund, mehr Code zu schreiben als nötig. Die URL und Überschriften der Bilder werden in einem Array zusammengefasst und in ein WinJS.Binding.List verpackt.
Die Artikelseite
Auch die Artikelseite ist recht einfach aufgebaut. Der HTML-Code des Artikels wird vom Server geladen und in die Artikelseite eingefügt. Aufwendig wird es erst, wenn der Artikel da ist. Das DIV-Element, welches die Galerievorschau im Artikel umgibt, wird mit einem Listener versehen, der die Galerieseite aufruft. Analog erfolgt das mit Links im Text, die auf andere Golem.de-Artikel verweisen. Damit diese auch innerhalb der App geöffnet werden, müssen sie auf einen internen Aufruf umgebogen werden. Eine weitere Anpassung betrifft Tabellen im Artikel. Sie lassen sich schlecht in das schmale Textlayout pressen. Deswegen tritt an ihre Stelle ein Platzhalter, der auf Klick die eigentliche Tabelle über dem Text anzeigt und so keine Rücksicht auf das Layout nehmen muss.
Das mehrspaltige Layout des Textes wird im Übrigen rein per CSS erzeugt: Die HTML-Render-Engine von Win8 unterstützt das Multi-Column-Layoutmodul(öffnet im neuen Fenster) von CSS3 vollständig.
Unsichtbar
Im Hintergrund sind noch etwas weiterer Javascript-Code und auch eine "unsichtbare" HTML-Datei am Werk.
In dieser HTML-Datei wird lediglich die sogenannte Navigationsbar definiert. Sie erscheint per Rechtsklick oder über eine Wischgeste vom oberen oder unteren Rand nach innen. Derzeit enthält die untere Leiste nur einen einzelnen Button zur Aktualisierung der Übersichtsseite, in der oberen einen Button, um zur Übersichtsseite zurückzukehren. Die Aufteilung entspricht den Styleguide-Vorgaben: Die untere Leiste soll seitenbezogene Aktionen anbieten, oben Navigationselemente.
Ebenfalls in der Datei enthalten ist die Einbindung des Javascripts zur Behandlung der Lifecycle-Events der App. Diese Events und ihre Behandlung verdienen eine gewisse Aufmerksamkeit, schließlich kennt WinRT nicht nur Programmstart/-ende, sondern kann auch Apps pausieren.
Sonstige Details
Damit ein Artikel geteilt werden kann, war es lediglich notwendig, eine Callback-Funktion zu definieren und anzumelden. Sie muss ein vordefiniertes Array mit den zu teilenden Daten zurückliefern. Der Zurück-Button taucht zwar an verschiedenen Stellen auf, dessen Funktion ist aber zentral definiert – und er kehrt tatsächlich immer zur letzten Seite zurück. Die kleine und die große Kachel der Golem.de-App sind normale PNGs. Das gilt auch für die Grafik beim Programmstart.
Wie es weitergeht
Die App ist unser erster Ausflug abseits der Browserwelt, auch wenn im Hintergrund vor allem serverseitig Altbekanntes arbeitet. Wir sind gespannt, wie unsere Leser die App annehmen werden. An Feedback – von dem wir auch die konkrete Weiterentwicklung abhängig machen wollen – sind wir stets interessiert.
Die nächsten Tagen und Wochen werden wir uns noch der Optimierung der Artikeldarstellung widmen. Die notwendigen CSS- und Darstellungsanpassungen haben sich als umfangreicher erwiesen als erwartet. Das liegt an den vielfältigen Möglichkeiten unserer Redakteure, einen Artikel per HTML zu gestalten. Wir erwarten, dass so mancher Artikel fehlerhaft in der App dargestellt wird, und werden versuchen, Darstellungsfehler so schnell wie möglich zu korrigieren.
Doch dabei soll es nicht bleiben. Einen Leserwunsch haben wir bereits umgesetzt: die Livekachel-Funktion; auf unserer eigenen Liste stehen noch Funktionen wie die Möglichkeit, Artikel offline zu lesen oder Artikel zum Lesen vorzumerken und natürlich die Integration der Kommentare.
Hinweis: Die Livekachel-Funktion ist Bestandteil eines App-Updates, das vorraussichtlich ab dem 28.8.2012 verfügbar ist.
- Anzeige Hier geht es zu JavaScript: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.