Offline WebAnwendungen unter HTML5

	Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Hamburg
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	HTML 5
Autor(en):	Rodion Sidorencov, Matthias Kirchner
Studienzeitmodell:	Abendstudium
Semesterbezeichnung:	WS10
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:	31.01.2011
Abgabetermin:	13.01.2011

Aus Winfwiki

Wechseln zu: Navigation, Suche

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Name des Autors / der Autoren:	Rodion Sidorencov, Matthias Kirchner
Titel der Arbeit:	"Offline Webanwendungen unter HTML5"
Hochschule und Studienort:	FOM Hamburg

Inhaltsverzeichnis

1 Abkürzungsverzeichnis
2 Abbildungsverzeichnis
3 Tabellenverzeichnis
4 Einleitung
5 Grundlagen
6 HTML 5
- 6.1 Anwendungsgebiete
- 6.2 Funktionsübersicht
7 Schlussbetrachtung
8 Fußnoten
9 Literatur- und Quellverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
API	Application Programming Interface
AMASS	Ajax Massive Storage System
CEO	Chief Executive Officer
CSS	Cascading Style Sheets
DB	Database
DHTML	dynamic HTML
DOM	Document Object Model
GUI	Graphical User Interface
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Protocol
kb	Kilobyte
LSO	Local Shared Object
mb	Megabyte
MIME	Multipurpose Internet Mail Extensions
PC	Personal Computer
PDA	Personal Digital Assistant
SQL	Structured Query Language
URL	Uniform Resource Locator
UTF-8	8-bit UCS Transformation Format
WAN	Wide Area Network
WWW	World Wide Web
XML	eXtensible Markup Language

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	HTML5
2	HTML5 Struktur
3	Historische Entwicklung
4	HTML5 Manifest
5	404 Error

3 Tabellenverzeichnis

Tab.-Nr. / Link	Bezeichnung
1	Event Handler Übersicht
2	Auflistung der existierenden Events
3	Browserunterstützung von "HTML5 storage"
4	Eigenschaften der "handle_storage" Funktion

4 Einleitung

Das Internet hat sich zu einer zentralen, länderübergreifenden Informations- und Kommunikationsschnittstelle entwickelt. Doch ist die Informationsbeschaffung und die Kommunikation untereinander nicht das Einzige, was das Internet heutzutage bietet. Das Internet stellt mittlerweile Applikationen für jeden Zweck bereit, ohne dass diese auf dem Rechner installiert werden müssen. Heutzutage ist es möglich online Videos anzuschauen, Steuererklärungen zu machen und sogar online zu spielen.

Bei Neu- und Weiterentwicklung der Applikationen wandert die Priorität mehr in Richtung Web -Applikationen anstatt der klassischen Client-Applikationen. Diese laufen zentralisiert ab, verbrauchen meistens weniger Ressourcen beim Anwender, da der Server einen Teil der Berechnungen übernimmt und setzten seit HTML5 nichts als einen Web-Browser beim Anwender voraus.

Jedoch hat die Entwicklung in Richtung der zentralisierten Bereitstellung von Web– Anwendungen einen wesentlichen Nachteil. Bricht die Internetverbindung zusammen oder wird diese gekappt, so ist eine Web-Applikation nicht erreichbar und kann nicht mehr ausgeführt werden. Hierbei können wichtige Daten verlorengehen.

Bei Videos oder Spielen ist dies nicht relevant, da die Erreichbarkeit dieser nicht kritisch ist und bei Wiederherstellung der Verbindung die jeweilige Aktion wieder fortgesetzt werden kann. Bei unternehmenskritischen Anwendungen ist dies jedoch nicht nur ärgerlich, sondern auch sehr kostenintensiv, da Arbeitsschritte mehrfach ausgeführt werden müssen und somit mehr Zeit und Resourcen verbrauchen. Aus diesem Grund bietet HTML5 einen vollständigen Offline Modus für Applikationen.

5 Grundlagen

Um die die Technologie von HTML5-Web-Anwendungen verstehen zu können, ist es notwendig, zuerst einen allgemeinen Überblick über die Funktionalität zu bekommen. Dieser Überblick wird mithilfe dieses Dokuments vermittelt, ebenso gibt das Dokument einen Einblick in die Historie der technischen Entwicklung. Anschließend wird in den Folgekapiteln tiefer in die Materie eingestiegen.

5.1 Allgemeine Grundlagen

Wie bereits in der Einleitung erwähnt, bietet HTML5 einen vollständigen Offline Modus für Applikationen.^[1] Dies bedeutet, dass der Nutzer beim ersten Aufrufen einer Webseite bestimmte, von der Seite vorgesehene, Inhalte vorgeladen und gecached bekommt. Diese Inhalte können nicht nur Bilder, sondern auch ganze HTML – Seiten mit den dazugehörigen Scripten sein. Sollte der Benutzer anschließend die Webseite erneut aufrufen und bestimmte Inhalte anzeigen wollen, die er bis dahin noch nie benutzt hat, ist dies ohne weiteres möglich. Der Benutzer ist mit seinen Aktionen an der Offline Web Applikation keinesfalls eingeschränkt, sämtliche Änderungen, die er durchführt, werden lokal zwischengespeichert um anschließend, bei einer erfolgreichen Wiederverbindung zum Internet wieder zu synchronisieren. Wird das Offline Feature einer Web Anwendung konsequent und durchgängig implementiert, ist es für den Benutzer absolut gleichgültig, ob er sich in dem Moment des Aufrufes der Applikation Offline oder online befindet, ähnlich wie dies der bei einer herkömmlichen Client–Anwendung der Fall ist.

5.2 Technische Grundlagen

Eine Offline Web Applikation technisch kurz zu beschreiben ist nicht einfach, da die Technologie dahinter ein komplexes Gebilde ist. Um diese Thematik grob zu umschreiben kann man sagen, dass eine Offline Web Applikation eine Liste von URLs darstellt. Diese URLs zeigen auf HTML, CSS oder JavaScript Dateien, Bilder oder andere Ressourcen, die für die Web Applikation benötigt werden. Die Seite der Offline Web Applikation, die auf diese Liste zeigt nennt man Manifest Datei. Diese Manifest Datei an sich ist nichts anderes, als eine Textdatei, die überall auf dem Server liegen kann.

Beim Aufrufen der Offline-Web-Applikation liest der Browser die Manifest Datei. Aus dieser Datei holt er sich die Liste der URLs, lädt die entsprechenden Ressourcen runter und speichert sie lokal auf dem Client Rechner. Diese Ressourcen bleiben so lange gespeichert, bis sie sich auf dem Server ändern. Es gibt die Möglichkeit in der Manifest Datei Resourcen zu definieren, welche bei jedem Aufruf neu aus dem Internet geladen werden müssen. Die Aktualisierungen der Dateien kann die Applikation natürlich nur mitkriegen, wenn die Applikation online aufgerufen wird. Bei einem Offline Aufruf der Applikation, greift der Browser nur auf die lokal zwischengespeicherten Ressourcen zu.

Um diese Zustände zu unterschieden liefert die Applikation eine Property, die der Programmierer zu implementieren hat. Aus den Zuständen resultieren anschließend die zugehörigen Events, die ausgelöst werden. Auf diese Zustände und Events wird im Folgenden in den Kapiteln Browser State bzw. Events näher eingegangen.

5.3 Historische Entwicklung

Eine dauerhafte lokale Speicherung ist heutzutage noch die Königsdisziplin der nativen Client-Anwendungen. Sie haben einen großen Vorteil im Vergleich zu bisherigen Web Applikationen: sie setzen auf einem Betriebssystem auf, welches eine Abstraktionsschicht zum Speichern und wiederabrufen von applikationsspezifischen Daten zur Laufzeit zu Verfügung stellt. Diese Daten können in der Registry, in INI Dateien, XML Dateien oder anderen Orten gespeichert werden. Dies hängt von den Richtlinien bzw. Konventionen ab, die das Betriebssystem vorgibt. Wenn eine Client-Applikation eine Datenspeicherung erfordert, die über die Schlüssel und den dazugehörigen Werten, hinausgeht, gibt es auf dem Client die Möglichkeit ein eigenes Dateiformat zu erfinden, eine eigene Datenbankart oder viele weitere Möglichkeiten.

Die Web Anwendungen haben aus historischen Gründen keinerlei dieser Vorteile. Es gibt zwar Cookies zum dauerhaften Speichern von Daten, jedoch wurden diese in den Anfängen der Web Entwicklung erfunden und bieten einige gravierende Nachteile:

Cookies werden bei jedem http Request übertragen, verlangsamen somit unnötig die Web Anwendung in dem sie die gleichen Daten jedes Mal transferieren.
Cookies werden bei jedem http Request unverschlüsselt übertragen, es sei denn man verschlüsselt die gesamte Web Anwendung mit https.
Cookies haben eine Limitierung von 4kb, sind demnach groß genug um eine Anwendung zu verlangsamen, jedoch nicht groß genug um einen großen Nutzen für die Datenspeicherung zu bringen.

Daraus resultierend ergaben sich folgenden Anforderungen:

ein größerer Speicher , als 4kb, auf dem Client
ein persistenter Speicher, welcher über die Laufzeit der Web Applikation hinaus bestehen bleibt
der Speicherinhalt wird nicht zurück zum Server übertragen

Aus diesen Anforderungen ergaben sich mehrere Entwicklungen, die zwar Defizite in verschiedenen Bereichen aufwiesen, zeigten jedoch HTML 5 die Richtung.

Angefangen hat die Entwicklung mit der Firma Microsoft und dem dazugehörigen Browser Internet Explorer in der damaligen Version 5. Microsoft erfand während des großen Konkurrenzkampfes mit anderen Browsern, wie Netscape Navigator, viele Neuerungen, um sich ein Vorteil zu verschaffen. Dazu gehörten die sogenannten DHTML Behaviors. DHTML Behaviors sind Komponenten, mit denen HTML(4)- Standardseiten mit zusätzlichen Funktionen ausgestattet werden können.

Eins dieser Behaviors war „userData“. „userData“ erlaubte es den Webseiten bis zu 64kb Daten per Domäne zu speichern. Dies geschah in einer XML-basierten Struktur. Vertrauenswürdigen Domänen war es erlaubt das Zehnfache an Speicher zu benutzen. Dieser Wert konnte nicht angepasst werden.

Im Jahr 2002 führte Adobe zusammen mit Flash 6 ein neues Feature ein, welches einen unglücklichen Namen „Flash Cookies“ bekam. In der Flash Umgebung wird dieses Feature richtigerweise Local Shared Object (LSO) genannt. Dieses Feature erlaubt es Flash Objekten bis zu 100kb Daten pro Domäne lokal zu speichern.

Im Jahr 2005 erfand Brad Neuberg einen frühen Prototyp einer Flash-to-JavaScript Bridge, welche AMASS (Ajax Massive Storage System) genannt wurde. Diese war allerdings durch das damalige Flash Design limitiert. Eine Nachbesserung gab es erst mit Flash8 im Jahr 2006, als Flash ExternalInterface eingeführt hat. ExternalInterface ist eine Flash API, welche Kommunikation zwischen Java Script und Flash erlaubt. In diesem Zuge wurde AMASS umgeschrieben. Daraus resultierte das populäre Dojo Toolkit, welches zwar die Lösung mit 100kb pro Domäne aufgriff, diese aber um die Funktionalität erweiterte, die Größe durch den Benutzer bei Bedarf vergrößern zu lassen.

Im Jahr 2007 fügte Google mit Gears einen Beitrag zum Thema Offline Web Applikationen hinzu. Gears ist ein Open Source Browser -Plugin, welches dem Browser erweiterte Funktionalitäten verleiht, unter anderem auch eine API zu Zugriff auf eine eingebettete SQL Datenbank, basierend auf SQL Lite. Dadurch ist es möglich größere Datenmenge in dieser Datenbank zu speichern. Am 19. Februar 2010 stellte Google die Entwicklung von Gears ein, um die Funktionen für HTML 5 bereitzustellen.

Parallel dazu versuchte man im oben erwähnten Dojo Toolkit^[2] die verschiedenen Funktionalitäten zentral über eine Schnittstelle anzusprechen. Diese Lösung ist trotz autodetect der jeweiligen Plugins nicht zufriedenstellend, da diese radikal unterschiedlich sind, auf verschiedenen Browser unterschiedlich reagieren und jeweils einen andere User Experience mit sich bringen .

An genau dieser Stelle setzt HTML 5 an. HTML 5 bietet eine standardisierte und browserübergreifende API, die nativ, ohne jegliche Plugins, im Browser implementiert ist.

6 HTML 5

6.1 Anwendungsgebiete

Die Anwendungsgebiete der Offline Web Applikationen sind vielfältig. Zunächst erweitert die Offlinefähigkeit der Web Applikationen den Einsatzgebiet herkömmlicher Web Applikationen. Dies bedeutet also, dass die Bereiche, in denen die Web Applikationen bereits bestand haben weiterhin beibehalten und erweitertet wird. Ein Beispiel dafür wäre Web Mail. Web Mail ist ein weit verbreiteter Standard, man hat als Nutzer von überall auf der Welt Zugriff auf seine E-Mails, die Voraussetzung dafür ist allerdings ein Internetzugang. Um jedoch auch Offline diesen Zugriff zu gewährleisten werden heutzutage E-Mail Programme, die nativ auf dem Client laufen und die E-Mails bereits heruntergeladen haben, wie Microsoft Outlook, benötigt. Mit HTML5 Offline Web Anwendungen, wäre das cachen der Emails unproblematisch, sodass der Zugriff auf diese auch Offline geschehen könnte.

Ein weiteres Anwendungsgebiet für Offline Web Applikationen wären Client Applikationen, die nur aus dem Punkt noch nativ auf dem Client laufen, da diese immer verfügbar sein müssten. Ein Beispiel dafür wäre eine Textverarbeitungsapplikation. Die komplette Funktionalität einer Textverarbeitungsapplikation kann man heutzutage auch als Web Applikation abbilden, was Microsoft beispielsweise mit Office 2010 Web Apps vorgeführt hat. Jedoch braucht man für diese noch durchgehend einen Netzwerkzugriff. Dieses wäre mit der HTML5 Technologie nicht mehr notwendig, sodass man auch Offline im Web Browser seine Briefe verfassen könnte.

Als drittes und immer wichtiger werdendes Anwendungsgebiet sind die Mobilen Web Applikationen für z.B. Apples IOS oder Googles Android. Die Browser, sowohl unter IOS, als auch unter Android, unterstützen HTML5. Zwar ist man mit diesen Geräten dauerhaft Online, jedoch ist der Netzausbau nicht immer gegeben oder performant, weiterhin sind momentan die Roaming Gebühren im Ausland zu hoch. An dieser Stelle würde die HTML5 Technologie die User Experience deutlich erhöhen, indem es in Gebieten mit gutem Netzausbau die Inhalte cached und sie in Gebieten mit schlechtem Netzausbau nur noch darstellen muss.

In naher Zukunft werden die Einsatzgebiete von Web Applikationen wachsen, wenn sie performanter werden und immer mehr Client Anwendungen ablösen, die Offline Fähigkeit dieser erweitert die Einsatzgebiete. Langfristig kann man prognostizieren, dass die Web Applikationen die Client Applikationen ganz ablösen werden.

6.1.1 Anforderungen an Offline Webanwendungen

Da die Offline Webanwendungen, weitestgehend die herkömmlichen Client Anwendungen ersetzen sollen bzw. eine vollwertige alternative bieten sollen, ergeben sich Anforderungen an deren Funktionalität und Sicherheit. Zu den Anforderungen an die Funktionalität zählt in erster Linie die User Experience, eine Web Anwendung wird nicht als alternative akzeptiert, wenn die User Experience schlechter als die der herkömmlichen Anwendung ist.

Eine weitere Anforderung der Funktionalität ist die Performance der Anwendung, der Anwendung sollte keinesfalls merklich langsamer laufen^[3], als eine Client Applikation. Aus der Performance resultierende Anforderung ist auch natürlich die minimale Lasterzeugung und Bandbreitenverbrauch. Steigen die Hardwarekosten durch Auslagerung einer Anwendung zentral auf einen Server immens, rechnet sich ein Business Case trotz der Vorteile von Web Anwendungen nicht. Ebenso gilt dies auch für den Bandbreitenverbrauch, die eine Web Applikation erzeugt, sei es durch den Betrieb oder durch das Cachen der Ressourcen. Um den Bandbreitenverbrauch so gering, wie möglich zu halten, empfiehlt es sich auch Technologien, wie Microsofts Branch Cache Technologie zuzugreifen, um das Cachen über WAN so gering, wie möglich zu halten und somit die WAN Bandbreitenkosten im Rahmen zu halten.

Neben dem funktionalen Aspekt sollte der Sicherheitsaspekt^[4] keinesfalls außer Acht gelassen werden. Durch Zentralisierung von Ressourcen erhöhen sich die Anforderungen an Sicherheit, da es statt vieler einzelner Angriffsstellen mit begrenzten Ressourcen nun eine zentrale Angriffsstelle mit sämtlichen Ressourcen gibt. Diese Stelle verteilt zentral an alle Clients Daten zum Cachen. Ist diese Stelle kontaminiert erfolgt die Verteilung schnell. Trotz der erhöhten Gefahr ist es für den Administrator leichter eine Stelle abzusichern, anstatt sämtlicher Clients.

6.1.2 Nutzen für den Aussendienst

Im vorherigen Kapitel wurde beschrieben, welche Anforderungen an eine Offline Webanwendung gestellt werden. Welchen weiteren Nutzen diese Anwendungen haben lässt sich feststellen, wenn zum vergleich die klassichen Client- und Serverbasierten Anwendungen herangezogen werden. In den Aussendienstbereichen vieler Unternehmen wurden bisher verschiedene arten von Applikationen verwendet. Häufig wurde eine Clientseitig installierte Software ausgeführt, mit der ohne bestehende Internetverbindung Daten erfasst werden konnten, die dann bei einem Verbinden mit dem Firmennetzwerk auf die Server übertragen wurden. Hierbei ist ein Problem, dass der Nutzer der Applikation keinerlei Zugriff auf vorhandene Daten in dem Firmennetzwerk besitzt und somit nicht immer die aktuellsten Informationen besaß.

Um diesen Umstand zu ändern, wurden Webapplikationen entwickelt, die der Client direkt im Firmennetzwerk über den Browser ausführen kann. Damit hat ein mobiles System mit einer konstanten Internetverbindung die Möglichkeit immer mit aktuellen Datenbeständen zu arbeiten. Tritt nun der Fall auf, dass ein Aussendienstmitarbeiter in einer Gegend unterwegs ist, die eine instabile oder garkeine Internetverbindung ermöglicht, dann kann die auf dem Server gelegene Webanwendung garnicht ausgeführt werden. Und genau hier setzt die Offline Webpplikation an. Gemäß dem Fall, dass während der Nutzung der Webanwendung die Internetverbindung fehlschlägt, würde der Browser erkennen, dass keine neuen Daten gecachet werden und somit würde die Verarbeitung komplett Offline stattfinden, solange bis wieder eine Interneverbindung hergestellt werden kann.

Der Aussendienstmitarbeiter hat also die Möglichkeit mit einer aktuell gehaltenen, vom Server bereitgestellten Webapplikation zu arbeiten, die im Falle eines Verbindungsabbruchs weiterhin ausgeführt werden kann, ohne dass die Verarbeitung abgebrochen werden muss. Ein weiterer Vorteil der Offline Webanwendung ist die Versionssicherheit, welche durch die serverseitige Verbreitung gegeben ist. Im Gegensatz zu den lokal installierten Anwendungen, welche über zeitaufwändige Ausrollverfahren bereitgestellt werden müssen, geschiet dies automatisiert und standardisiert über den Web Server. Dies ist ein deutlich günstigeres Verfahren, als das Ausrollen einer Client-Applikation. Um dem User eine gleichwertige Experience, wie beim Verteilen von Web Anwendungen, zu bieten muss eine teure Verteilsoftware, wie Microsoft System Center Configuration Manager erworben werden und eine unattended Installation der zu verteilenden Software gescriptet werden.

6.1.3 Netzinstabilität

In der herkömmlichen Weblandschaft war eine konstante Internetverbindung eine Grundvoraussetzung für funktionierende Applikationen. Wenn eine unregelmäßge Internetverbindung besteht, ist es möglich, dass eine in jenem Moment aufgerufene Website funktioniert und im darauffolgenden nicht mehr. Um dieses Problem zu umgehen wurde mit HTML5 der sog. "application cache" eingefügt. Dieser cache ist eine Sammlung verschiedener Ressourcen, und dient im Zusammenspiel mit dem "cache host" dazu bei einer unterbrochenen Internetverbindung die bisher geladenen Resourcen zwischenzuspeichern und lokal auszuführen. Das führt bei dem User dazu, dass ein großteil der Funktionalität einer Website oder Webapplication auch im Offline Modus verfügbar ist. Der Aufbau und die Funktionsweise des "application cache" wird in einem späteren Kapitel weiter erläutert.

6.2 Funktionsübersicht

HTML 5 kommt mit vielen neuen Funktionen daher. Die für Offline Webanwendungen relevanten Punkte werden im folgenden beschrieben.

6.2.1 Cache manifest

Die Grundlage für die Funktionsweise einer Offline Webanwendung besteht in einer Manifest Datei, welche alle Dateien auflistet, die für die Ausführung der Anwendung notwendig sind. Diese Dateien werden dann für den Browser kenntlich gemacht, damit dieser dafür sorgt, dass lokale Kopien dieser Dateien erstellt werden. Dadurch wird das ausführen der Anwendung im Offline Modus ermöglicht.

Ein cache manifest wird unter Verwendung des dazugehörigen MIME-Types^[5] "text/cache-manifest" erstellt, welcher unten stehende Syntax vorgibt.

Das application cache manifest ist ein UTF-8 enkodiertes Textdokument, welches Zeilenbasiert befüllt wird.

Die eingetragenen Zeilen müssen eine der Folgenden sein:

- Eine Leerzeile
- Ein Kommentar
- Ein section header
- Ein gültiges Format der jweiligen Sektion

Sektionen können doppelt vorkommen oder auch leer sein.

6.2.2 Cache manifest Syntax

Die cache manifest Syntax ist nicht sehr komplex. Zu allererst muss "CACHE MANIFEST" in die Datei geschrieben werden. Dadurch wird das Dokument als cache manifest erkannt. Anschließend müssen alle, für die Anwendung relevanten, Resourcen eingetragen werden^[6].

Dies geschieht in drei Sektionen. Zum einen gibt es die "CACHE:" Sektion, welche dafür sorgt, dass alle hier befindlichen Dateien vom Browser gespeichert werden, um auch ohne bestehende Internetverbindung beim ausführen der Anwendung vorhanden sind. Die "cache" Sektion wird auch "explicit section" genannt, hier werden die "explicit entries" eingetragen, welche auch als "foreign" markiert werden können. Das bedeutet, dass die Einträge ein Manifestattribut besitzen, dieses sich jedoch nicht in diesem cache manifest befindet.

Eine weitere Sektion ist Folgende, "FALLBACK:" wird verwendet, um dort eine Fehlerseite zu definieren, die aufgerufen wird, solange der Benutzer Offline ist.

Weiterhin gibt es die "NETWORK:" Sektion, welche als online whitelist dient. Die hier eingetragenen Resourcen werden immer über das Netzwerk geladen, auch in dem Fall, dass keine Netzwerkverbindung besteht. Dann schlägt der Aufruf der Dateien fehl. Ein Beispiel für eine Ressource, die in der Network Section einzutragen ist, ist ein Besucherzähler, da dieser im Offline Modus keinen Sinn macht. In der "network section" kann ein "online whitelist wildcard flag" gesetzt werden, wenn dies der Fall ist, dann bedeutet es, dass Zugriffe auf Resourcen auf anderen Webseiten nicht blockiert werden.

Das "CACHE:"-tag muss nicht zwingen in die Manifest Datei geschrieben werden, die zu cachenden Resourcen können auch direkt unter dem header platziert werden. In das cache manifest können absolute Pfade und sogare absolute URLs eingetragen werden. Kommentare können mit einer vorangestellten Raute (#) eingefügt werden.

Die im cache manifest referenzierten Seiten werden gecached, wenn auf diese zugegriffen wird, so dass bei einem erneuten Zugreifen die Seite direkt aus dem cache geladen wird. Die Seiten werden solange im cache gehalten, bis das Manifest sich geändert hat. Ist das der Fall, werden alle Resourcen neu gecached.

6.2.3 Application cache

Der "application cache" ist ein Verbund an gespeicherten Resourcen. Er besteht aus den Dateien, welche im Manifest eingetragen sind und für das Ausführen der Anwendung notwendig sind. Diese Einträge können Webseiten im HTML-Format, Stylesheets, Java Script Dateien und viele weitere beinhalten.

Jeder "application cache" hat einen "completeness flag", welcher auf "complete" oder "incomplete" steht. Dieses Flag gibt an, ob der "application cache" vollständig heruntergeladen wurde und somit die Offline Lauffähigkeit der Anwendung möglich ist.

Aus mehreren "application caches" wird eine sog. "application cache group" gebildet, welche durch eine absolute URL-Angabe im Manifest spezifiztiert wird. Die "application caches" in einer Gruppe werden chronologisch sortiert, und jeder "application cache" der nach einem anderen erstellt wurde ist neuer. Nur der neuste "application cache" in einer application cache group kann das "completeness flag" auf incomplete stehen haben. Alle anderen caches sind immer complete.

Jede "application cache group" hat einen "update status", welcher immer einen von drei Status aufweisen muss. Die Status sind, "idle", "checking", "downloading". Der "application cache" in einer "application cache group", welcher als letzter den Status "complete" erreicht hat, wird auch "relevant application cache" genannt.

Es kann sein, dass mehrere "application caches" in verschiedenen "application cache groups" die gleiche Resource beinhalten, nämlich wenn verschiedene Manifeste die Resource referenzieren. Nun kann, falls so konfiguriert, der "user agent" automatisch von einer Liste von "relevant application caches" die, am ehesten vom Benutzer gewünschte, Resource auswählen. Dabei wird überprüft, welcher "application cache" zuletzt aktualisiert wurde und welcher "application cache" zuletzt verwendet wurde, um die Resource anzuzeigen, von der der Benutzer auf die neue Resource zugreifen wollte, und welchen "application cache" der Benutzer bevorzugt.

6.2.3.1 Application cache herunterladen/aktualisieren

Der "application cache" ist eine Grundvoraussetzung für die Offline Web applications. Hierbei ist es wichtig zu wissen, wann die, in dem cache manifest eingetragenen, Resourcen heruntergeladen oder aktualisiert werden müssen. Der anzustoßende Prozess wird "application cache download process" genannt und gibt an, in welcher Reihenfolge welche Tasks, aufgrund der vorhandenen Informationen, ausgeführt werden müssen. Die kommenden Schritte werden asynchron ausgeführt und können somit parallel laufen.

Während der Aktualisierung des "application cache" kann der "user agent" den Status der Aktualisierung dem Benutzer mitteilen. Jedoch sollte keine absolute Fortschrittsangabe gemacht werden.

Vor dem Start des "application cache download process" kann die Erlaubnis für die Aktion vom Benutzer erfragt werden. Dieser Schritt ist optional und kann verhindern, dass eine weitere Verarbeitung stattfindet. Entfällt dieser Schritt oder ist erfolgreich durchgeführt werden automatisch die folgenden Unterschritte ausgeführt.

Die Unterschritte sind davon abhängig, ob eine Absolute URL zur Identifizierung eines cache manifest vorhanden ist oder ob eine "application cache group" vorhanden ist. Dies dient dazu die korrekte "application cache group" zu ermitteln, zu welcher der "application cache" hinzugefügt werden soll.

Wenn die Schritte durch einen "cache host" ausgeführt wurden, dann wird überprüft, welchen Status die cache group besitzt. Ist der Status "checking" oder "downloading" dann wird ein load-task gestartet, der ein einfaches Event "checking" im ApplicationCache singleton ausführt. Hierbei wird im normalfall eine Nachricht an den Benutzer durch den "user agent" ausgegeben.

Wenn der Status der cache group "downloading" ist, dann wird ebenso ein load-tastk ausgeführt, welcher das Event "downloading" im ApplicationCache singleton ausführt. Hier wird auch eine Nachricht an den Benutzer ausgegeben.

Wenn kein "cache host" beim Ausführen gefunden wurde, und der Status der "cache group" entweder "checking" oder "downloading" ist, dann wird der aktuelle "application cache download process" abgebrochen, da schon ein update durchgeführt wird.

Für jeden "cache host", der einen "application cache" in der "cache group" aufweist, wird ein load-task in eine queue gestellt. Hat nun die "cache group" bereits einen "application cache", dann ist dies ein "upgrade attempt" wenn nicht, dann ist es ein "cache attempt".

Im zweiten Fall wird nun das Manifest von der "manifest URL" geladen und versucht zu parsen. Wenn beim Zugriff auf das Manifest ein 404 (Website wurde nicht gefunden) oder 410 (Website existiert nicht mehr) auftritt werden wieder weitere Unterschritte durchgeführt.

Die "cache group" wird als "obsolete" geflagt, da sie keine eigenen Nutzen mehr hat. Die Resourcen sind schon mit anderen "application caches" verknüpft. Für jeden "cache host" wird ein Task gestartet, der das Event "obsolete" im ApplicationCache singleton ausführt. Alle "application caches" in der "cache group" welche auf "incomplete" stehen, werden gelöscht. Anschließend wird der Status der "cache group" auf "idle" gesetzt und der "application cache download process" wird abgebrochen.

Schlägt das Laden des Manifest auf eine andere Weise fehl, dann werden die "cache failure steps" ausgeführt. Diese regeln das Verhalten im Fehlerfall und sorgen dafür, dass alle anstehenden Tasks bearbeitet oder kontrolliert beendet werden.

Wenn das Manifest aktualisiert werden soll, dann wird byte-weise überprüft, ob das Manifest identsich zu dem Manifest im neusten "application cache" ist. Ist das der Fall, dann wird der cache der neueste "application cache" in der "cache group", ausserdem wird die "task list" geleert. Für jeden der vorhandenen "master entries" wird gewartet, dass deren tasks beendet oder abgebrochen sind. Danach wird für jeden "cache host" das Event "noupdate" im ApplicationCache singelton gestartet. Abschließend wird der "cache group" Status auf "idle" gesetzt und der "application cache download process" wird abgebrochen.

Wenn das geladene Manifest ein neues ist, dann wird in der "application cache group" ein neuer cache angelegt, der den Status "incomplete" aufweist. Alle Einträge in der "application cache group" werden mit dem Dokument des neuen "application cache" verknüpft. Anschließend wird der Status der "application cache group" auf "downloading" gesetzt. Ebenso wird für jeden "cache host" der "application cache group" das Event "downloading" in dem ApplicationCache singleton gestartet.

Die "file list" wird geleert und alle URLs in den "explicit entries" die beim Parsen des "application manifest" gefunden werden, werden in die "file list" mit dem Flag "explicit entry" übertragen. Das gleiche passiert mit den Einträgen unter "fallback entries", diese werden dann entsprechend mit dem Tag "fallback entriy" gekennzeichnet.

Für jede URL in der "file list" wird überprüft ob diese auf eine veraltete und nicht mehr verwendete Resource hinweist. Die als veraltet erkannten Resourcen werden aus dem "application cache" entfernt. Wenn die URL auf eine Resource zeigt, dann wird anhand der Aufteiling in explicit, fallback und master entry festgestellt wie mit der Resource zu verfahren ist.

Wenn alle URLs in der "file list" abgearbeitet wurden, dann wird der Status des "application cache" auf "complete" gesetzt. Anschließend wird die "task list" geleert. Falls es ein "cache attempt" ist, wird für jeden "cache host" das Event "cached" in dem ApplicationCache singleton gesetzt. Wenn ein "update attempt" vorliegt, dann wird für jeden "cache host" das Event "updateready" in dem ApplicationCache singleton gesetzt.

Zuletzt wird der "update status" der "application cache group" auf "idle" gesetzt.

Die "user agents" können den "application cache download process" im Hintergrund für jeden "application cache" ohne "cache host" durchführen. Dies sorgt dafür, dass alle caches auf dem aktuellen Stand gehalten werden, auch bevor der Benutzer die Seite besucht.

6.2.3.2 Auswahlverfahren des application cache

Für das Auswählen des korrekten "application cache" gibt es einen Selektierungsalgorythmus. Dieser wird bei jedem Aufruf eines Dokumentes ausgeführt. Dabei wird das Dokument und optional eine Manifest URL übergeben. Daraufhin muss der "user agent" jeweils den ersten zutreffenden der folgenden Schritte ausführen.

In dem Fall, dass eine Manifest URL und ein Dokument von einem "application cache" und die URL des Manifest der "application cache group" nicht die gleiche wie die Manifest URL sind, wird der der Eintrag der Resource von der das Dokument gelesen wurde als "foreign" markiert. Daraufhin wird die derzeitige Navigation vom Anfang des "navigation algorithm" neu gestartet. Dabei werden alle Veränderungen, die als Teil der Initialladung durchgeführt wurden, wieder rückgägig gemacht. Der "user agent" sollte hierbei den Benutzer darauf hinweisen, dass eine Inkonsistenz zwischen dem cache manifest und den Metadaten des Dokuments herrscht.

Ein anderer Fall ist der, dass der "application cache", aus welchem das Dokument geladen wurde, noch existiert. Hierbei wird das Dokument mit dem "applicaction cache" verknüpft von dem es geladen wurde. Im Hintergrund wird der "applicaction cache download process" für die "application cache group" des "application cache" angestoßen.

Wenn das Dokument über ein HTTP GET^[7] oder gleichartige Funktionalität geladen wurde und eine Manifest URL, die die gleiche Herkunft wie das Dokument hat, vorhanden ist, dann wird im Hintergrund der "applicaction cache download process" für die Manifest URL mit dem Dokumenten als "cache host" angestoßen.

In jedem anderen Fall ist das Dokument mit keinem "application cache" verbunden. Wenn eine Manifest URL existiert, dann kann der "user agent" berichten, dass diese ignoriert wurde.

6.2.3.3 Application cache API

Um mit dem ApplicationCache zu arbeiten benötigt man gewissen Schnittstelleninformationen. Das Interface des ApplicationCache besitzt folgende Statuswerte^[8]:

- const unsigned short UNCACHED = 0;
- const unsigned short IDLE = 1;
- const unsigned short CHECKING = 2;
- const unsigned short DOWNLOADING = 3;
- const unsigned short UPDATEREADY = 4;
- const unsigned short OBSOLETE = 5;
- readonly attribute unsigned short status;

Es besitzt die Methoden:

- void update();
- void swapCache();

Und die Events:

- attribute Function onchecking;
- attribute Function onerror;
- attribute Function onnoupdate
- attribute Function ondownloading;
- attribute Function onprogress;
- attribute Function onupdateready;
- attribute Function oncached;
- attribute Function onobsolete;

Folgende Implementierungsformen müssen beachtet werden.

$c a c h e = w i n d o w . a p p l i c a t i o n C a c h e$

(In einem Fenster ausgeführt)Gibt das ApplicationCache Objekt zurück, das sich im aktiven Dokument des Fensters befindet.

$c a c h e = s e l f . a p p l i c a t i o n C a c h e$

(In einem "shared worker" ausgeführt) Gibt das ApplicationCache Objekt zurück, das sich im derzeitigen "shared worker" befindet.

$c a c h e . s t a t u s$

Gibt den derzeiteigen Status des ApplicationCache Objekts zurück.

$c a c h e . u p d a t e ()$

Startet den "application cache download process" und wirft eine "INVALID_STATE_ERR" Fehlermeldung, wenn kein "application cache" vorhanden ist.

$c a c h e . s w a p C a c h e ()$

Wenn ein neuerer "application cache" vorhanden ist führt diese Methode dazu, dass zu dem neuren cache gewechselt wird und wirft eine "INVALID_STATE_ERR" Fehlermeldung, wenn kein "application cache" vorhanden ist.

Bei der Statusabfrage liefert die Methode einen numerischen Wert zurück, der den Status des ApplicationCache Objektes darstellt.

Der Wert 0 (uncached) gibt an, dass der "cache host" von dem ApplicationCache Objekt keinem "application cache" zugeordnet ist.

Der Wert 1 (idle) gibt an, dass der "cache host" mit einem "application cache" verknüpft ist, dessen "application cache group" den "update status" idle besitzt und, dass der "application cache" der neueste cache in der cache group ist. Dabei ist die "application cache group" nicht als obsolete markiert.

Der Wert 2 (checking) gibt an, dass der "cache host" mit einem "application cache" verknpüft ist, dessen "application cache group" den "update status" checking besitzt.

Der Wert 3 (downloading) gibt an, dass der "cache host" mit einem "application cache" verknpüft ist, dessen "application cache group" den "update status" downloading besitzt.

Der Wert 4 (updateready) gibt an, dass der "cache host" mit einem "application cache" verknpüft ist, dessen "application cache group" den "update status" idle besitzt und diese nicht als obsolete markiert ist. Ausserdem ist der "application cache" nicht der neuste in der Gruppe.

Der Wert 5 (obsolte) gibt an, dass der "cache host" mit einem "application cache" verknpüft ist, dessen "application cache group" als obsolte markiert ist.

Abschließend noch eine Übersicht über die Event handler, welche von allen Objekten unterstützt werden müssen die das ApplicationCache interface verwenden.

Eventhandler	Event handler event type
onchecking	checking
onerror	error
onnoupdate	noupdate
ondownloading	downloading
onprogress	progress
onupdateready	updateready
oncached	cached
onobsolete	obsolete

6.2.4 Events

Wenn eine Webseite aufgerufen wird, die ein Manifest besitzt, dann wird der Browser versuchen den cache zu aktualisieren. Dies geschieht, indem eine Kopie des Manifest vom Browser erstellt wird. Wenn sich das Manifest von einem vorhandenen Manifest der Seite unterscheidet, werden alle Resourcen erneut gecached.

Während dieses Vorgangs werden einige "Events" auf dem ApplicationCache Objekt ausgeführt, die dafür sorgen, dass der updatestatus des cache updates dem User bekannt gegeben werden kann.

6.2.4.1 Arten von Events

Die Events, welche beim cache update auftreten sind folgende: ^[9]

Event Name	Interface	Tritt auf, wenn...	Nächste Events
checking	Event	Der "user agent" prüft nach Updates oder versucht das Manifest zum ersten mal herunterzuladen. Dieses Event ist immer das erste in dieser Sequenz.	noupdate, downloading, obsolete, error
noupdate	Event	Das Manifest ist unverändert.	Letztes Event in der Sequenz.
downloading	Event	Der "user agent" hat ein Update gefunden und fängt es, oder die im Manifest eingetragenen Resourcen werden heruntergeladen.	progresss, error, cached, updateready
progress	ProgressEvent	Der "user agent" lädt die im Manifest hinterlegten Resourcen herunter.	progresss, error, cached, updateready
cached	Event	Die im Manifest hinterlegten Resourcen wurden heruntergeladen und die Anwendung ist nun zwischengespeichert.	Letztes Event in der Sequenz.
updateready	Event	Die im Manifest hinterlegten Resourcen wurden erneut heruntergeladen und das Skript kann "swapCache()" benutzen, um zum neuen cache zu wechseln..	Letztes Event in der Sequenz.
obsolete	Event	Das gefundene Manifest ist eine 404 oder 410 Webseite geworden, so dass der "application cache" gelöscht wurde.	Letztes Event in der Sequenz.
error	Event	Das Manifest hat sich nicht verändert, aber die Webseite die das Manifest referenziert konnte nicht erfolgreich heruntergeladen werden. \| Ein schwerwiegender Fehler ist, beim laden der im Manifest hinterlegten Resourcen, aufgetreten. \| Das Manifest hat sich während des updatevorgangs verändert.	Der "user agent" wird versuchen die Dateien erneut zu laden.

6.2.5 HTML 5 storage

Der Name „HTML 5 Storage“ ist nicht homogen. Die offizielle Bezeichnung für die HTML 5 Storage ist „Web Storage“. Diese wird Browserübergreifend aber auch nicht einheitlich benutzt. Weitere Namen für die Web Storage wären „Local Storage“ oder auch „DOM Storage“. Diese Heterogenität stellt den Entwickler vor einige Probleme, die später in diesem Kapitel erläutert werden. Im Folgenden wird ausschließlich der Begriff zur einheitlichen Namensgebung ausschließlich der Begriff „HTML 5 Storage“ verwendet.

„HTML 5 Storage“ ist, vereinfacht gesagt, ein Verfahren, welches den Web Seiten ermöglicht spezifizierte Schlüssel mit den dazugehörigen Werten lokal, innerhalb des Browsers zu speichern. Dies geschieht ähnlich dem Verfahren der Speicherung von Daten in Cookies, ist aber dafür ausgelegt größere Dateimengen speichern und mit diesen umgehen zu können. Dabei bleiben die Daten auch nach dem Schließen der Web Seite, schließen des Tabs oder gar des ganzen Browsers bestehen. Der Unterschied zu den Cookies besteht aber darin, dass die Daten nicht die strenge Größenlimitierung, wie Cookies haben und an den Server niemals zurückgemeldet werden, da dies performance- und bandbreitenintensiv ist. Die „HTML 5 Storage“ bleibt auf dem Rechner und kann von der Webseite nach dem Laden benutzt werden.

Die Funktionalität der „HTML 5 Storage“ ist nativ im Browser implementiert und ist nicht, wie in Kapitel „historische Entwicklung“ beschrieben, von einem Addon abhängig.

Alle heutzutage gängigen Internet Browser unterstützen in der aktuellen Version bereits die „HTML 5 Storage“ Funktionalität.

Browser	Internet Explorer	Mozilla Firefox	Apple Safari	Google Chrome	Opera	iPhone	Android
Unterstützung ab Version	8.0	3.5	4.0	4.0	10.5	2.0	2.0

Jedoch setzt nicht jeder Anwender, insbesondere Firmen, die jeweils aktuelle Browser Version ein, deshalb ist es notwendig als Entwickler zu überprüfen, ob die „HTML 5 Storage“ vom Browser unterstützt wird. Dies kann mit der „localStorage“ - Property des „global window objects“ überprüft werden. Unterstützt der Browser „HTML 5 Storage“ nicht ist diese Property nicht vorhanden. ^[10]

function supports_local_storage()

{

Return (`localstorage` in window) && window[`localStorage`] !== null;

}

6.2.5.1 Änderungen in der HTML 5 Storage

HTML5 Storage basiert, wie bereits erwähnt, auf Schlüsseln mit den dazugehörigen Werten in Paaren. Unter dem Schlüsselnamen, unter dem man einen Wert gespeichert hat, ist dieser auf wieder aufzufinden.

Die Werte werden immer als Strings gespeichert, können aber alle vom Java Script unterstützen Datentypen, wie Integer, Float, Boolean, darstellen. Lediglich beim Wiederaufrufen von Daten muss der Datentyp bekannt sein, da dieser in das entsprechende Format zurückkonvertiert werden muss. Dafür werden Funktionen, wie parseInt() (Konvertierung von String zu Integer) oder parseFloat() (Konvertierung von String zu Float), bereitgestellt.

Um die Werte zu setzen wird die Funktion setItem() benutzt, diese erzeugt entweder einen neuen Eintrag oder ersetzt einen bereits vorhandenen. Dies geschieht ohne eine Exception auszugeben, dass dieser Bereits vorhanden ist.

Um die Werte wieder auszulesen wird die Funktion getItem() benutzt. Diese Funktion, genau wie die setItem() Methode gibt keinerlei Exceptions aus, ist der Schlüssel nicht vorhanden, wird null zurückgegeben.

Zum Beispiel:

localStorage.setItem(“Welt“, Hallo) ;

Mit diesem Code wird ein Schlüssel “Welt“, welcher den Wert Hallo hat erzeugt.

var welt = localStorage.getItem(“Welt“);

Mit diesem Code wird der Variablen welt, der Wert des Schlüssels “Welt“ zugeordnet.

Alternativ kann auch auf die setItem() und getItem() Methoden verzichtet werden. Stattdessen kann das localStorage Objekt als ein assoziatives Array angesprochen werden.

Zum Beispiel, können die oben genannten Codeschnipsel durch Folgendes ersetzt werden:

localStorage[“Welt“] = Hallo;

var welt = localStorage[“Welt“];

Entsprechend den getItem() und setItem() Methoden gibt es eine removeItem() Methode, die ein Schlüssel entfernt. Ist ein Schlüssel nicht vorhanden wird auch hier keine Exception ausgegeben, es passiert an der Stelle einfach nichts. ^[11]

6.2.5.2 Nachverfolgung der Änderungen

Es ist unter bestimmten Umständen sinnvoll die Änderungen am Storage nachzuverfolgen, sei es denn aus Debugging Gründen oder um bestimmte Transaktionen mitzuloggen. Um dies zu bewerkstelligen ist es notwendig einen EventListener einzurichten, welcher auf das Storage Event hört. Der Event wird dann bei setItem() oder removeItem() ausgelöst. ^[12]

window.addEventListener("storage", handle_storage, false);

Mit diesem Codeabschnitt wird beim Auslösen des Storage Events, die Funktion handle_storage() aufgerufen.

function handle_storage(e)

{

if (!e) { e = window.event; }

}

Beim Aufrufen der handle_storage Funktion ist das StorageEvent im window.event gespeichert, dieser wird nun einer Variable zugeordnet, die dann folgende Eigenschaften bekommt.

Eigenschaft	Typ	Beschreibung
Key	String	Der Name des Schlüssels, welcher verändert wurde
oldValue	Any	Der bisherige Wert (wenn verändert) oder null wenn neuerzeugt
newValue	Any	Der neue Wert oder null wenn Schlüssel entfernt
url	String	Die Seite die den Methodenaufruf durchgeführt hat

6.2.6 Eingeschränkte Funktionalität

Im Kapitel „Historische Entwicklung“ wurde auf Limitierungen verschiedensten HTML5 Vorgängertechnologien eingegangen. HTML5 hat selbst momentan Limitierungen die auf die Internet Browser zurückzuführen sind. Standardmäßig hat jeder aktuelle Browser 5mb Speicher für Offline Web Applikationen reserviert. Diese Größe ist in den üblichen Fällen ausreichend. Jedoch gibt es Sonderfälle, in welchen dieser Grenze schnell erschöpft ist. Da, wie bereits erwähnt, bei der Speicherung der Daten immer Strings verwendet werden, stößt diese Größe an ihre Grenzen, wenn viele Integer oder Gleitkommazahlen gespeichert werden müssen, da diese jeweils pro Ziffer als Charakter gespeichert werden.

Die Limitierung von 5mb wäre an sich kein Problem, wenn diese stufenlos durch Applikationen erweitert werden könnte. Dies ist heutzutage jedoch nicht der Fall. Wenn die Quota erschöpft ist, wird lediglich die Exception QUOTA_EXCEEDED_ERR ausgeben. Eine Erweiterung des Speichers kann anschließend nur durch eine Benutzerinteraktion angestoßen werden. Aber auch dies ist nicht Browserübergreifend einfach möglich. Nur der Opera Browser bietet eine GUI, mit welcher man die Quota pro Seite festlegen kann. Im Internet Explorer ist nur durch verändern einiger Registry Einträge oder durch das Setzen einer Policy möglich.

6.2.7 Fehleranalyse

Bei jeder Entwicklung kommt der Punkt, dass trotz vermeintlich richtiger Implementierung, die Funktionalität nicht so arbeitet, wie man sich vorstellt. Dabei ist es wichtig nicht nur den Fehler so schnell bzw. so effizient, wie möglich zu finden. Bei Offline Web Applikationen sind dabei einige Eigenarten zu beachten, die im Folgenden näher erläutert werden.

6.2.7.1 Browser state

Vor dem eigentlichen Debugging der Funktionalität ist es bei Offline Web Applikationen wichtig zu überprüfen in welchem Status der Browser sich befindet. Um dies zu bewerkstelligen gibt es eine Funktion, die wie folgt oder dem entsprechend auszusehen hat: ^[13]

function updateIndicator() {

document.getElementById('indicator').textContext = window.navigator.onLine ? 'online' : 'offline';

}

Dabei wird auf die Property des window-Objekts zugegriffen. window.navigator.online liefert zurück, ob eine Verbindung zu einem Netzwerk besteht. Diese Funktion sollte im <body onload> Kontext aufgerufen werden, um immer den aktuellen Status zu haben.

Doch, wie bereits erwähnt, liefert die Funktion zurück ob eine Verbindung zu einem Netzwerk besteht, dies stellt deshalb nicht sicher, ob eine Verbindung zum Internet vorhanden ist. Ist diese in einer Anwendung notwendig, muss dies mit einer selbstgeschriebenen Methode, die beispielweise ein Ping auf einen Server, von dem man ausgeht, dass er online ist, absetzt, sichergestellt werden.

6.2.7.2 Debugging

Das Debugging der Web Applikationen ist ein schwieriges Unterfangen. Wird auch nur eine Ressource aus der kompletten Web – Applikationen nicht ordnungsgemäß gecached, scheitert der ganze Prozess des cachens einer Web Applikation. Der Browser zeigt dabei eine Fehlermeldung an, die selten sprechend ist und zeigt somit nicht an, an welche Stelle das Problem besteht. Aus diesen Gründen kann der Debugging – Prozess sich frustrierend für den Programmierer darstellen.

Ein weiteres Problem beim Debugging sieht im ersten Moment, wie ein Browser-Bug aus, hängt aber damit zusammen, wie ein Browser überprüft, ob ein cache manifest sich verändert hat. Dieses Verfahren wird nicht spezifisch für Offline Web Applikationen angewandt, sondern für alle Web Ressourcen. Hierbei geht es um den folgenden Ablauf:

Mit dem Standard – http – Verfahren überprüft der Browser ob der cache manifest abgelaufen ist. Diese Informationen erhält der Browser von dem Web -Server. Dieser überträgt hierbei Meta- Informationen in den http Antwort Headern. Diese Meta-Informationen geben dem Browser die Auskunft darüber, wie das cachen der Inhalte zu erfolgen hat.
Wenn die Gültigkeit des cache manifests abgelaufen ist (dies wird an den http Headern abgelesen), erfragt der Browser bei Webserver ob es ein aktuelleres Paket gibt, wenn dies der Fall ist, wird die aktuelle Version runtergeladen. Um diesen Ablauf durchzuführen, stellt der Browser ein http Request, welcher die letzte Änderung des cache manifest enthält, welche aus dem http Response Header des Servers vom letzten Download stammt. Hat sich am cache manifest nichts geändert, antwortet der Server mit dem Status-Code 304 (not modified).
Wenn der Server aber denkt, dass seit dem letzten Request sich eine Veränderung ergeben hat, sendet er den Status-Code http 200 (OK), um anschließend die aktuellen cache Manifest Datei zuzusenden und die Übertragung mit dem neuen Last – Modified Datum zu beenden. Dies stellt sicher, dass die Übertragung beim nächsten Mal genau so funktioniert und die Dateien nur einmal runtergeladen werden müssen. Nach dem erfolgreichen Download des cache manifest Datei überprüft der Browser ob sich die Inhalte auf dem lokalen Cache sich von den Dateien in der cache manifest Datei unterscheiden, die Dateien, die sich nicht verändert haben werden somit nicht nochmals runterladen.

Jeder dieser Schritte kann bei der Entwicklung unvorhergesehene Probleme bereiten. Zum Beispiel merkt der Entwickler kurz (z.B. 5 Minuten) nach dem Verteilen der cache manifest Datei, dass er eine Ressource vergessen hat. Deshalb verändert er bzw. fügt was der cache manifest Datei eine Zeile hinzu. Dann verteilt er die Anwendung erneut. Nach dem anschließenden Aktualisieren des Browsers, wird aber bei bestimmten Server Konfigurationen keine Aktualisierung vorfinden. Die Standardeinstellung der meisten Web Server besagt dem Browser (über http Header) mitzuteilen statische Files mehrere Stunden zu cachen ohne Nachzufragen. Der Server weiß natürlich hierbei, dass es eine Aktualisierung gibt, wird jedoch durch den Browser nicht gefragt.

Dies ist, wie bereits erwähnt, kein Bug sondern ein Feature. Alles hat so funktioniert, wie es sollte, denn gäbe es diese Anweisung des Servers, dem Browser oder dem Proxy mitzuteilen, dass er cachen muss, nicht, dann würde das Internet die Last niemals bewältigen können.

Diese Funktion kann man beim Web – Browser für die Entwicklungszeit natürlich ausschalten, anderenfalls müsste man zwischen Updates mehrere Stunden warten, um diese Testen zu können.

Das Problem mit der cache manifest Datei ist nicht das einzige Problem, welches bei der Entwicklung oder Verteilung besteht. Möchte der Entwickler nur eine Datei aktualisieren, die im cache manifest bereits hinterlegt ist, wird er auch auf ein Problem stoßen, denn nach der Aktualisierung des Browser wird er keine Änderung erkennen. Dies liegt daran, dass die cache manifest Datei sich nicht geändert hat, dies wird auch zurückgemeldet.

Um dieses Problem zu lösen, wird empfohlen, eine Revisionsnummer in der cache manifest Datei zu führen und diese bei jeder Änderung der Dateien zu aktualisieren.

7 Schlussbetrachtung

Zusammenfassend kann man sagen, dass HTML 5 mit der Offline Web Applikation schlussendlich, nach jahrelanger Entwicklung dieser Funktionalität, eine echte Alternative zu den herkömmlichen Client Anwendungen bietet. Durch die Offline Funktionalität fällt der wichtigste Nachteil einer Web Anwendung weg und behält jedoch sämtliche Vorteile dieser. Jedoch ist durch HTML5 nur der erste Schritt der Standardisierung der Offline Fähigkeit von Anwendungen gemacht worden, jetzt müssen sämtliche Webbrowser, diese Funktionalität voll implementieren und nativ unterstützen.

Auch wird HTML5 mit den Offline Web Anwendungen nicht gleich alle Client Anwendungen ablösen können, es bleiben noch viele Bereiche, wie Grafik Design, Spiele und besonders unternehmenskritische Anwendungen, die noch einige Zeit reine Client Anwendungen bleiben werden. Langfristig ist aber davon auszugehen, dass das herkömmliche Betriebssystem ausgedient hat und man nur einen Browser benötigt, um alle Aufgaben erledigen zu können. Experten, wie der CEO der Firma Opera Lars Boilesen geht sogar davon aus, dass dies bereits 2020 der Fall sein wird. Dies manifestiert er an einer firmeneigenen Untersuchung, die besagt, dass bereits heutzutage 95% der Benutzer nur noch 5 native Client Applikationen auf dem Rechner haben. ^[14]

8 Fußnoten

↑ Laut W3C Working Group Note 30 May 2008
↑ vgl. http://www.heise.de, Webanwendungen auch Offline nutzen
↑ vgl. http://www.innovations-report.de, Webperformance wird immer mehr zum Wettbewerbsvorteil im E-Commercee
↑ vgl. http://www.tecchannel.de, Die zehn größten Schwachstellen in Webanwendungen
↑ vgl. http://www.elektronik-kompendium.de, MIME-Types - Multipurpose Internet Mail Extensions
↑ vgl. http://www.whatwg.org, The cache manifest syntax
↑ vgl. http://dev.w3.org/html5/spec Hypertext Transfer Protocol -- HTTP/1.1 Method Defenitions
↑ http://www.whatwg.org, Application cache API
↑ vgl. http://dev.w3.org/html5/spec Kapitel 5.6.1.1 Event Summary
↑ vgl. HTML5 Up and Running S23f.
↑ vgl. HTML5 Up and Running S130
↑ vgl. HTML5 Up and Running S131f.
↑ vgl. http://dev.w3.org/html5/spec Kapitel 5.6.10 Browser State
↑ UpNorthWeb, Konferenz vom 14.10.2010

9 Literatur- und Quellverzeichnis

Mark Pilgrim (2010)| Pilgrim, Mark: HTML5: Up and Running, Published by O'Reilly Media, Inc., S. 137 bis 146

David Mathew (2010)| Mathew, David: HTML 5 Designing Rich Internet Applications| Published by Focal Press,S. 4 bis 12 ; S.33 bis 35

Peter Kröner (2010)| Kröner, Peter: HTML5 – Webseiten innovativ und zukunftssicher | Published by Open Source Press,S. 151 bis 179

UpNorthWeb, Konferenz vom 14.10.2010 | Webcast unter http://www.opera.com/portal/unw/ | Datum 28.12.2010 Uhrzeit: 15:00

HTML 5 Working draft | http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline | Datum 07.01.2011 | Uhrzeit: 18:00 Uhr

HTML 5 Edtor's draft | http://dev.w3.org/html5/spec | Datum 07.01.2011 | Uhrzeit: 18:00 Uhr

Heise | http://www.heise.de/ix/meldung/Webanwendungen-auch-offline-nutzen-132426.html | Datum 08.01.2011 | Uhrzeit: 19:00 Uhr

Innovations-Report | http://www.innovations-report.de/suche/suche_s.php?suchbegriff=E-Commerce | Datum 07.01.2011 | Uhrzeit: 18:00 Uhr

Tecchannel | http://www.tecchannel.de/webtechnik/webserver/2019842/schwachstellen_fehler_und_bugs_in_web_anwendungen/ | Datum 07.01.2011 | Uhrzeit: 18:00 Uhr

Elektronik-Kompendium | http://www.elektronik-kompendium.de/sites/net/0906211.htm | Datum 07.01.2011 | Uhrzeit: 18:00 Uhr

[0] Laut W3C Working Group Note 30 May 2008

[1] vgl. http://www.heise.de, Webanwendungen auch Offline nutzen

[2] vgl. http://www.innovations-report.de, Webperformance wird immer mehr zum Wettbewerbsvorteil im E-Commercee

[3] vgl. http://www.tecchannel.de, Die zehn größten Schwachstellen in Webanwendungen

[4] vgl. http://www.elektronik-kompendium.de, MIME-Types - Multipurpose Internet Mail Extensions

[5] vgl. http://www.whatwg.org, The cache manifest syntax

[6] vgl. http://dev.w3.org/html5/spec Hypertext Transfer Protocol -- HTTP/1.1 Method Defenitions

[7] ttp://www.whatwg.org, Application cache API

[8] vgl. http://dev.w3.org/html5/spec Kapitel 5.6.1.1 Event Summary

[9] vgl. HTML5 Up and Running S23f.

[10] vgl. HTML5 Up and Running S130

[11] vgl. HTML5 Up and Running S131f.

[12] vgl. http://dev.w3.org/html5/spec Kapitel 5.6.10 Browser State

[13] UpNorthWeb, Konferenz vom 14.10.2010

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]