Windows Store Apps entwickeln mit HTML5 und JavaScript

Felix Rieseberg

Published by Microsoft Press Deutschland

Einleitung

Apps dominieren den Softwaremarkt und verändern die Grundparameter von Softwareentwicklung und –anwendung nachhaltig. Mittlerweile besteht kein Zweifel mehr daran, dass das digitale und zentralisierte Vertriebsmodell von Nutzern angenommen und gar eingefordert wird. Die Paradigmenverschiebung steht nicht alleine dar: Auch in puncto Benutzeroberflächen, Bedienkonzepten und Nutzungsverhalten sind erdrutschartige Verschiebungen zu beobachten, die den Consumer-Markt längst fest im Griff haben und in immer größer werdenden Schritten auch den Enterprise-Sektor erfassen. Zu nennen wären hier z.B. eine größere Bandbreite an Geräten, Bildschirmgrößen, Rechenleistung und Eingabemethoden.

Microsoft hält zahlreiche dieser Neuausrichtungen von Hardware und Software für nachhaltig und für so wichtig, dass zahlreiche Kernkonzepte des hauseigenen Betriebssystems Windows auf den Prüfstand gestellt wurden. Dieses Buch wird durchgehend auf die Änderungen in den Konzepten hinweisen, aber alleine die Tatsache, dass ausgerechnet Windows – der Name bedeutet bekanntlich nichts anderes als Fenster – in der neuen, für Apps konzipierten Oberfläche gar nicht mehr über Fenster verfügt, spricht bereits Bände.

Viele dieser Änderungen versetzen Entwickler, die Erfahrung mit Webtechnologien haben, in eine gute Position. Ein Großteil der Paradigmenverschiebungen haben mit einem Mehr an Vielfalt zu tun, die für Webentwickler nicht zwangsläufig neu ist. Während sich die App-Pioniere auf iOS jahrelang auf eine einzige Auflösung verlassen konnten, waren Webentwickler schon seit Jahren mit der neu aufkeimenden Vielfalt vertraut. Gleichzeitig gewinnen HTML und JavaScript mit immer schneller werdenden JS-Engines und dem ausgebauten HTML-Standard aufgrund ihrer Plattformunabhängigkeit immer mehr an Bedeutung.

Windows 8 integriert JavaScript und HTML als eine der möglichen Technologiefundamente, um Apps für das System zu entwickeln. Dabei handelt es sich nicht wie bei anderen Plattformen um die einfache Anzeige einer Webseite in einem seelenlosen App-Container, sondern in der Tat um eine mit JavaScript gesteuerte Interaktion mit dem Betriebssystem sowie dessen Diensten, Schnittstellen und kontrollierter Hardware. Dieses Buch wird noch näher erläutern, welche cleveren Schritte Microsoft hier gegangen ist. Festhalten kann man aber schon einmal, dass JavaScript nahezu gleichberechtigt neben den breitschultrigen Partnern C++ und C# steht.

Da Sie dieses Buch in Händen halten und über den ersten Absatz hinausgelesen haben, muss ich Sie möglicherweise nicht mehr von den großen Chancen überzeugen, die sich mit Windows 8 für JavaScript-Entwickler eröffnen. Dennoch: Windows ist das mit Abstand am stärksten verbreitete Betriebssystem weltweit. Der mit Windows 8 integrierte App-Marktplatz erlaubt es einzelnen Entwicklern und kleinen Teams, auf einen Schlag ihre Software auf dem ganzen Globus zu vermarkten. Gleichzeitig besteht eine umfangreiche Codekompatibilität mit allen anderen HTML5/JavaScript-Plattformen, inklusive der vielen beeindruckenden Komponenten, die die Community im Netz unter offenen Lizenzen bereitgestellt hat. All die coolen Dinge, die Sie in den letzten Jahren mit Frameworks wie jQuery oder Dojo gesehen haben, können auch in einer Windows 8 App verwendet werden. Bei der Beurteilung der Chancen für Windows 8 Apps ergeben sich gleich zwei Pluspunkte: Zunächst handelt es sich um ein etabliertes System mit einem gigantischen Markt. Gleichzeitig wird der Entwicklungsaufwand in der Regel eher vergleichsweise gering ausfallen.

Dieses Buch versteht sich als Einführungswerk für all jene, die bereits ein wenig Erfahrung mit HTML5 und JavaScript haben (dennoch enthält es für beide Technologien eine eigene, kurze Einführung), und hilft Ihnen auf diese Weise bei der Umsetzung und Vermarktung eigener App-Ideen.

0.1 Windows 8 Apps mit HTML5 und JavaScript

In insgesamt 14 Kapiteln werden Schritt für Schritt die relevanten Themen rund um die App-Entwicklung mit Windows 8 behandelt. Das betrifft zunächst die technische und konzeptionelle Plattform, auf der Microsoft mit Windows 8 aufbaut. Hier werden die Kernkonzepte, die wesentlichen Paradigmenverschiebungen sowie die Integration von JavaScript in das System erläutert. Ebenfalls Teil der einführenden Kapitel ist eine Auffrischung der JavaScript-Kenntnisse – ein Kapitel, das sich vor allem für all jene lohnt, die bislang hauptsächlich kleinere jQuery-Anweisungen schreiben mussten. Anschließend wird ein Überblick über die wesentlichsten und umfangreichsten Änderungen im und rund um den HTML5-Standard gegeben, dabei neue Schnittstellen und neue Layoutkonzepte beleuchtet – nicht, dass noch jemand auf die Idee kommt, Layouts mit Tabellen zu erstellen.

Sind die Fundamente gelegt, wird mit der Entwicklung begonnen: Die verbleibenden zehn Kapitel beschreiben in thematischen Blöcken Theorie und Praxis der App-Entwicklung. Die Kapitel bestehen sowohl aus einem theoretischen Teil, der einen Überblick über die Schnittstellen, Objekte und Vorgehensweisen gibt, sowie einem praktischen Teil, in dem die besprochenen Dinge umgesetzt werden. Ähnlich wie Medizinstudenten an einem leblosen Körper mehr Operationen durchführen, als ein lebender Mensch vertragen würde, erstellt dieses Buch so Schritt für Schritt die Beispielanwendung »Eierlegende Wollmilchsau«, welche nicht als leuchtendes Exemplar für eine gute App angesehen werden sollte, sondern ein hilfreiches Objekt ist, um die beschriebenen theoretischen Elemente in der Praxis auszuprobieren.

Die Beispiele aus dem Buch und die gesamte App können Sie sich hier herunterladen:

www.microsoft-press.de/support/9783866455672

msp.oreilly.de/support/2358/783

Ebenfalls Bestandteil der praktischen Abhandlung sind einige Überlegungen rund um die Vermarktung der eigenen App und den Einsatz verschiedener kommerzieller Modelle, um mit der App Geld zu verdienen.

Doch noch bevor groß Geld verdient werden kann, muss die Entwicklungsumgebung eingerichtet werden. Ein Großteil der Leser dieses Buchs wird vermutlich im Zuge des Interesses an der Windows 8-Entwicklung bereits in die Tools geblickt haben – diejenigen, die auf diesen Schritt bislang verzichtet haben, sollen aber nicht alleine zurückgelassen werden.

0.2 Die Entwicklungsumgebung

Die Entwicklung von Apps für Windows 8 erfolgt mit einer ganzen Palette an Tools, die in drei großen Paketen kommen: erstens Visual Studio für die technische, codezentrierte Entwicklung, das Debugging und die Paketierung von Apps; zweitens Blend für Visual Studio für eine benutzeroberflächenzentrierte Entwicklung mit Fokus auf Gestaltung; drittens das Windows Software Development Kit (SDK), welches die für die Windows 8-App-Entwicklung notwendigen Bibliotheken und Tools für Visual Studio und Blend mitbringt.

Visual Studio kann auf zahlreiche Wege und in unterschiedlichen Geschmacksrichtungen bezogen werden – zu nennen wären etwa die von Microsoft präferierten MSDN-Abonnement-Modelle für die kostenpflichtigen und leistungsstärkeren Versionen, die auch kostenfrei über Sponsoring-Programme wie BizSpark (für Startups) und DreamSpark (für Studierende und Bildungseinrichtungen) bezogen werden können. Wer nicht in eine kostenpflichtige Version investieren möchte und gleichzeitig zu keiner der unterstützten Gruppen gehört, muss nicht zwangsläufig Geld ausgeben – Microsoft ist sich durchaus der Bedeutung von Apps für die Zukunft von Windows bewusst und hat extra für Windows 8 eine kostenfreie Version von Visual Studio veröffentlicht, die für die Entwicklung von Apps mehr als ausreichend gewappnet ist. Es gibt einige Einschränkungen, die Erweiterungen und für größere Entwicklungsteams interessante Features betreffen, aber keiner der in diesem Buch beschriebenen Vorgänge kann mit der Version Visual Studio Express 2012 for Windows 8 nicht durchgeführt werden. Es ist zu betonen, dass die Entwicklung einer App mit den kostenpflichtigen Varianten nicht auf magische Art einfacher wird – dem Entwickler werden nur mehr Tools an die Hand gegeben, die gerade fortgeschrittenen und Berufsentwicklern den Kostenaufwand wert sein könnten.

Tools und SDK herunterladen

Wichtige Voraussetzung ist selbstverständlich Windows 8. Sollten Sie MSDN-Abonnent sein, so finden Sie die Vollversion in Ihrem Mitgliederportal; Nicht-Mitglieder können für den Einstieg auch mit der Evaluierungsversion glücklich werden. Sie können wahlweise in einer Suchmaschine Ihrer Wahl nach »Windows 8 Evaluation for Developers« suchen oder direkt die Webseite http://msdn.microsoft.com/de-de/evalcenter/jj554510.aspx aufrufen, welche den Download bereitstellt.

Als MSDN-Abonnent sollten Sie Ihren Aufenthalt im Mitgliederbereich auch direkt nutzen, um Visual Studio in Ihrer präferierten Version herunterzuladen und zu installieren. Wer keinen Zugriff darauf hat und über keine kostenpflichtige Version verfügt, wird feststellen, dass das extra zu installierende Software Development Kit bei Nicht-Vorhandensein von Visual Studio auf dem System automatisch die kostenfreie Version Visual Studio Express 2012 for Windows 8 zusammen mit Blend for Visual Studio installiert. Das SDK können Sie kostenfrei unter der Adresse http://msdn.microsoft.com/de-de/windows/apps/br229516.aspx beziehen – alternativ wird Sie jede Suchmaschine mit dem Begriff »Windows 8 SDK« an die richtige Stelle führen.

Sind alle Tools und das SDK installiert, sind Sie hinreichend ausgerüstet, um sich in die Windows 8-Entwicklung zu stürzen. Ich wünsche Ihnen viel Freude bei der Entwicklung – eigenen Code arbeiten zu sehen, lässt gerade mit all den Neuerungen, Features und handwerklichen Kunstgriffen in Windows 8 noch jeden Entwickler schelmisch grinsen.

Felix Rieseberg

http://www.felixrieseberg.com

0.3 Korrekturen und Kommentare

Es wurden von Verlagsseite alle Anstrengungen unternommen, um die Korrektheit dieses Buches zu gewährleisten. Microsoft Press bietet Kommentare und Korrekturen für seine Bücher im Web unter http://www.microsoft-press.de/support/9783866455672 an. Hier werden Sie auch zu gegebener Zeit Hinweise auf relevante Neuerungen finden, die mit Windows 8.1 Einzug halten.

Wenn Sie Kommentare, Fragen oder Ideen zu diesem Buch haben, senden Sie diese bitte per E-Mail an mspressde@oreilly.de. Bitte beachten Sie, dass über diese Adresse kein Support für Microsoft-Produkte angeboten wird.

Kapitel 1. Die Plattform Windows 8 im Überblick

Windows 8 ist, ohne jeden Zweifel, der größte Entwicklungsschritt des populären Betriebssystems seit dem Wechsel von DOS zu Windows 95. Microsoft wagt diesen Sprung von einem mächtigen Fundament aus: Mit mehr als 600 Millionen verkauften Lizenzen für Windows 7 und mehr als 550 Millionen Menschen, die sich regelmäßig bei Windows Live anmelden, blickt das Unternehmen keinesfalls verzweifelt in die Zukunft. Microsoft ist offensichtlich stolz auf die Erfolge, die der klassische Windows-Desktop sowohl in Unternehmen als auch bei Heimanwendern erreichen konnte. Windows 8 verfügt über zwei Herzen, die in seiner Brust schlagen: Der Desktop, wie man ihn aus Windows 7 kennt, ist weiterhin vertreten. Man gibt sich viel Mühe, regelmäßig zu betonen, dass nahezu sämtliche Applikationen, die unter Windows 7 laufen, auch noch unter Windows 8 einwandfrei funktionieren – im Idealfall sogar ein bisschen schneller, als es unter Windows 7 der Fall war. Gleichzeitig bringt Windows 8 eine komplett neue Oberfläche und Entwicklungsumgebung mit, in der die sogenannten »WinRT Apps« leben, auch als »Windows Store Apps« bezeichnet. Der Begriff der »WinRT App« hat den Ursprung in dem neuen API-Set, das für die neuartigen Apps verantwortlich ist – und von seinen Schöpfern WinRT genannt wurde. Man muss kein Experte sein, um schon beim ersten Blick festzustellen, dass die neue Welt, die ohne Start-Button, Taskleiste und namensgebende Fenster (Windows) auskommt, ein radikaler Schritt ist. Woher kommt die Motivation, zusätzlich zum klassischen Desktop eine Umgebung einzuführen, die so fundamental neu erscheint?

Der Softwarekonzern hat für die Zukunft der gesamten IT-Branche insgesamt vier Trends identifiziert, die zumindest in Redmond als so einschneidend angesehen werden, dass sie die Art und Weise, wie Menschen mit Computern arbeiten, nachhaltig verändern werden – und deshalb erfordern, dass sich Windows mit der neusten Version auf diese Änderungen vorbereitet.

1.1 Vier Trends für die Zukunft der IT

Vier Punkte sind wesentlich: erstens die Vielfalt der Gerätelandschaft, zweitens ein neues Verständnis von Mobilität, drittens der Siegeszug von Touch und viertens das durch Apps verschobene Verständnis von Applikationen und Softwarelösungen. Dieser Abschnitt wirft einen Blick auf diese vier Punkte und bespricht gleichzeitig exemplarisch einige der wichtigsten Schritte, die Microsoft unternommen hat, um den genannten Entwicklungen der Branche zu begegnen.

Gerätevielfalt

Noch vor wenigen Jahren war die Welt für Entwickler simpler. Viele der Leser dieses Buchs werden sich noch an jene Zeit erinnern, in denen ein Webentwickler mit gutem Gewissen davon ausgehen konnte, dass ein Großteil der Besucher einer Webseite über einen Bildschirm mit einer Auflösung von 1024 × 768 Pixeln und höher verfügen wird. Maus und Tastatur waren die primären Eingabegeräte. Man hat zwar voraussagen können, dass Hard- und Software immer leistungsfähiger werden, war aber nicht darauf vorbereitet, dass die Entwicklung von mehr Leistung auf kleinerem Raum auch dazu führt, dass die Vielfalt der Geräte dermaßen explodiert. Wer heute über eine beliebige Computermesse schlendert, muss nach dem klassischen Personal Computer schon fast suchen – All-in-Ones, Convertibles, Netbooks, Tablet-PCs, Slates und Notebooks dominieren das Bild. Im Gesamtbild müssen Entwickler sich immer mehr auf eine große Vielfalt einstellen, die bereits bei Grundbausteinen eines Computers große potenzielle Unterschiede zum Vorschein bringt, ganz gleich, ob man sich Kennwerte wie Bildschirmgröße, Auflösung, DPI-Werte, Prozessorleistung, Prozessorkerne, Eingabemethode, Speicherplatz oder Nutzungsszenario ansieht.

Windows 8 reagiert auf diese Entwicklung mit einem Maßnahmenpaket, das den gewohnten Desktop weitestgehend unangetastet lässt, führt aber dafür in einer neuen Oberfläche bereits auf unterster Ebene Neuerungen ein. Während das bekannte Windows seit Jahren auf x86- und x64-Architektur lief, wird Windows mit der neusten Version auch erstmals auf ARM-Architektur laufen – zumindest mit der neuen Oberfläche. Die ARM-Architektur wurde bereits 1983 vom britischen Computerhersteller Acorn entwickelt, erlebte ihren echten Aufschwung aber erst zusammen mit dem Siegeszug des Smartphones. Der Chip ist im Vergleich zu x86- oder x64-Prozessoren vergleichsweise schwach, jedoch erlaubt die Architektur ein ausgesprochen stromsparendes Design. Für Mobilitätsszenarien ist die Architektur so erfolgreich, dass 2012 sämtliche modernen Smartphone-Betriebssysteme ausschließlich auf ARM laufen oder ARM unterstützen.

Auf die großen Unterschiede in puncto Leistung, die durch die Einführung von ARM sogar noch vergrößert werden, reagiert die WinRT-Umgebung mit strikter Leistungskontrolle, die sich vollkommen von dem bekannten Szenario unterscheidet: Innerhalb der WinRT-Oberfläche laufen grundsätzlich nur Anwendungen, die gerade im Vordergrund sind. Das klassische Multitasking-Management, bei dem der Anwender in der Taskbar sehen kann, welche Anwendungen gerade laufen (und welche nicht), ist so in der WinRT-Oberfläche nicht mehr existent.

Elegant erscheint die Lösung, die für das Problem der unterschiedlichen Bildschirme gefunden wurde. Das Problem ist, dass Bildschirme nicht einfach nur kleiner und größer werden – auch die Anzahl der Pixel, die ein Bildschirm auf einem Quadratzentimeter abbildet, variiert stärker. Schön zu sehen ist dieser Effekt beim iPhone: Das iPhone verfügt zwar stets über die gleiche physische Bildschirmgröße, unabhängig davon, ob es mit einem Retina-Display ausgestattet ist oder nicht. Jedoch weist das Retina-Display eine Auflösung auf, die doppelt so hoch ist wie jene der alten iPhone-Generationen. Windows-Entwickler, die es nicht nur mit genau einem Gerät zu tun haben, stehen vor einer unlösbaren Aufgabe: Selbst wenn die eigene Anwendung unterschiedliche Auflösungen unterstützt, so hat man noch nicht berücksichtigt, wie groß – physisch betrachtet – etwa eine Schaltfläche oder ein Text sein sollte. Ein Bildschirm mit Full HD-Auflösung kann heute einen beliebigen Durchmesser zwischen 5 und 80 Zoll haben. Windows 8 ist in der WinRT-Oberfläche in der Lage, sich dynamisch an unterschiedliche Auflösungen und unterschiedliche DPI-Größen anzupassen. Entwicklern wird eine ganze Reihe von Werkzeugen an die Hand gegeben, die es ebenfalls erlauben, sich nur kurz mit Einstellungen aufzuhalten und in der eigenen App anschließend ein Layout zu nutzen, das sich selbstständig unterschiedlichen Bedingungen anpasst. Dadurch, dass es Entwicklern einfach gemacht wird, auf dieses Problem zu reagieren, kann Microsoft guten Gewissens im Windows Store verlangen, dass sämtliche Apps, die dort vertrieben werden sollen, auch für die wildesten Windows 8-Geräte gewappnet sind.

Ein neues Verständnis von Mobilität

Insbesondere Smartphones haben das Verständnis von Mobilität verändert. Noch vor wenigen Jahren war sich die Branche einig, dass »Mobilität« bedeute, dass ein Gerät von einem Ort ohne größeren Aufwand an einen anderen Ort transportiert werden könne. So war es nicht verboten, mehrere Kilogramm schwere Telefone oder Desktop-Gehäuse mit angeschweißten Tragegriffen als »mobil« zu bezeichnen. Dass einige der frühen Mobiltelefone bei keiner Airline als Handgepäck durchgehen würden, widersprach diesem Mobilitätsbegriff nicht – immerhin brauchte man keine Spedition und keine Techniker, um das Gerät von A nach B zu schaffen und am Zielort zu installieren.

Heute sieht die Sache etwas anders aus: Unzählige Geräte haben die ganze Branche dazu erzogen, Dinge nur noch dann als mobil zu bezeichnen, wenn der Nutzer diese problemlos unterwegs einsetzen kann. Dies hat einen massiven Einfluss auf die Szenarien, in denen Anwendungen verwendet werden: Als Entwickler einer E-Mail-App muss man damit rechnen, dass diese nicht nur in ordentlichen Büros, sondern auch in der Bahn, im Flugzeug kurz vorm Start oder gar mal schnell im Kino genutzt wird.

Windows 8 reagiert darauf mit neuen Features, die die Nutzung unterwegs erleichtern sollen – das betrifft beispielsweise eine bessere Unterstützung von Sensoren, wie man sie aus Smartphones kennt (GPS, SIM-Verbindungen, NFC etc.), oder die kleine, aber wichtige Möglichkeit, Verbindungen als »getaktet« zu markieren, damit Windows 8 mit dem Herunterladen von Updates wartet, bis wieder eine heimische Internetverbindung verfügbar ist. Gleichzeitig wurden umfangreiche Bedienkonzepte erarbeitet, die dafür sorgen sollen, dass sich Nutzer App-übergreifend schnell zurechtfinden und ohne größere Einarbeitungszeit oder Konzentration unmittelbar zu den gesuchten Inhalten kommen. Dieses Buch wird den User Interface- und User Experience-Konzepten ein ganzes Kapitel widmen, um die Vorgaben und Empfehlungen in gebührender Länge zu besprechen.

Der Siegeszug von Touch

Touch ist sicherlich eine der Neuerungen von Windows 8, die bei der Vorstellung des Betriebssystems am meisten diskutiert wurden. Blogs und Diskussionsforen waren gefüllt mit Meinungen, die Touch als überflüssige Spielerei abqualifizierten. Sicherlich hat niemand das Monopol darauf, die Zukunft vorauszusagen – es sei hier lediglich darauf hingewiesen, dass auch bei Einführung des iPhones von vertrauenswürdigsten Publikationen zu hören war, dass ein Gerät mit nur einem echten Button schon von Geburt an dem Tode geweiht sei. Microsoft geht fest davon aus, dass Touch in Zukunft immer mehr Nutzungsszenarien gewinnen wird – und auch für ernste Dinge jenseits von Angy Birds und Co. Maus und Tastatur vorzuziehen ist. Gleichzeitig ist anzunehmen, dass Maus und Tastatur die Branche noch eine ganze Weile begleiten werden – keiner der Touch-Advokaten suggeriert, dass komplexe Anwendungen wie Visual Studio oder Excel am besten ohne Tastatur bedient werden können.

Microsoft fährt deshalb einen zweigleisigen Ansatz: Der Desktop wurde zwar stärker für Touch optimiert, wird aber auch in Windows 8 nur im Ausnahmefall mit Touch besser zu bedienen sein. Für die neue Oberfläche wurde hingegen der Kampfschrei ausgegeben, dass sämtliche Apps so zu gestalten seien, dass sie sowohl mit Touch als auch mit Maus und Tastatur großartig bedient werden können. Diese Ansage ist keine allein stehende Forderung, sondern kommt im Paket mit allerlei Werkzeugen, die die Entwicklung von Touch-fähigen Apps erleichtern soll. Beispiele an dieser Stelle sind ein umfangreicher Emulator, mit dem auch auf klassischen Computern eine Touch-Bedienung simuliert werden kann, umfangreiche Empfehlungen und Vorgaben, die auf User Experience-Forschung basieren, sowie die volle Touch-Unterstützung sämtlicher mitgelieferten Controls.

Schaut man eine Ebene tiefer, findet man gar eine Vereinheitlichung der Eingabemethoden, die Maus und Touch als MSPointer (dazu gleich mehr) zusammenfasst. Warum ist das wichtig? Webentwickler, die während des Siegeszuges von iPhone und iPad Webseiten entwickelt haben, die auch auf diesen Geräten laufen sollten, haben vielleicht festgestellt, dass sämtliche Funktionen, die auf Maus-Events warten, nicht ausgeführt werden. So kann man mit dem iPad beliebig oft auch einen Button drücken – wenn dieser auf einen Mousedown- oder ein Click-Event wartet, passierte nichts. Durchaus zu Recht: Ein Gerät mit Touchscreen sollte in einer solchen Situation, ganz wie vom Standard vorgeschrieben, ausschließlich Touch-Events auslösen. Diese Situation führte dazu, dass einige Anwendungen für beide Szenarien entwickelt werden mussten – sowohl für Maus als auch für Touch. Windows 8 verwendet hingegen in der WinRT-Oberfläche systemweit MSPointer – ein Eingabeinterface, das es Entwicklern ermöglicht, ohne großes und ständiges Umdenken für beide Eingabemethoden gleichzeitig zu entwickeln. Die komplizierte Aufgabe, sowohl einen Rechtsklick als auch eine kleine Wisch-Geste nach unten zu verstehen, übernimmt dann das System – damit der Entwickler sich auf seine eigentliche App konzentrieren kann.

Ein neues Verständnis von Software – Apps

Die Applikationslandschaft bewegt sich immer stärker in eine Richtung, in der eine App nicht mehr per se die Lösung selbst ist, sondern eine Dienstleistung anbietet, die der Nutzer auf unterschiedliche Weisen in Anspruch nimmt. Es ist dieselbe Entwicklung, die dafür gesorgt hat, dass manche Webseiten als Web-Apps verstanden werden, weil die angebotene Dienstleistung über das reine Konsumieren von Informationen hinausgeht.

Das neue Verständnis von Apps, bei dem Nutzer keine vollwertige Softwarelösung erwarten, führt dazu, dass Nutzer sich ihr komplexes Nutzungsszenario aus mehreren Apps zusammenbauen – vergleichbar mit einer Art Applikations-Sushi. Einige Entwickler haben bereits darauf reagiert und vereinfachen proaktiv die Verkettung und Verbindung von einzelnen Apps. Eine Kamera-App tut beispielsweise gut daran, soziale Netzwerke wie Facebook oder Twitter zu integrieren, damit der Nutzer direkt aus der App heraus das geschossene Foto auch dort veröffentlichen kann. Die App könnte dem Nutzer darüber hinaus anbieten, die geschossenen Fotos direkt in einer Fotobuch-App bereitzustellen – wenn sich die Entwickler beider Apps verständigt haben, können die Daten direkt ausgetauscht werden. Üblicherweise werden diese Verkettungen über APIs (Application Programming Interfaces), also Schnittstellen, realisiert. Facebook und Twitter verfügen etwa beide über eine ausgesprochen gut dokumentierte Schnittstelle, die schnell in eine Anwendung eingebaut ist – was dazu führt, dass eine Vielzahl an Apps und Webseiten Facebook und Twitter integrieren. Diese Vorgehensweise hat jedoch massive Nachteile: Möchte der Entwickler möglichst viele potenzielle Verkettungsmöglichkeiten abdecken, müssen eine ganze Reihe an APIs eingebunden werden, wenn sie denn überhaupt verfügbar sind. Ebenso kann eine solche Herangehensweise zu einem Updatechaos führen: Jedes Mal, wenn der Anbieter einer API aktualisiert und anpasst, muss auch die eigene App entsprechend überarbeitet werden. Es ist offensichtlich, dass dies keine effiziente Methode ist, um dem Nutzer eine Verkettung der einzelnen Apps zu erleichtern.

Windows 8 bringt mit dem Teilen-Vertrag (Share Contract) ein Konzept mit, das die Verkettung innerhalb der WinRT-Oberfläche grundsätzlich standardisieren und vereinfachen soll. Das Prinzip ist simpel: Jede Anwendung meldet beim System an, welche Daten die App ausliefern und entgegennehmen kann. So müsste die Kamera-App aus dem Beispiel von vorhin bei Windows 8 lediglich anmelden, dass sie Bilddateien ausgeben kann. Hat der Anwender nach Herstellung eines Fotos den Wunsch, dieses Foto in einer anderen App zu verwenden, kann er auf den systemweit verfügbaren Teilen-Button klicken: Sämtliche Anwendungen, die vorher beim System registriert haben, dass sie mit Bilddateien umgehen können, werden nun angezeigt. Wird nun beispielsweise Twitter ausgewählt, stellt Windows 8 die saubere Übergabe der Bilddatei zwischen den beiden Apps sicher – ohne dass der Entwickler vorher definieren muss, wie das Foto zu Twitter gelangt. Das hat massive Vorteile: Zum einen muss der Entwickler nur noch die generische Windows 8-Schnittstelle implementieren und kann sich stärker auf die eigene App konzentrieren, zum anderen werden so auch all jene Nischen-Apps unterstützt, deren APIs selbst bei Verfügbarkeit nie integriert worden wären.

Abbildung 1.1 Der Share Contract erlaubt es der Kamera-App, ohne Initiative des Entwicklers auch mit Apps wie MetroTwit zusammenzuarbeiten

Ein weiteres Beispiel für die tiefere Integration von Apps in das System ist die Suche. Viele Apps halten Informationen bereit, die der Nutzer auf die ein oder andere Art und Weise durchsuchen kann – Inhalte, die der systemweiten Suche in aller Regel nicht zur Verfügung stehen. Auch hier setzt man auf Zentralisierung: Apps können ihre Suche zentral beim System anmelden. Startet der Benutzer irgendwo in der WinRT-Oberfläche die Suche, so wird zusätzlich eine Liste mit all jenen Apps angezeigt, die eine Suche anbieten. Als Beispiel dient ein Nutzer, der online einkaufen möchte. Zahlreiche Stores bieten inzwischen Apps an, um das Kauferlebnis zu verbessern. Anstatt jetzt manuell von App zu App zu wechseln, dort die Suche aufzurufen und den gewünschten Artikel einzugeben, kann ein Nutzer unter Windows 8 ohne viel Mühe direkt von Suche zu Suche springen.

Abbildung 1.2 Der Nutzer kann bei der Suche schnell auf die Inhalte einzelner Apps zugreifen

1.2 Architektur der Plattform

Windows 8 begrüßt seine Benutzer mit dem neuen Start-Screen, der sich in der WinRT-Oberfläche befindet. Die dort vorhandenen Kacheln repräsentieren allesamt Applikationen – entweder Apps, die im Vollbildschirmmodus innerhalb der WinRT-Umgebung gestartet werden, oder klassische Desktop-Anwendungen, deren Start den Nutzer aus der WinRT-Umgebung zum Desktop führt. Der Desktop selbst verfügt ebenfalls über eine Kachel. Die beiden Umgebungen wurden bereits als zwei Herzen in der Brust von Windows 8 beschrieben und in der Tat ist der Unterschied für Entwickler massiv. Die klassische Desktop-Umgebung bringt mit Windows 8 nur wenige Änderungen für Entwickler mit – betrachtet man sie losgelöst von Aktualisierungen bei Frameworks wie .NET, bleibt eigentlich alles beim Alten: Entwickler können ihre Anwendungen ganz nach eigenem Gusto entwickeln, vertreiben und installieren. Das System hält sich weitestgehend aus der Verwaltung des Applikationslebenszyklus heraus, der Anwender kann die Anwendung nach Belieben starten und beenden. Strenge Vorgaben an die Benutzeroberfläche oder an das Benutzungserlebnis existieren nicht, abseits von einfachen Empfehlungen seitens Microsoft kann man als Entwickler so ziemlich alles an Anwendungen herstellen, für das ein Markt vorhanden ist. Dieses Buch wird den Desktop weitestgehend ignorieren, da er für die Entwicklung von »Windows Store Apps« mit HTML5 und JavaScript ohne Bedeutung ist.

Wenn man über »WinRT Apps« spricht, sind jene Apps gemeint, die innerhalb der neuen Umgebung, also der WinRT-Umgebung laufen. Der Name »WinRT App« hat seinen Ursprung in der Art und Weise, wie diese Apps mit dem Betriebssystem interagieren. Für das Verständnis dieses Punktes ist von Bedeutung, dass es sich bei der WinRT-Oberfläche nicht etwa um ein Programm handelt, das auf dem normalen Desktop läuft. Die WinRT-Oberfläche ist eine vollwertige Umgebung, die wie eine zweite Säule neben dem klassischen Desktop steht. Wenn eine WinRT App mit dem Betriebssystem interagiert, also etwa auf das Dateisystem oder Hardware zugreifen möchte, nutzt sie dafür APIs, die von WinRT bereitgestellt werden. Eine WinRT App hat keinerlei Zugriff auf die klassischen Entwicklungsframeworks und APIs, die auf dem Desktop zur Verfügung stehen – gleichzeitig haben Desktop Apps keinerlei Zugriff auf den Luxus der zum Teil sehr komfortablen WinRT-APIs.

Abbildung 1.3 Der Desktop sowie die WinRT-Oberfläche stehen nebeneinander als zwei Säulen auf dem Windows-Kernel

Die beiden Welten der Windows 8-Oberfläche mit WinRT und die des Desktops sind nicht nur durch eigenständige API-Sätze, die der jeweils anderen Welt nicht zur Verfügung stehen, voneinander getrennt, sondern sie haben auch keinen Zugriff aufeinander. Im Klartext: Eine Kommunikation zwischen WinRT Apps und Desktop Apps ist technisch, so gut es geht, unterbunden und seitens Microsofts-Regelwerk verboten. Technische Kunstgriffe, die zu Betazeiten von Windows 8 noch möglich waren, wie etwa die Einrichtung eines lokal laufenden Webservers, wurden inzwischen technisch unterbunden – eine WinRT App erhält seit Veröffentlichung von Windows 8 keinen Zugriff mehr auf die IP-Nummer 127.0.0.1 oder auf localhost generell. Es ist also ausdrücklich gewünscht, dass die beiden Welten getrennt voneinander existieren, betrieben werden und auch von Entwicklern getrennt angesprochen werden. Zwar haben beide Welten Zugriff auf das Dateisystem und somit auch auf dort gespeicherte Dateien, ein direkter Kommunikationskanal zwischen WinRT Apps und Desktop Apps ist hingegen tabu. Sollte eine Kommunikation zwischen den beiden Welten dringend notwendig sein, verweist Microsoft auf die Cloud – Datenpakete können also ausschließlich via Internet zwischen den beiden Welten hin- und hergeschickt werden.

In dieser Umgebung herrschen zwei Paradigmen, die sich fundamental von der Desktop-Umgebung unterscheiden. Das betrifft zum einen den sogenannten Applikationslebenszyklus, also die Art und Weise, wann eine App wie ausgeführt wird. Zum anderen sind die Entwicklungsmöglichkeiten unter WinRT ausgesprochen umfangreich – Microsoft gibt Entwicklern direkt ein ganzes Buffet an Entwicklungstechnologien an die Hand, mit denen WinRT Apps entwickelt werden können.

Der Applikationslebenszyklus

In der klassischen Desktop-Umgebung muss sich der Entwickler kaum um den Lebenszyklus kümmern: Der Anwender startet eine Anwendung und ist selbst dafür verantwortlich, diese auch wieder zu beenden. Das System verteilt zwar die Ressourcen, schreitet aber nicht ein – das automatische Beenden oder Suspendieren einer Anwendung ist undenkbar. Kurz zusammengefasst: Der Nutzer ist für das Management des Applikationslebenszyklus verantwortlich.

Anders sieht die Situation in der WinRT-Umgebung aus, in der das System bestimmt, wann eine App Rechenzeit bekommt: Grundsätzlich läuft eine App im Vordergrund. Auf Wunsch des Nutzers kann eine zweite Anwendung an eine der beiden Bildschirmseiten gedockt werden, in welchem Fall sich zwei Apps im Vordergrund befinden und dementsprechend auch beide Apps über Rechenzeit verfügen und Code ausführen können. Die Zwei ist hier wörtlich zu nehmen: Die Anzahl gleichzeitig laufender Apps im Vordergrund ist auf maximal zwei beschränkt. Sämtliche Apps, die sich im Hintergrund befinden, also gerade nicht sichtbar sind, erhalten keinerlei Rechenzeit. Im Klartext: Ausgeführt wird nur, was auch sichtbar ist. Wie sieht also der Lebenszyklus einer App aus? Zum besseren Verständnis ein Blick auf den Lebenszyklus von insgesamt zwei Apps: App A und App B. Beide Apps wurden noch nicht gestartet. Nun startet der Nutzer App A – die App ist im Vordergrund und erhält Rechenzeit. Wechselt der Anwender nun zurück zum Start-Screen, gerät App A in den Hintergrund. Die App wird nun suspendiert – das System schickt der App einen Event, der sie darüber informiert, dass ihr nur noch wenige Sekunden Rechenzeit zur Verfügung stehen. Anschließend wird der App jegliche Rechenzeit entzogen. Die im Arbeitsspeicher befindlichen Daten bleiben jedoch erhalten. Wechselt der Anwender nun zurück zu App A, erhält die App wieder Rechenzeit und kann weiterhin ausgeführt werden. Dieser Schlafzustand, in dem die Daten einer App im Arbeitsspeicher zwar erhalten bleiben, sie aber keinen Code ausführen kann, wird »suspendiert« genannt. Startet der Anwender nun App B, befindet sich App A im suspendierten Zustand. Sollte nun der Fall eintreten, dass App B mehr Arbeitsspeicher benötigt, als frei ist, geht das System rabiat vor und gibt den von App A genutzten Arbeitsspeicher frei. Wird die App nun erneut aufgerufen, verhält sich die App wie bei einem Neustart – sämtliche nur im Arbeitsspeicher befindlichen Daten sind nicht mehr vorhanden, die App wird de facto neu gestartet.

Das Besondere hierbei ist, dass App A, wenn sie suspendiert wird, sich bereits auf die Eventualität vorbereiten muss, terminiert zu werden. Da eine suspendierte App keinerlei Rechenzeit erhält, erhält sie auch keine Benachrichtigung, wenn sie terminiert wird. Der Entwickler muss seine App also so gestalten, dass Daten wie etwa Formulareingaben jederzeit wiederhergestellt werden können.

Doch nicht nur in puncto Lebenszyklus unterscheiden sich WinRT Apps fundamental von Desktop Apps – auch die Möglichkeiten, mit dem Betriebssystem zu interagieren, sind eine Einführung wert.

Zugriff auf WinRT-APIs – ein bunter Technologiemix

Microsoft baut mit WinRT auf drei Technologieblöcke, um möglichst vielen Entwicklern die Gelegenheit zu geben, mit den ihnen bereits bekannten Werkzeugen und Programmiersprachen schnell in die Windows 8-Entwicklung einsteigen zu können. Freunde von Performance und Systemnähe können nativ mit nicht verwaltendem Code (engl. »Unmanaged Code«), also C++ und C, entwickeln. Als Präsentationssprache wird auf XAML gesetzt. Klassische Windows-Entwickler greifen im Rahmen des verwalteten Codes (engl. »Managed Code«) auf die Microsoft-Technologien C# und Visual Basic zurück – auch hier stützt man sich auf XAML als Präsentationssprache. Dieses Buch konzentriert sich auf den dritten Block: Zusätzlich zu den klassischen Anwendungsentwicklungssprachen hebt Microsoft HTML5 und JavaScript erstmals auf einen Level, der den anderen beiden Blöcken ebenbürtig ist. HTML ist hierbei die Präsentationssprache, während die Logik der App in JavaScript realisiert wird.

Abbildung 1.4 Die Entwicklung von WinRT Apps ist mit zahlreichen Technologien möglich

Natürlich stellt JavaScript keine Sprache dar, für die ein Zugriff auf das Betriebssystem selbstverständlich ist. JavaScript ist immerhin ausdrücklich eine Skriptsprache, die sich für die Ausführung der Befehle traditionell auf Webbrowser und kleine Programme verlassen hat – weniger auf ganze Betriebssysteme. Microsoft hat es mit Windows 8 jedoch geschafft, JavaScript geschickt in das System zu integrieren. Für den Entwickler sind zwei Punkte von wesentlicher Bedeutung: Zum einen ist die von Windows 8 verwendete JavaScript-Engine Chakra, die für die Ausführung des Skriptcodes zuständig ist, rasend schnell. Chakra nutzt Hardwarebeschleunigung und ist tief in das System integriert, wodurch beeindruckende Leistung erzielt wird. Zum anderen erfolgt der Zugriff auf die verschiedenen Betriebssystemfunktionen nicht über eine Anpassung von JavaScript selbst, sondern über eine mächtige Bibliothek namens »WinJS«.

WinJS verhält sich, soweit es den gemeinen Entwickler betrifft, wie jede andere JavaScript-Bibliothek auch – ganz wie jQuery, Dojo, MooTools oder andere Bibliotheken, die die Entwicklung von JavaScript-Applikationen einfacher gestalten. Hinter dem vollen Namen »Windows Library for JavaScript« versteckt sich also eine Ansammlung an JavaScript- und CSS-Dateien, die eine ganze Reihe an Objekten bereitstellen. In verschiedenen Namespaces organisiert findet der Entwickler in WinJS praktische Controls wie Datepicker, komplexe Listen oder ein Rating-Werkzeug, aber auch so Dinge wie eine Animationsbibliothek, einen vereinfachten XMLHttpRequest-Handler oder Methoden, mit denen Klassen und Namespaces angelegt werden können. Diese Vorgehensweise befreit den JavaScript-Entwickler von der Notwendigkeit, die genauen Innereien von Windows 8 zu verstehen, um ansprechende Apps zu entwickeln. Wer beispielsweise auf die Webcam zugreifen möchte, verwendet hierfür einen ungefährlich aussehenden Aufruf einer WinJS-Funktion – wie genau Chakra als JavaScript anschließend mit dem Betriebssystem umgeht, damit dieses Zugriff auf die Hardware ermöglicht, ist für den Entwickler von geringerem Interesse. Aus diesem Grund wird WinJS auch gerne als »jQuery auf Steroiden« bezeichnet – es lässt selbst komplexe Dinge wie Hintergrundprozesse, nativ beschleunigte Benutzeroberflächen-Controls oder Medienstreaming aussehen, als würde man in einer einfachen Bibliothek einen Button animieren.

Dieses Buch ist also im Wesentlichen eine umfangreiche Einführung in WinJS: Der für Windows 8 geschriebene HTML5- und JavaScript-Code sieht bis auf die Verweise auf WinJS aus wie normaler Webcode. Das führt dazu, dass Webentwickler, die mit HTML5 und JavaScript schon ein wenig Erfahrung haben, sehr schnell zur ersten eigenen App kommen – und noch schneller bestehende Webseiten in eine App verpacken können. Bevor man sich blind in die Entwicklung stürzt, lohnt ein Blick auf die Designvorgaben, die Microsoft unabhängig von der verwendeten Entwicklungstechnologie für Benutzeroberflächen und Benutzererfahrung gemacht hat: Die sogenannten WinRT Style Guides sind ein elementarer Bestandteil des Ökosystems und sollten von jedem Entwickler noch vor Beginn jeder Entwicklung verinnerlicht werden.

Kapitel 2. Windows 8-Design: Prinzipien und Richtlinien

Microsoft hat Entwicklern traditionell viel Freiheit gegeben: Nach wie vor können Desktop-Applikationen in puncto Benutzeroberfläche und Benutzerführung tun und treiben, wonach dem jeweiligen Entwickler der Sinn steht. Mit der WinRT-Oberfläche ändert sich das: Die über mehrere Jahre unter dem Codenamen »Metro« entstandene Designsprache bietet sowohl sehr fundamentale, fast philosophisch anmutende Richtlinien zur Entwicklung von Benutzeroberflächen als auch konkrete Vorgaben, wie einzelne Elemente einer Oberfläche gestaltet werden müssen. Jene Apps, die in der neuen Oberfläche beheimatet sind und einen Platz im Windows Store ergattern müssen, werden einer umfangreichen Prüfung unterzogen, die eine korrekte Einhaltung der Vorgaben bis ins kleinste Detail überprüft. Gleichzeitig haben einige der strikten Vorgaben umfangreiche Folgen für die Entwicklungspraxis. Als Beispiel dient etwa die Maxime »Fast and Fluid«, welche verlangt, dass die Oberfläche dem Nutzer bei Interaktion jederzeit Feedback gibt und »lebendig« erscheint. Dies führt dazu, dass in JavaScript ein umfangreiches asynchrones Entwicklungsmuster eingeführt wurde, damit die Benutzeroberfläche auch bei länger andauernden Anfragen nicht einfriert.

Dieses Kapitel widmet sich deshalb kurz den Voraussetzungen, die zur Entwicklung der Metro-Designsprache geführt haben – und geht anschließend alle wesentlichen Punkte durch, die für die praktische Entwicklung von Relevanz sind.

2.1 Eine kurze Geschichte der Benutzeroberflächen

Obwohl einzelne Elemente der Designsprache bereits in frühen Microsoft-Produkten wie Encarta 95, MSN 2.0 und Windows Media Center auftauchten, wurde die »Metro-Designsprache« für Drittentwickler erstmals in umfangreicher Form mit Windows Phone vorgestellt. Das Designteam verweist für die Entstehungsgeschichte der Designsprache gerne auf den Übergang von Windows Mobile zu Windows Phone – aus Designsicht habe man am Ende des Lebenszyklus von Windows Mobile realisiert, dass der dort eingeschlagene Weg nicht länger tragbar sei. Mit der Freiheit, ein komplett neues Interface zu entwickeln, sei auch die Freiheit entstanden, auf einem weißen Blatt Papier zu denken – und entsprechend ganz neu über die fundamentalen Bestandteile von modernen Benutzeroberflächen nachzudenken.

Aktuelle Benutzeroberflächen, wie sie auf dem klassischen Windows Desktop, in Mac OS X oder vielen fensterorientierten Erweiterungen unter Linux zu finden sind, haben einen gemeinsamen Ursprung, der mehr als 60 Jahre zurückreicht. 1945 beschrieb der US-amerikanische Ingenieur und Erfinder Vannevar Bush in einem Artikel im Magazin »The Atlantic Monthly« die sogenannte Memex Machine (»Memex steht für Memory Extender«, zu Deutsch etwa »Gedächtnis-Erweiterer«). Beschrieben wurde die Memex als ein großer Schreibtisch, in den mehrere Bildschirme eingelassen sind. Der Nutzer hätte diese Maschine als Gedächtniserweiterung nutzen können, die es ihm erlaubte, Dokumente schnell zu annotieren, referenzieren und miteinander zu verknüpfen – quasi als Prototyp eines Hypertextsystems, dessen Konzepte dem späteren Hypertext im World Wide Web ähneln. Die Maschine wurde nie gebaut.

Als man bei Institutionen wie SRI und Xerox PARC in den frühen 1970er-Jahren im Bereich grafischer Benutzeroberflächen forschte, gewann die Memex wieder an Relevanz. Bekannt war bislang nur die Kommandozeile, ein Konzept für eine grafische Oberfläche galt es erst noch zu erarbeiten.

Um dem Nutzer den Einstieg zu erleichtern und schnell ein Konzept beizubringen, bediente man sich bei der Idee der Memex – und baute einen virtuellen Schreibtisch inklusive Dateien, Akten, Ordnern und Fenstern. Wer heute einen Blick auf das frühe System wirft, wird sich sofort an moderne Betriebssysteme erinnert fühlen – die Computerpioniere konnten das Konzept aufgrund mangelnder Patentierung seitens Xerox PARC problemlos übernehmen.

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!