Kochen mit Patrick: Offlinefähige Webapplikationen mit HTML(5) Selbst offline noch online

Transkript

1 PRAXIS Kochen mit Patrick: Offlinefähige Webapplikationen mit HTML(5) Selbst offline noch online Patrick A. Lorenz ist Geschäftsführer der PGK GmbH, eines auf.net spezialisierten Technologiedienstleisters, der das.net-basierte CMS QualiSite anbietet. Daneben ist er als Autor und Coach tätig. In seiner Freizeit ist Patrick Hobbykoch. Sie erreichen ihn unter und com/kochen.mit.patrick. dnpcode A1211Kochstudio Nicht erst seit diesem Jahr sind wir immer und überall online. Wenn mich unterwegs spontan eine Frage quält, ist die nächste Wikipedia-App mit einer vermeintlich passenden Antwort nur einen Griff in die Hosentasche entfernt. Und auch nachdem die Smartphones nun aus einem von mir nicht nachvollziehbaren Grund wohl wieder zunehmend größer werden, müssen wir maximal bis zur (Herren-)Handtasche langen. Auch unsere tägliche Arbeit verlagert sich immer mehr ins Web. Und, nein, damit meine ich nicht Facebook, sondern klassische Desktop- Softwareprodukte, deren Aufgaben zunehmend von Webapplikationen übernommen werden. Google ist hier schon länger ein Vorreiter, zum Beispiel mit Google Docs oder dem auf Chrome basierenden, eher als experimentell zu bezeichnenden Betriebssystem Chrome OS. Aber Microsoft öffnet sich mittlerweile sehr stark in diese Richtung, etwa mit den Webversionen der Office- Produkte als Bestandteil von Office 365. Die im letzten Monat an dieser Stelle erwähnte Webversion von OneNote geht in dieselbe Richtung. Sobald wir immer mehr Arbeiten rein im Browser erledigen sollen, werden wir eines zwingend voraussetzen: ein hohes Maß an Zuverlässigkeit oder, wie es beim Bulls*** Bingo heißen würde, Reliability. Wenn ich beispielsweise während einer beschaulichen Zugfahrt je nach Jahreszeit übermäßig frierend oder schwitzend im ICE mit dem Tablet auf meinem Schoß, im Abteil eingeklemmt zwischen zwei Großfamilien, mit dem -Webclient meiner Wahl meiner Herzallerliebsten ein Liebesgedicht schreibe und ungeschickterweise mitten während der zweistündigen Verschnaufpause im Tunnel auf Senden klicke, wäre wohl nicht nur ich zutiefst enttäuscht, falls die Nachricht einsam zwischen zwei Gleisabschnitten verenden würde. Nein, natürlich würde ich erwarten, dass meine naiven Wortreihen so lange lokal zwischengespeichert würden, bis die Onlineverbindung steht und die Nachricht ihre Empfängerin etwas verspätet, dafür aber verlustfrei erreichen würde. Nicht trotz, sondern nicht zuletzt gerade durch die Verbreitung onlinefähiger Geräte steigt also die Nachfrage nach Webapplikationen, die auch offline funktionieren. Man nennt sie mal Online/Offline-Webapplikationen, manchmal auch Offline Web Applications. Mit schnödem JavaScript aus dem Jahr 1995 lassen sie sich nicht realisieren, da braucht es neuere Techniken, zum Beispiel einige der mit HTML5 eingeführten Funktionen, die ich Ihnen diesen Monat vorstellen möchte. Online du bist? Die erste Frage bei der Entwicklung einer offlinefähigen Webapplikation lautet naheliegenderweise, ob der Benutzer nun gerade online oder offline ist. HTML5 spendiert den Browsern eine einfache Antwortmöglichkeit in Form der booleschen Eigenschaft: navigator.online. Liefert der Browser true, wähnt er sich online, und ansonsten offline. Im folgenden Snippet wird die Eigenschaft periodisch alle 250 Millisekunden abgefragt und abhängig vom Ergebnis die Hintergrundfarbe eines Divs mittels jquery von Grün auf Rot geändert und darin ein passender Text angezeigt: <div id="onlinestatus"> Prüfe Online-Verbindung... </div> <script language="javascript"> $(function () { setinterval(function () {

2 PRAXIS var statuselement = $('#onlinestatus'); var online = navigator.online; statuselement.text( online? 'Ihr Browser ist online' : 'Ihr Browser ist offline'); statuselement.css("background-color", online? "rgb(0, 204, 0)" : "rgb(204, 0, 0)");, 250); ); </script> [Abb. 1] Der Browser gibt Auskunft über den Onlinestatus. Abbildung 1 zeigt das Beispiel im Internet Explorer 9. Ich habe den Browser hier bewusst in den Offlinemodus versetzt, aber auch der Abbruch beispielsweise einer WLAN-Verbindung würde zum gleichen Ergebnis führen. Ohne Änderung funktioniert das Beispiel auch in anderen Browsern wie Chrome oder Firefox und auch auf mobilen Geräten, etwa mit Safari auf einem ios-gerät. Statt periodisch den Status zu ermitteln, unterstützen viele Browser auch die Ereignisse online und offline: $(function () { $(window).bind('online', checkconnectivity); $(window).bind('offline', checkconnectivity); checkconnectivity(); ); function checkconnectivity() { var statuselement = $('#onlinestatus'); var online = navigator.online; statuselement.text( online? 'Ihr Browser ist online' : 'Ihr Browser ist offline'); statuselement.css("background-color", online? "rgb(0, 204, 0)" : "rgb(204, 0, 0)"); Die Offlineerkennung klappt in der Praxis ziemlich gut. Hundert Prozent Verlass gibt es bei diesem Ansatz allerdings nicht, denn der Browser muss selbst schon wissen, dass er nicht mehr online ist. Andererseits bedeutet eine bestehende Onlineverbindung nicht gleichzeitig auch eine funktionierende Zugriffsmöglichkeit auf das Internet. Wer es ganz genau wissen will, muss tatsächlich versuchen, auf das Internet zuzugreifen. Ein sinnvoller Ansatz ist da beispielsweise der Versuch, eine winzige, nicht gecachte Datei im Hintergrund per Ajax herunterzuladen. Klappt das, besteht ganz offensichtlich Internetzugang. Ein schönes Beispiel, das die Browserfunktionalität mit einer Prüfung kombiniert, findet sich im Blog [1]. Web Storage Hat die Webapplikation festgestellt, dass Applikation samt Benutzer tatsächlich offline sind, sollte sinnvoll reagiert werden. Mit höchster Priorität sollte die Arbeit des Benutzers gesichert werden, also dessen Eingaben. Eine lokale Zwischenspeicherung wäre ein sicherlich gewünschtes Verhalten. Traditionell werden dazu Cookies verwendet. Meist dienen diese, vor allem in Verbindung mit serverseitigen Technologien, der Persistenz von Informationen, die ausgehend vom Server im lokalen Browser gespeichert und zu einem späteren Zeitpunkt wieder auf dem Server ausgewertet werden. Dies impliziert eines der Grundkonzepte von Cookies, nämlich die ständige Übertragung vom und zum Server mit jeder HTTP-Anforderung. Zwar lassen sich Cookies auch auf dem Client anlegen und verarbeiten, dennoch werden sie übertragen und eignen sich daher zumindest nicht für größere Datenmengen. Und abgesehen davon genießen Cookies nach wie vor ein schlechtes Image. Eine bessere Alternative für die lokale Speicherung von beispielsweise Benutzereingaben ist der HTML5 Web Storage. Vergleichbar mit Cookies lassen sich darin Schlüssel-Wert-Daten ablegen. Die Daten werden jedoch ausschließlich auf dem Client gespeichert und zu keinem Zeitpunkt direkt mit dem Server ausgetauscht. Die lokale Speicherung erfolgt entweder im Kontext der laufenden Benutzersitzung oder dauerhaft. In beiden Fällen ist der Zugriff immer auf Daten der aktuellen Domain beschränkt, Sie können im Prinzip also nur Daten lesen, die Sie selbst im Web Storage abgelegt haben. Der Zugriff erfolgt per JavaScript über die zwei dedizierten Objekte sessionstorage und localstorage mitsamt einigen jeweils identischen Methoden. Dazu gehören setitem zum Schreiben eines Eintrags und getitem zum Lesen. Das folgende Beispiel zeigt zwei mehrzeilige Eingabefelder (textarea). Mittels jquery wird über das keyup-ereignis beim Betätigen einer Taste in einem der Textfelder der eingegebene Text im localstorage- Dictionary abgelegt. Zur Identifizierung im Web Storage dient die ID des Eingabeelements. Beim Laden der Seite wird der zwischengespeicherte Wert ausgelesen und in das Eingabefeld geschrieben. Sie können den Browser somit beliebig schließen und neu öffnen: Der einmal eingegebene Text ist immer noch da. <textarea id="text1" style="width: 400px; height:200px"></textarea> <script> var inputelements; $(function () { inputelements = $("textarea"); inputelements.keyup(function () { storevalue(this); ); loadvalues(); dumpstorages(); ); function loadvalues() { inputelements.each(function () { loadvalue(this); ); function loadvalue(obj) { var value = localstorage.getitem(obj.id); if (value!= null) { var objj = $(obj); objj.val(value); function storevalue(obj) { var objj = $(obj); var value; value = objj.val(); localstorage.setitem(obj.id, value); </script>

3 PRAXIS Kochen mit Patrick: Offlinefähige Webapplikationen mit HTML(5) Gespeichert werden üblicherweise ausschließlich Strings, zumindest limitieren die meisten Browser den Web Storage derzeit dahingehend. Wer andere Datentypen speichern will, sollte diese als JSON-Zeichenkette konvertieren und beim Auslesen wieder parsen: var steveb = { FirstName: "Steve", LastName: "Ballmer" ; var value = JSON.stringify(steveB); localstorage.setitem("steveb", value); Mit weiteren Methoden auf den beiden Storage-Objekten können Sie das Dictionary leeren, ausgewählte Einträge entfernen, sogar alle gespeicherten Schlüssel durchlaufen und diese samt den gespeicherten Werten abfragen. Das geht so: dumpstorage(sessionstorage, "sessionstoragedump"); dumpstorage(localstorage, "localstoragedump"); function dumpstorage(storage, divname) { var dump = ""; for (var i = 0; i < storage.length; i++) { var key = storage.key(i); dump += key + " = " + storage.getitem(key) + '<br/>'; $("#" + divname).html(dump); Abbildung 2 zeigt eine Kombination der Anwendungsfälle, diesmal mit Google Chrome. Web Storage ist ein ehemaliger Bestandteil von HTML5, der mittlerweile jedoch zu einer eigenen W3C-Empfehlung [Abb. 2] Der Web Storage speichert Schlüssel- Wert-Paare lokal im Browser. heranreift. Die aktuellen Versionen aller gängigen Browser unterstützen den Web Storage bereits in der gezeigten Form. Web SQL Database und IndexedDB Für eine temporäre Offlinefähigkeit von Webapplikationen wie etwa dem Web - client im Zug dürfte die Schlüssel-Wert- Speicherung im Web Storage völlig ausreichend sein. Wer eine umfangreiche offlinefähige Applikation realisieren möchte, kann zukünftig aber noch einen Schritt weitergehen und eine ganze Datenbank im Browser anlegen und verwalten. Ähnlich wie der Web Storage werden solche Datenbanken lokal im Client gespeichert, und die Daten werden nicht mit dem Server ausgetauscht. Es gibt dazu vom W3C zwei unterschiedliche Ansätze: Web SQL Database und IndexedDB. Die Spezifikation der Web SQL Database sieht eine wie der Name andeutet SQL-basierte Datenbank im Browser vor. Mit üblichen Statements lassen sich Tabellen anlegen, Datensätze erzeugen, Abfragen durchführen und so weiter ganz wie wir es kennen. Ein entscheidender Nachteil dabei liegt auf der Hand: Alle Daten müssen zwischen JavaScript und dem strengen Datensatz-Modell von SQL hin- und herkonvertiert werden. Web SQL wurde von einigen Browsern implementiert, mittlerweile jedoch vom W3C für deprecated erklärt. Als offizielle Begründung wird angegeben, dass alle Browserhersteller auf SQLite als Backend gesetzt hätten und sich das W3C für eine Standardisierung eine heterogene Basis gewünscht hätte. Ich persönlich behaupte, dass ein SQL-basiertes Modell nicht zu den Anforderungen einer Browserdatenbank und JavaScript passt. Das neue und nun präferierte Konzept heißt IndexedDB und löst SQL nicht nur im Namen, sondern auch in der Praxis ab. Statt mit Statements und Datensätzen zu hantieren, werden direkt JavaScript- Objekte persistiert und über Indizes effizient zugreifbar gemacht. Die Abfrage der Daten erfolgt Cursor-basiert mittels einer übergebenen Callback-Methode, die für jedes Objekt aufgerufen wird. Das folgende Beispiel basiert auf [2] und zeigt in vereinfachter Form die Abfrage eines Cursors: var idbrequest = window.indexeddb.open( 'DBName'); idbrequest.onsuccess = function(event) { var db = event.srcelement.result; var transaction = db.transaction([], IDBTransaction.READ_ONLY); var currequest = transaction.objectstore('storename').opencursor(); currequest.onsuccess =...; ; Die Verwendung erfordert ein wenig Vorbereitung und tatsächlich eine Menge Quelltext. Ein schönes Tutorial mit Beispielen finden Sie unter [3]. Mir persönlich erscheint das IndexedDB-API etwas sperrig. Ich glaube, es ginge auch einfacher. Das API wird derzeit noch nicht von allen Browsern unterstützt. Internet Explorer 9 bleibt außen vor, mit Version 10 wird IndexedDB jedoch unterstützt. Application Cache Als dritten Baustein für Offline Web Applications nach der Offline-Identifizierung und der lokalen Speicherung von Daten stellt HTML5 bessere Eingriffsmöglichkeiten in das Caching-Verhalten eines Browsers bereit. Bisher lässt sich dies vor allem auf Ebene der HTTP-Antwort einzelner Dateien mittels spezieller Kopfdaten beeinflussen. Zukünftig kann HTML-Seiten ein Application Cache Manifest mitgegeben werden. Ist dies der Fall, werden die eingangs aufgerufene Datei und alle weiteren im Manifest genannten explizit für eine etwaige Offlinenutzung im Cache des Browsers zwischengespeichert. Auch ohne aktive Internetverbindung kann die Datei später aufgerufen werden. Beim Application Cache Manifest handelt es sich letztlich um eine schnöde Textdatei, die in einer definierten Form die lokal zu speichernden Dateien auflistet. Das sieht beispielsweise so aus: CACHE MANIFEST CACHE: /Images/Image1.png /Images/Image2.png /Scripts/Script1.js /Scripts/Script2.js NETWORK: /WebServices/* FALLBACK: /Online.aspx /Offline.aspx Im Abschnitt CACHE werden alle im Cache zu haltenden Dateien aufgelistet. Diese Dateien werden unmittelbar nach der Auswertung der Manifest-Datei automatisch durch den Browser geladen, auch ohne dass sie zunächst in der aktuellen Seite referenziert werden müssen

4 PRAXIS Wie bei Oma am Kachelofen Einen Kachelofen hatten meine Großeltern nicht. Trotzdem ist die Vorstellung schön. Draußen wird es immer kühler: herbstlich bis gefühlt fast winterlich. Da darf man schon etwas heizen. Dicke Socken, der Ikea-Rentierpulli Wärmty, ein heißer Tee, und natürlich braucht es auch ein zur Jahreszeit passendes Essen. Deftig darf es sein und gerne auch etwas rustikal. Thüringer Rindsroulade nach Schwiegervater-Art Sie sehen schon, diesmal wird die ganze Familie involviert. Für die Zubereitung seiner original Thüringer Rindsroulade empfiehlt der Thüringer Schwiegervater gutes Fleisch vom Metzger, das möglichst flach geklopft und dann von einer Seite mit Senf bestrichen wird, gepfeffert und ganz leicht gesalzen. Etwas Schinkenspeck sowie saure Gurken und je nach Anzahl der Rouladen eine kleine bis mittlere Zwiebel werden in feine Würfel geschnitten, dann wird das Fleisch damit belegt. Die Rouladen werden anschließend an den Seiten etwas eingeschlagen und dann von der schmalsten Seite her fest aufgerollt. Damit das auch hält, verwenden Sie einen Spieß, eine Klammer oder Bindfaden. Die Rouladen werden, beginnend auf dem Endstück und dann rundherum, auf vier Seiten in einer Pfanne scharf angebraten. In der Zwischenzeit geben Sie in einen separaten Topf Zwiebeln und Wurzelgemüse nach Wunsch (Sellerie, Karotten, Petersilienwurzel), braten dies alles an und löschen mit etwas Wasser ab. Darauf kommen nun die Rouladen. Kurz aufkochen und dann mindestens eine gute Stunde sanft köcheln lassen. Danach kommen die Rouladen raus, das Gemüse wird passiert und die entstehende Soße je nach Wunsch etwas angedickt. Die Rouladen werden von Spießen, Klammern oder Bindfaden befreit und kommen zurück in den Topf. Rouladen können gut am Vortag vorbereitet werden. Sie müssen dann bloß noch sanft aufgewärmt und gierig verputzt werden. Guten Appetit! Alle Dateien müssen existieren. Eventuelle Fehler führen zu einem Abbruch, und das Manifest wird komplett ignoriert. Die aufrufende Seite und alle hier genannten Dateien werden dauerhaft im Cache des Browsers gehalten. Anders als beim normalen Caching werden sie auch bei Änderungen nicht neu geladen. Lediglich die Manifest-Datei wird, sofern möglich, neu geladen. Unter NETWORK werden optional Dateien aufgeführt, die gerade nicht lokal gespeichert, sondern bei jeder Anforderung neu geladen werden sollen. Wildcards sind hier möglich. Der dritte und optionale Abschnitt FALLBACK listet paarweise Fallback-Adressen auf. Ist zum Beispiel kein Zugriff auf die online.aspx möglich, wird der Fallback offline.aspx aus dem Cache angezeigt. Die Manifest-Datei wird üblicherweise in der oder den Einstiegsseiten einer Webapplikation hinterlegt, und zwar direkt im Kopfbereich: <html manifest="/appcachemanifest.aspx"> <head>... </head> </html> Ich habe im Beispiel die Manifest-Datei als ASP.NET-Web-Forms-Seite realisiert, um sicherzustellen, dass diese per Codebehind den richtigen MIME-Typ text/ cache-manifest zurückliefert. Das Verhalten des Caches lässt sich besonders einfach in Google Chrome nachvollziehen. Hier liefert die Konsole hilfreiche Informationen. In Abbildung 3 ist beispielsweise zu erkennen, dass die Verarbeitung des Manifests aufgrund einer nicht gefundenen Datei abgebrochen wurde. Der HTML5 Application Cache besteht außer aus dem deklarativen Manifest aus einem API. Dessen Aufgabe ist es einerseits, den Entwickler über den Zustand des Caches zu informieren, und andererseits, diesen explizit zu aktualisieren. Einstiegspunkt sind das window.applicationcache-objekt und dessen update- Methode, die hier von einem Button ausgelöst wird:

5 PRAXIS Kochen mit Patrick: Offlinefähige Webapplikationen mit HTML(5) [Abb. 3] Mit der Chrome-Konsole lassen sich Fehler im Cache Manifest aufdecken. [Abb. 4] Das Application-Cache-API prüft auf Änderung des Manifests. <button onclick=" window.applicationcache.update(); return false;" > Cache leeren </button> Die Methode prüft auf dem Server, ob eine neue Version der Manifest-Datei existiert. Ist dies der Fall, werden das Manifest neu ausgewertet und die darin enthaltenen Dateien heruntergeladen. Ist dieser Prozess abgeschlossen, wird das Ereignis updateready ausgelöst. Über die Methode swapcache können nun der bisherige Cache durch die neue Version ersetzt und anschließend die Seite neu aus dem Cache geladen werden: <script> var cache = window.applicationcache; cache.addeventlistener('updateready', function (e) { if (cache.status == cache.updateready) { cache.swapcache(); window.location.reload(); ); </script> Der HTML5 Application Cache ist eine gute Sache für die Implementierung von offlinefähigen Webapplikationen. Aber auch beim Onlinebetrieb können statische Ressourcen wie Bilder und Scripts vorgeladen und im Browser-Cache gehalten werden. Das Caching ist allerdings nicht ohne Tücken, denn die Einstiegsseite wird generell und dauerhaft im Speicher gehalten. Auch Änderungen an der Datei wirken sich anders als beim bisher bekannten HTTP- Header-basierten Caching nicht aus. Erst eine Aktualisierung des Manifests führt zum neuen Laden der Daten. Das Caching wird in der vorgestellten Form derzeit unter anderem von Chrome und Firefox unterstützt, und auch Safari kommt auf dem Desktop sowie unter ios damit zurecht. Der Internet Explorer unterstützt die Funktionalität erst ab Version 10 sowie Windows Phone 8. Eine kurze Geschichte zu HTML5 Namen sind ja Sie wissen schon! Auch bei HTML5 scheint das so zu sein. Das Thema ist so verwirrend, dass man meinen könnte, Microsoft sei fürs Marketing verantwortlich gewesen. HTML5 ist die neue Version von HTML, so viel ist klar. Der Standard wird vom W3C erarbeitet, ist aber eigentlich noch gar keiner und auch noch keine Empfehlung, sondern die Gremien sind noch richtig bei der Arbeit. Das W3C rechnet etwa im Jahr 2014 mit einer fertigen Empfehlung von HTML5. Sie und ich wollen natürlich nicht so lange warten, bis wir die neuen Funktionen nutzen können. Die Browserhersteller wollen das auch nicht und haben viele bisher spezifizierte Funktionen bereits in ihre aktuellen Browserversionen integriert und manche dann auch wieder entfernt. Mozilla, Opera und Apple sind noch einen Schritt weitergegangen und haben gemeinsam die Web Hypertext Application Technology Working Group (WHATWG) [4] ins Leben gerufen, die ebenfalls an HTML5 zu arbeiten gedachte. Die 5 hat man dort allerdings zwischenzeitlich gestrichen und spricht stattdessen nur noch von HTML und einer lebendigen Spezifikation, die fortwährenden Änderungen unterworfen ist. Das trifft den Kern sicherlich ganz gut. Den aktuellen Stand der HTML-Spezifikation nach dem Verständnis von WHATWG finden Sie unter [5]. Dem nachvollziehbaren Wunsch nach einer kürzeren Inkubationszeit von Web innovation trägt das W3C selbst insofern Rechnung, als dass verschiedene ehemalige HTML5-Bestandteile unabhängig und als eigene Spezifikation vorangetrieben werden. Schauen Sie doch mal, wo Sie die hier behandelten Themen in Abbildung 5 finden. Fortschritt in einer offenen Webgesellschaft mit so vielen Beteiligten mit unterschiedlichsten Interessen muss wirklich harte Politik sein. Bei uns Entwicklern bleibt angesichts verschiedener Spezifikationen und Gremien schnell Verwirrung hängen. Wenn man dann noch bedenkt, dass die unterschiedlichen Browser ein jeweils individuelles Set an HTML5- Funktionen implementieren, mag man sich ein wenig in das Webdesigner-Glück vergangener Tage zurückversetzt fühlen, als sich das Internet mehr um Browserweichen als um Innovationen gedreht hat. So schlimm ist es aber nicht, denn zumindest halten sich die Hersteller meist sehr eng an die jeweilige Spezifikation. So muss ein Entwickler dann zwar vielleicht ermitteln ob ein Feature unterstützt wird, er muss jedoch nicht zahlreiche unterschiedliche Interpretationen des Features berücksichtigen. Welcher Browser kann was? Einen guten Überblick darüber, welche Browserversion welche Funktionen unterstützt, liefert die Seite HTML5 Test [6]. Konsolidiert werden die einzelnen

6 PRAXIS Feature-Kriterien in einer Bewertung mit 500 maximal möglichen Punkten. Davon erreicht Chrome 21 satte 437, Firefox 14 immerhin noch 345. Weit abgeschlagen ist der Internet Explorer 9 mit nur 138 Punkten. Mit Version 10 wird die Welt für Microsoft aber etwas besser, die kommt zumindest auf 319 Punkte. Wie war das noch beim Eurovision Song Contest? Der Gewinner arbeitet die nächste Spezifikation aus? Wer die neuen Funktionen nutzen will, tut gut daran, diese mit den zu unterstützenden Browserversionen und deren Verbreitung abzugleichen. Offizielle Angaben dazu gibt es ja viele. Statt eine solche Statistik zu zitieren, habe ich zu den naheliegenden Daten gegriffen, denen der dotnetpro-website. Die sind natürlich sehr geprägt von einem stark Microsoftlastigen Publikum. Umso erstaunlicher ist da die Verteilung der Top 3 zwischen dem 1. Januar und dem 31. August 2012: 3 8,48 Prozent Firefox 3 5,56 Prozent Internet Explorer 1 5,76 Prozent Chrome Danach folgen mit deutlichem Abstand Safari und Opera. Hätten Sie das erwartet? Etwas beruhigender ist die Top-Platzierung von Windows als Betriebssystem mit 89,25 Prozent, von denen wiederum 73,56 Prozent auf Windows 7 entfallen. Die Details zu den verwendeten Browserversionen für den Monat August 2012 finden Sie in Abbildung 6. [Abb. 5] HTML5 und wie die Welt es sieht, Quelle: SpecGraph [7]. [Abb. 6] Verteilung von Browsern und Versionen auf der dotnetpro-website im August Fazit Auf den ersten Blick scheint der Wunsch nach stärkerer Offlinefähigkeit von Webapplikationen im Widerspruch zur zunehmenden Onlineverfügbarkeit zu stehen. Ich behaupte: Das ist kein Widerspruch, denn mit der Onlinefähigkeit ist zunächst mal auch die Omnipräsenz von onlinefähigen Geräten gestiegen. Und jedes dieser Geräte ist potenziell eben auch offlinefähig. Im nicht WLAN-fähigen Zug etwa reißt die Verbindung andauernd ab, und der fehlende Internetzugriff im Flugzeug ist heute zwar nicht mehr zwangsläufig Realität, jedem Arbeitsflieger aber immer noch hinreichend präsent. Auf der anderen Seite lösen Webtechnologien immer mehr native Applikationen ab, auf rein mobilen Geräten, aber zunehmend auch auf klassischen Desktops. Google als Webprimus ist in diesem Bereich eine treibende Kraft. Wer seine Arbeitszeit einer solchen Webapplikation anvertraut, erwartet nicht zu Unrecht ab- solute Zuverlässigkeit. Das gilt umso mehr, wenn die Arbeit früher vielleicht mit einer nativen Applikation geleistet wurde. Die Nachfrage nach offlinefähigen Webapplikationen steigt. Die technischen Möglichkeiten gibt es heute schon. So können alle aktuellen und gängigen Browser zumindest einmal grob erkennen, ob das Gerät online oder offline ist. Und auch die Mittel zum lokalen Zwischenspeichern von Daten sind durchgängig vorhanden. Microsoft hat mit dem Internet Explorer 9 gut Land gewonnen, mit der neuen Version 10 holt der IE zum Mitbewerb auf. Taktgebend bleiben allerdings Chrome und Firefox, die allein durch ihr abweichendes Release-Modell viel schneller (re-)agieren können. Früher oder später wird sich Microsoft diesem Konzept wohl auch ergeben. Persönlich glaube ich, dass in fünf, vielleicht maximal zehn Versionen das Konzept der Software-Hauptversionen ohnehin weitgehend überholt sein wird und wir schlicht mit der jeweils aktuellen Ausgabe des Produkts arbeiten werden. Versionsnummern bleiben dann vielleicht etwas für technikverliebte Menschen wie uns Entwickler. Welche HTML5-Funktionen nutzen Sie bereits? Schreiben Sie mir! [bl] [1] D etecting offline status in HTML 5, [2] P resentation HTML5 Rocks, [3] A simple todo list using HTML5 IndexedDB, [4] WHATWG, [5] H TML Living Standard (Spezifikation), [6] HTML5 Test, [7] S pecgraph, HTML5 Spezifikations-Übersicht von Peter Kröner,