HTML5 Unterstü tzüng fü r teilweise offline-nützüng

Transkript

1 HTML5 Unterstü tzüng fü r teilweise offline-nützüng Mike Schwitalla 21. März 2013 Zusammenfassung: Diese Arbeit behandelt die Offline-Funktionalitäten der in der Entwicklung befindliche HTML5 Spezifikation. Es werden die entsprechenden Teilspezifikationen Web Storage, Offline Web Application, IndexedDB und File API vorgestellt und mögliche Alternativen aufgezeigt. Abstract: This work discusses the offline capabilities of the HTML5 specification, which is under development. It will be presented the corresponding specifications of web storage, offline web application, IndexedDB and File API, and also possible alternatives.

2 Inhaltsverzeichnis Abbildungsverzeichnis...3 Tabellenverzeichnis Einleitung Theoretische Grundlagen Das Internet Verständnis von Online und Offline Die Hypertext Markup Language Unterschied HTML5 und HTML Living Standard Formen der Offline-Nutzung Bisherige Möglichkeiten Neue Möglichkeiten Web Storage [14] [15] sessionstorage localstorage Offline Web Applications [16] [17] Application caches Web SQL Database [19] Indexed Database API [20] File API [21] Offline & Storage vs. native Anwendung Voraussetzungen Einschränkungen Warum noch native Anwendungen? Grenzen Anwendungsgebiete Entwicklungsarbeit Alternativen Schlussbetrachtung A Ausblick B Abkürzungsverzeichnis C Anhang Literaturverzeichnis Weiterführende Literatur Stand: Seite 2 / 24

3 Abbildungsverzeichnis Abbildung 1: Die gängigsten Desktop Browser Deutschlands...5 Abbildung 2: Die gängigsten Mobile Browser Deutschlands...5 Abbildung 3: Screenshot der Einstiegsseite der Entwicklungsarbeit...17 Tabellenverzeichnis Tabelle 1: Offline-Speicherung durch Drittanbieterfunktionalität...7 Tabelle 2: Kompatibilitätsliste sessionstorage...9 Tabelle 3: Kompatibilitätsliste localstorage...9 Tabelle 4: Kompatibilitätsliste Application Cache...11 Tabelle 5: Kompatibilitätsliste Web SQL Database...11 Tabelle 6: Kompatibilitätsliste IndexedDB...12 Tabelle 7: Kompatibilitätsliste File API...13 Stand: Seite 3 / 24

4 1 Einleitung Das World Wide Web ist im stätigen Wandel. Durch die aktuelle Entwicklung des HTML5- Standards stehen zahlreiche multimediale Neuerungen an, die das Web, auch ohne Browser- Plugin s, Interaktiver werden lassen. Es stehen Möglichkeiten offen die vormals nur mit Adobe Flash, Microsoft Silverlight oder ähnlichem zur Verfügung stand. Umfangreiche Anwendungen bringen auch umfangreiche Daten mit. Um unter anderem den Datenverkehr möglichst gering zu halten, bietet der HTML5-Standard die offline Speicherung von Daten zur Verfügung. Offline Datenspeicherung ist im Prinzip nichts neues. Daten werden lokal erstellt oder für die spätere Nutzung lokal abgespeichert. Diese allgegenwärtige Möglichkeit bleibt meist dem Nutzer oder dem Nutzer-Client vorbehalten. Dies gilt für alle Art von Daten im Internet. Darunter fallen die Seiten des World Wide Webs, s, Musikdateien, Programmdaten und vieles mehr. Durch die immer schnelleren und mobilen Internetanbindungen verlagern sich die Nutzer- Clients immer öfter als Dienstleistung (Software-as-a-Service) ins World Wide Web. Das wohl bekannteste Beispiel ist der -Client. Fast jeder Anbieter von -Postfächern bietet heutzutage einen Web-Client zum Verwalten der s an. Ein Problem beim Zugriff auf den -Web-Client ist die ständig nötige Internetanbindung. Ist diese nicht vorhanden kann schon das Lesen einer unmöglich werden. Es hapert an der Möglichkeit, ohne externe Software, die Daten lokal abzuspeichern. Der HTML5 Standard befindet sich zurzeit noch in der Entwicklung, viel der hier vorgestellten Funktionen sind nur als Entwurf veröffentlicht. Um diese Arbeit nicht mit Kompatibilitätsangaben zu überfüllen, welche sich in kürzester Zeit ändern können, sind die gemachten Angaben bezogen auf die gängigsten Browser (Marktanteil >5%) in Deutschland der vergangenen sechs Monate im Desktop [1] und Mobile-Bereich [2]. Stand: Seite 4 / 24

5 Abbildung 1: Die gängigsten Desktop Browser Deutschlands Quelle Abbildung 2: Die gängigsten Mobile Browser Deutschlands Quelle Für weitere und aktuelle Informationen führt die Internetseite The HTML5 test [3] eine sehr detaillierte und Umfangreiche Statistik, aus der mit Stand vom die gemachten Kompatibilitätsangaben stammen. Stand: Seite 5 / 24

6 2 Theoretische Grundlagen 2.1 Das Internet Das Interconnected Network (Internet) ist ein weltumfassendes Netzwerk von Rechnern, dessen Vorgänger das Advanced Research Projects Agency Network (ARPANET) ist, welches im Auftrag der US Air Force entwickelt wurde. [4] Im Internet können verschiedene Dienste genutzt werden. Zu den Diensten gehören unter anderem das World Wide Web (WWW), , Telnet und das Usenet. Durch die immer schnelleren Datenverbindungen werden neue Dienste entwickelt und genutzt, wie z.b. für die Telefonie oder das Fernsehen. In dieser Ausarbeitung liegt das Augenmerk auf dem World Wide Web. Die Techniken von HTML5 können aber auch von anderen Internetdiensten genutzt werden. 2.2 Verständnis von Online und Offline Der Begriff Offline, in Verbindung mit dem Internet, assoziiert das weder eine passive noch eine aktive Verbindung mit dem Netzwerk besteht. Online bedeutet dementsprechend, dass eine Verbindung zum Internet hergestellt ist. Daher ist der Titel dieser Arbeit nicht ganz zutreffend. Die behandelten Techniken beruhen auf einer Verschränkung der beiden Zustände, weswegen der Begriff Online-Offline besser gewählt wäre. Der Einfachheit halber und der gängigen Literatur angepasst wird zur Beschreibung der Funktionalitäten auf den Begriff Offline zurückgegriffen. Eine ausführliche Diskussion zu diesem Thema ist auf [5] zu finden. 2.3 Die Hypertext Markup Language Die Auszeichnungssprache Hypertext Markup Language (HTML) basiert auf der Standard Generalized Markup Language (SGML), welche nach ISO 8879 [6] genormt ist. HTML ist die Lingua franca 1 des Web, mittels derer die Inhalte der Seiten des World Wide Web beschrieben und von einem Webbrowser dargestellt werden können. Das World Wide Web Consortium (W3C) und die Web Hypertext Application Technology Working Group (WHATWG) haben es sich zur Aufgabe gemacht, den HTML Standard weiter zu Entwickeln. Weiterführende Informationen sind auf [7] zu finden. 1 Italienisch für fränkische Sprache; Bedeutung: Verkehrssprache eines größeren mehrsprachigen Raums [29] Stand: Seite 6 / 24

7 2.4 Unterschied HTML5 und HTML Living Standard HTML in der Version 5 [8] und als Living Standard [9] werden in Kooperation der beiden Organisationen W3C und WHATWG entwickelt. Der Unterschied liegt in der Philosophie der Entwicklung bzw. auch der Veröffentlichung des Standards. Im Wesentlichen bevorzugt das W3C die Veröffentlichung der Spezifikation als Empfehlung 2 nach Abschluss der Entwicklungsarbeiten, während die WHATWG von einer lebenden, sich ständig im Wandel befindlichen Spezifikation ausgeht. Weiter Unterschiede sind unter [10] detailliert aufgelistet. 3 Formen der Offline-Nutzung 3.1 Bisherige Möglichkeiten Die lokale Datenspeicherung von Internetinhalten ist nicht neu. HTML-Seiten können lokal gespeichert oder auch ausgedruckt werden. Daten wie zum Beispiel aktive Logins können in Cookies [11] genauso gespeichert werden wie Formulardaten oder virtuelle Einkaufskörbe im Online-Shop. Neben den standardisierten Möglichkeiten gibt es im Internet auch über Software von Drittanbietern die Möglichkeit Daten lokal zu speichern. In Tabelle 1 wird ein Teil dieser Fähigkeiten aufgezeigt, welche meist zugunsten von HTML5 eingestellt wurden. Tabelle 1: Offline-Speicherung durch Drittanbieterfunktionalität Software Verfahren der lokalen Speicherung Verweis Microsoft Internet Explorer mittels DHTML Speicherung von [12] eingestellt userdata Adobe Flash Local Shared Object (LSO) / Flash Cookies [13] Ajax Massive Storage System Flash-to-JavaScript Bridge [14] (AMASS) in Dojo Toolkit integriert Google Gears eingestellt zu Gunsten HTML5 lokaler Webserver mit Datenbank [15] Trotz der oben aufgeführten Funktionalitäten lässt sich sagen, dass ohne direkten Zugriff auf das Dateisystem, die effektive lokale Datenspeicherung den nativen Programmen vorbehalten ist. Neben den in Tabelle 1 aufgeführten Software gibt es aktuell neben HTML5 noch weiter Möglichkeiten der Offline-Nutzung, welche im Abschnitt 8 Alternativen behandelt werden. 2 Das W3C ist keine zwischenstaatlich anerkannte Organisation und gibt daher nur Empfehlung (W3C Recommendation) aus, welche meistens als quasi Standard anerkannt werden. Stand: Seite 7 / 24

8 3.2 Neue Möglichkeiten Mit den neuen Funktionalitäten der Offline-Datenspeicherung von HTML5 soll eine effektive Datenspeicherung auch für Web-Applikationen möglich sein. In HTML5 sind die unterschiedlichen Funktionalitäten der offline-nutzung in verschiedene Spezifikationen, gemäß der folgenden Auflistung, aufgeteilt. Web Storage o sessionstorage o localstorage Offline Web Applications o Application caches o Web SQL Database Indexed Database File API Auf die Eigenschaften der unterschiedlichen Speichervarianten wird in den folgenden Abschnitten näher eingegangen. 3.3 Web Storage [16] [17] Web Storage ist ein lokaler Datenspeicher, welcher den Cookies sehr ähnlich ist. Es ist die persistente als auch eine Session basierende Datenspeicherung möglich. Vom Entwicklungsstatus her ist der Web Storage zurzeit bei W3C als Candiate Recommendation 3 veröffentlicht und im Living Standard der WHATWG als Ready for first implementations 4 markiert. Beide Storage Typen speichern Zeichenketten in Verbindung mit einem Schlüssel in einem Storage Objekt. Der Schlüssel ist ebenfalls als Zeichenkette realisiert. In der Spezifikation wird empfohlen, dass die Client-Software die zu speichernde Datenmenge begrenzt und wiedergeben kann welche Datenmenge bereits abgespeichert ist. In welcher Form oder Höhe das geschieht wird den Herstellern der Software überlassen. 3.4 sessionstorage In diesem Speicher werden Zeichenketten für den Zeitraum einer Session (der Lebenszeit eines Browser-Tabs) gespeichert. Die Daten werden nach dem beenden der Session vom Browser automatisch gelöscht. 3 Die W3C Arbeitsgruppe hat die Arbeit an der Spezifikation so gut wie beendet und wartet auf Rückmeldungen aus der Entwicklergemeinschaft. 4 Arbeiten an der Spezifikation sind abgeschlossen und können implementiert werden. Stand: Seite 8 / 24

9 Tabelle 2: Kompatibilitätsliste sessionstorage Desktop Browser Implementie rt Mobile Browser Implementie rt Firefox 13 Ja Android 4.0 Ja Internet Explorer Ja ios 5.1 Ja 9 Chrome 20 Ja Opera Mobil Ja 12.0 Safari 5.2 Ja Quelle localstorage Im Gegensatz zum sessionstorage bleiben die Daten auch nach Beendigung der Session und somit auch nach einem Neustart der Client-Software erhalten. Um Manipulationen zu erkennen, muss gemäß der Spezifikation die Client-Software eine Exception geworfen werden, wenn von Scripts anderer Herkunft auf die gespeicherten Daten zugegriffen wurde. Um dies zu erkennen wird das document.domain Attribut überprüft. Tabelle 3: Kompatibilitätsliste localstorage Desktop Browser Implementiert Mobile Browser Implementiert Firefox 13 Ja Android 4.0 Ja Internet Explorer Ja ios 5.1 Ja 9 Chrome 20 Ja Opera Mobil Ja 12.0 Safari 5.2 Ja Quelle Offline Web Applications [18] [19] Dieses Thema umfasst zwei Unterthemen, die Funktionalitäten von Web SQL und die des offline Anwendungscache. Die Online-/Offline-Statuserkennung sowie der in Abschnitt 3.5 behandelte localstorage stehen in Beziehung zu dieser Spezifikation. Zu der Online-/Offline-Statuserkennung ist lediglich zu erwähnen, dass ein im Browser manuell zu setzendes Flag abgefragt wird. Gesetzt wird dieses Flag über die Option Offline arbeiten o.ä. der Client-Software. Es wird nicht der reale Zustand der Internetverbindung abgefragt. Die Arbeiten an dieser Teilspezifikation von HTML5 sind beim W3C und der WHATWG bereits abgeschlossen und kann Implementiert werden. Stand: Seite 9 / 24

10 3.6.1 Application caches Der Application cache wird über eine Manifest-Datei, welche im Header der HTML-Datei angegeben werden muss, angesprochen. Über die Manifest-Datei ist es möglich festzulegen, welche Dateien auf der lokalen Festplatte gespeichert werden sollen und welche auf jeden Fall aus dem Netzwerk zu laden sind. Weiterhin besteht die Möglichkeit zur Angabe einer Fallback-Seite, welche im Offline- Zustand geladen wird, falls eine nicht lokal gespeichert Seite aufgerufen wird. Sollte eine der aufgeführten Dateien für den Speichervorgang nicht vorhanden sein, wird die gesamte Manifest-Datei ignoriert und der Application Cache nicht genutzt. Die lokal gespeicherten Dateien werden, auch bei aktiver Internetverbindung, geladen. Es muss dazu lediglich die URL der eigentlichen Seite aufgerufen werden. Eine Aktualisierung der Dateien findet nur nach einer Veränderung der Manifest-Datei statt, aber auch dann nur, wenn die gespeicherten Dateien sich geändert haben. Es empfiehlt sich daher eine Kommentarzeile mit Datum, Uhrzeit oder Versionsnummer in die Manifest-Datei einzufügen, welche bei allen Änderungen an den verweisenden Dateien angepasst wird. Durch diese Umsetzung des beschriebenen Updateverfahrens ist es möglich Bandbreite und Zeit zu sparen, da zuerst nur die Manifest-Datei auf Aktualität überprüft wird und anschließend erst bei Bedarf die anderen Dateien einer Prüfung unterzogen werden. Durch den Application Cache können somit auch größere Programme realisiert werden, welche nicht nur Offline verwendet werden können, sondern auch nur einmal komplett aus dem Internet heruntergeladen werden müssen. Von besonderem Interesse ist dies bei mobilen Anwendungen, die nicht ständig eine Internetverbindung mit genügend Bandbreite zur Verfügung haben. Wie der Tabelle 4 zu entnehmen, werden die gängigsten mobilen Browser unterstützt. Während der Erstellung der Entwicklungsarbeit (siehe Abschnitt 7) wurde festgestellt, dass der Browser Mozilla Firefox in der Version 13 den Application Cache nicht unterstütz, obwohl die Funktion seit Version 3 [20] des Browsers vorhanden sein soll. Der Status bleibt konstant auf UNCACHED stehen. Auch die im Browser einzusehende Datenmenge bleibt bei 0 Byte. Letzteres kann auch bei anderen Internetseiten festgestellt werden, welche den Application Cache nutzen. Stand: Seite 10 / 24

11 Tabelle 4: Kompatibilitätsliste Application Cache Desktop Browser Implementiert Mobile Browser Implementiert Firefox 13 Ja Android 4.0 Ja Internet Explorer Nein ios 5.1 Ja 9 Chrome 20 Ja Opera Mobil Ja 12.0 Safari 5.2 Ja Quelle Web SQL Database [21] Web SQL sollte eine auf dem Befehlssatz von SQLite aufbauende, genormte SQL Datenbank auf Client-Seite werden. Da sich bei der Entwicklung nur Entwickler beteiligt haben, die ausschließlich SQLite verwenden, fehlte die nötige Breite für einen eigenen Standard. Da der Befehlssatz von SQLite zwar als Grundlage dienen sollte, wollte man vermeiden einen SQLite Clone zu entwickeln. Aus diesem Grund wurde die Entwicklung eingestellt, auch wenn schon viele Plattformen die Spezifikation implementiert hatten und auch noch haben. Eine alternative Datenbank wird unter dem Namen Indexed Database für HTML5 entwickelt. Diese wird im Abschnitt 3.7 vorgestellt. Tabelle 5: Kompatibilitätsliste Web SQL Database Desktop Browser Implementiert Mobile Browser Implementiert Firefox 13 Nein Android 4.0 Ja Internet Explorer Nein ios 5.1 Ja 9 Chrome 20 Ja Opera Mobil Ja 12.0 Safari 5.2 Ja Quelle Indexed Database API [22] Die Datenbank dient der Speicherung von JavaScript Objekten. Wie der Name schon andeutet handelt es sich nicht um eine relationale sondern um eine indizierte Datenbank. Jedes abgespeicherte Objekt wird über einen Schlüssel indiziert. Dieser kann automatisch generiert oder individuell erstellt werden. Schlüssel und Objekte werde in einem sogenannten Object Store abgespeichert. Eine Datenbank kann eine oder mehrere Objekt Stores beinhalten. Die Spezifikation sieht einen asynchronen und eine synchronen Zugriff vor. Die asynchrone Teilspezifikation ist schon in einigen Browsern implementiert, während noch keiner eine Umsetzung des synchronen Zugriffs realisiert hat. Die IndexedDB hat bei der W3C noch den Status eines Arbeitsentwurfs. In den letzten Versionen hat sich einiges am Syntax geändert, sodass es schwierig ist ein funktionierendes Stand: Seite 11 / 24

12 Beispiel oder ein korrektes Tutoriell zu finden. Die WHATWG führt die Datenbank nicht in ihrem Living Standard auf. Die Spezifikation sieht es nicht vor, dass der Anwender über die Client-Anwendung eine Übersicht oder gar den Zugriff auf die Datenbanken erhält. Sollten die Softwarehersteller nicht aus eigenem Antrieb eine entsprechende Schnittstelle anbieten, erhält der Nutzer keine Übersicht darüber, welche Datenbanken auf dem Rechner existieren und welchen Datenumfang diese haben. Ein vorbildliches Beispiel geht Google mit seinem Browser Chrome, welcher Einblicke über alle gespeicherten Daten über einen Ressourcen-Monitor bietet. Dies allerdings nur für die aktuell aufgerufene Seite. Die indizierte Datenbank gehört zu den Funktionalitäten die noch nicht im mobilen Bereich umgesetzt wurden, wodurch Webanwendungen mit Offline-Datenbanken auf den Desktop- Bereich beschränkt sind. Tabelle 6: Kompatibilitätsliste IndexedDB Desktop Browser Implementiert Mobile Browser Implementiert Firefox 13 Ja Android 4.0 Nein Internet Explorer Nein ios 5.1 Nein 9 Chrome 20 Ja Opera Mobil Nein 12.0 Safari 5.2 Ja Quelle File API [23] Die Datei Schnittstelle lässt sich nur teilweise zu den Offline-Funktionalitäten von HTML5 zuordnen. Mit Hilfe der API gelingt der Zugriff auf das lokale Dateisystem. So können Dateien im Webbrowser verarbeitet werden, ohne dass diese an einen Server übertragen werden müssen. In der Regel wird über eine FileList ein Inhaltsverzeichnis ausgelesen um danach einzelnen Dateien daraus zur Bearbeitung auszuwählen. Über den Dateizugriff besteht die Möglichkeit die Daten bei Bedarf an den Server zu übertragen. Dafür stehen zwei Verfahren zu Verfügung. Die Übertragung als Datei und die Übertragung der Dateien in mehreren Paketen, welche auf dem Server wieder zusammengesetzt werden. Dies ist vor allem bei Breitbandübertragungen zum parallelen Upload interessant, um möglichst die gesamte Bandbreite auszunutzen. In der Tabelle 7 ist lediglich der Browser Chrome von Google in der aktuellen Version aufgeführt, der die Spezifikation implementiert hat. Chrome ist dabei der einzige Browser, der die Spezifikation im Ganzen umgesetzt hat. In Teilen sind die Funktionalitäten auch in den anderen Browsern vorhanden. Firefox 13 hat z.b. die Möglichkeit Verzeichnisse auszulesen und auf lokale Dateien zuzugreifen. Dies kann über die beigefügte Entwicklungsarbeit (Abschnitt 7) nachvollzogen werden. Stand: Seite 12 / 24

13 Tabelle 7: Kompatibilitätsliste File API Desktop Browser Implementiert Mobile Browser Implementiert Firefox 13 Nein Android 4.0 Nein Internet Explorer Nein ios 5.1 Nein 9 Chrome 20 Ja Opera Mobil Nein 12.0 Safari 5.2 Nein Quelle 4 Offline & Storage vs. native Anwendung 4.1 Voraussetzungen Um die Möglichkeiten von HTML5 nutzen zu können ist eine unterstützende Client-Software notwendig. Dies muss nicht zwangsläufig ein Webbrowser sein, wird aber in den meisten Anwendungsfällen darauf hinaus laufen. Da entsprechende Client-Software für jedes System entwickelt werden kann ist die Auszeichnungssprache HTML5 plattformunabhängig. Die Unterstützung der Webbrowser bezüglich der einzelnen Funktionen von HTML5 ist sehr unterschiedlich, was durch die noch in der Entwicklung befindliche Spezifikation zu begründen ist. Das entsprechende Implementationen bereits vorhanden sind kann der Entwicklergemeinde der Spezifikation zugeschrieben werden. Diese besteht weitestgehend aus Entwicklern der großen Browser Hersteller (u.a. Microsoft, Google, Mozilla, Opera). Dieser Umstand lässt auch hoffen, dass alle Spezifikationen gleichermaßen in den Browser umgesetzt werden und Hacks 5 wie sie in der Vergangenheit nötig waren hinfällig werden. Native Anwendungen sind nicht plattformunabhängig, sie sind für ein spezielles Betriebssystem Programmiert und lassen sich dementsprechend nur auf diesem System ausführen. Über Virtualisierung lassen sich viele native Programme auf anderen als den vorgesehenen Systemen betreiben, was jedoch meist mit Performanceeinbußen einhergeht und je nach Virtualisierungssoftware mit Problemen behaftet sein kann. Auch Laufzeitumgebungen wie Java von Oracle oder Adobe Flash sind nicht plattformunabhängig. Java bietet zwar Laufzeitumgebungen für viele unterschiedliche Systeme an, sodass ein quasi plattformunabhängiger Status erreicht ist, dennoch laufen Java Anwendungen nur auf den von Oracle unterstützten Plattformen und nicht auf allen. Besonders bei Flash kann nicht mehr von einem plattformunabhängigen Format gesprochen werden. Im Desktop-Bereich noch weit verbreitet, wird es durch kein mobiles Smartphone- 5 Browserweichen auch Hacks genannt, dienen zur Browser abhängigen Darstellung von Inhalten, um ein möglichst einheitliches Layout zu präsentieren. [30] Stand: Seite 13 / 24

14 oder Tablet-System unterstützt. Unter ios wurde Flash noch nie offiziell unterstütz und die Portierung auf Android wurde jüngst zurückgenommen. 4.2 Einschränkungen Einschränkungen der nativen Software bestehen im Wesentlichen nur aus der soeben, im vorherigen Abschnitt, erläuterte Plattformabhängigkeit. Dennoch, eine weitere Einschränkung die nicht unerwähnt bleiben sollte ist der unter Umständen benötigte Internetzugriff. Je nachdem wie eine eventuell installierter Firewall oder andere Schutzmechanismen konfiguriert sind kann eine Internetverbindung mehr oder weniger Schwierig aufgebaut werden. Bei der Entwicklung von HTML5-Anwendung hingegen muss sich darüber keine Gedanken gemacht werden. Die Anwendung hat die gleichen Rechte wie die Client-Software, welche in der Regel für den Internetzugriff konfiguriert ist. Somit müssen keine Rechte durch einen Administrator eingeräumt werden, wie es unter Umständen bei nativen Anwendungen der Fall ist. Jedoch haben es HTML5-Anwendungen mit anderen, vielfältigen Beschränkungen zu tun die je nach Client-Software unterschiedlich ausfallen können. Allgemein sind HTML5-Anwendungen langsamer als native Anwendungen. Dies beginnt bei der Installation der Anwendung. Eventuell müssen große Datenmengen aus dem Internet beim ersten Aufruf geladen werden. Die Umgehung dieser Prozedur durch eine Offline- Installation sollte aufgrund der in den Spezifikationen aufgeführten Sicherheitsregeln, welche nur Daten gleicher Herkunft in einer Webanwendung zulässt, nicht möglich sein. Beim Betrieb der Anwendung, auch im Offline-Bereich, kommen diese nicht an die Performance von nativen Programmen ran. Alleine bedingt dadurch, dass native Programme sehr Hardwarenah programmiert werden können und so einen direkteren Zugriff auf vorhandenen Ressourcen erhalten können. Dadurch, dass in HTML5 keine Hardwareschnittstellen beschrieben sind, bleibt der Zugriff auf Hardwarekomponenten wie Bluetooth, GPS-Sensor oder auch einer Kamera verwehrt. Gerade diese Möglichkeiten sind vor allem im mobilen Einsatzbereich wünschenswert, wodurch HTML5 seine größte Einschränkung erfährt. Diese Insuffizienz lässt sich durch entsprechende Erweiterungen überbrücken, führt aber immer über den Umweg einer nativen Anwendung, wodurch der größte Vorteil von HTML5, die Plattformunabhängigkeit, eingebüßt wird. Weiter Einschränkungen erfährt HTML5 im Umgang mit der Datenhaltung, welche im Abschnitt 5 Grenzen detailliert behandelt wird. 4.3 Warum noch native Anwendungen? Gerade durch die noch fehlenden Hardwareschnittstellen von HTML5 haben native Anwendungen einen großen Vorteil. Da native Anwendungen vor allem auf die Zusammenarbeit mit einzelnen CPU-Typen ausgelegt sind, werden diese in der Regel über Stand: Seite 14 / 24

15 schnelle Ausführungszeiten verfügen. Dies ist vor allem bei komplexen Berechnungen wie sie z.b. in der Videobearbeitung, der Kryptographie und vielen anderen Bereichen von Vorteil. Native Anwendungen können in der Regel von verschiedenen Datenträgern installiert oder direkt ausgeführt werden, während Webanwendungen, auch wenn sie offline verwendet werden können, im Normalfall aus dem Internet mindestens einmal geladen werden. Je nach Internetverbindung kann dies selbst bei wenigen Megabytes relativ lange dauern. Besonders betroffen davon sind Verbindungen über das Mobilfunknetz, welches je nach Standort und Netzqualität mit sehr geringen Transferraten ausfallen können. Je nach Tarif des Mobilfunkvertrages können bei nicht bekannter Größe der Webanwendung überraschend hohe Kosten auf den Nutzer zukommen. Webanwendungen mittels HTML5 haben die Eigenheit das die Quellcodes offengelegt werden. Ist dieses nicht erwünscht, muss eine native Anwendungen oder eine der nachfolgend beschrieben Hybridanwendungen entwickelt werden. Um das bestmögliche von beiden Welten zu vereinen bieten sich Hybridanwendungen an, wie sie zahlreich im Smartphone und Tablet Bereich bereits vorkommen. Über die native Komponente kann die Hardwaresteuerung erfolgen, während die Anzeige und Datenhaltung über die HTML Komponente realisiert wird. Wodurch die Hybridanwendungen die Vorteile zusammenfügen werden auch die Nachteile zusammengeführt, sofern diese sich nicht durch die Verschmelzung der beiden Technologien aufheben. 5 Grenzen Wie bei viele Softwareansätze haben auch die Offline-Fähigkeiten von HTML5 ihre Grenzen. Eine große Grenze ist der verwendete Browsers. Wurden Daten erst einmal lokal gespeichert, können die Daten nicht ohne Umwege über einen anderen Browser abgerufen werden. In der Regel bedeutet dies eine Festlegung auf einen Browser. Problematisch werden in diesem Zusammenhang auch Datensicherungen. Bisher unterstützt kein Browser ein Datenbackup der Offline Daten. Auch ist im HTML5 Standard keine derartige Funktionalität geben. Ein weiterer Punkt ist der Datenzugriff. Die gespeicherten Daten sind für den Nutzer im Backend des Browsers nicht einsehbar. Somit entfällt eine händische Überprüfung der gespeicherten Daten durch den Otto Normalnutzer. Er muss darauf vertrauen, dass die genutzte Software alle Daten korrekt ablegt und auch wieder löscht. Sollte das vom Entwickler umgesetzte Speichermanagement unzureichend programmiert sein, können sich vermehrt verwaiste Datensätze ansammeln. Lediglich das Löschen des gesamten Offlinespeichers, teilweise auch auf eine Domain begrenzt, unterstützen die meisten Browser zum jetzigen Zeitpunkt. Im Browser Chrome kann zumindest von der aktuellen Seite die Daten geändert werden. Stand: Seite 15 / 24

16 Den Datenzugriff betreffend, ist der Sicherheit der gespeicherten Daten ebenso Grenzen gesetzt. Auch wenn wie gerade erläutert der Zugriff auf die gespeicherten Daten mit Bordmitteln kaum unterstützt wird, bedeutet dies nicht, dass keiner Zugriff auf die Daten möglich ist. Da die Daten lokal abgespeichert werden, können diese von kompetenten Personen ausfindig gemacht und gegebenenfalls manipuliert werden. Durch die Manipulation der Daten kann z.b. schädlicher Code aus dem Internet heraus in die offline Datenbestände eingeschleust werden. Ein ebenfalls wahrscheinliches Szenario ist, die Daten lokal zu verändern um die geänderten Daten auf den Server zu übertragen. Diese Daten müssen nicht zwangsläufig aus schädlichem Code bestehen, sie können auch veränderte Kundendaten darstellen, um in Namen von anderen Personen Geschäfte abzuwickeln, Rechnungen und Artikelpreise zu manipulieren oder einfach die Schulnote zu verbessern. Es ist vom Entwickler und dessen Auftraggeber entsprechend abzuwägen, welche Daten Offline Verfügbar gemacht werden und bestenfalls noch Sicherheitsvorkehrungen zur Verhinderung von Manipulationen berücksichtigen. Kurz erwähnt sei auch die Problematik der Datensynchronisation, die bei allen Server-Client- Anwendungen, auftreten. Teils sind asynchrone Verfahren in der Spezifikation von HTML5 definiert und auch in den aktuellen Browsern weitestgehend umgesetzt. Synchrone Verfahren sind teilweise vorgesehen, aber noch in keinem Browser umgesetzt. Daher kann momentan nicht abgesehen werden, ob der synchrone Datenabgleich weiter verfolgt oder fallengelassen wird. Allgemein ist Vorsicht bei der Implementierung von HTML5 Funktionen walten zu lassen. Die Spezifikationen befinden sich größtenteils noch in der Entwurfsphase, sodass gravierende Änderungen in kurzen Zeitabständen möglich sind und auch Teilspezifikationen, wie bei Web SQL geschehen, in der Bearbeitung eingestellt werden können. 6 Anwendungsgebiete Durch die Offline Spezifikationen von HTML5 können viele bereits vorhandenen Web Applikationen mit neuen Funktionalitäten ausgestattet werden, welche die Programme zu echten Alternativen von nativen Anwendungen werden lassen. Vor allem im mobilen Bereich mit Notebook und Smartphone, wo nicht immer eine Internetverbindung möglich ist, haben diese Anwendungen großes Potenzial. Neben -Anwendungen, Textverarbeitung und Tabellenkalkulationen könne aber auch Umfangreiche Grafik und Bildbearbeitungsprogramme verwirklicht werden, ohne das die teilweise großen Daten zur Verarbeitung erst auf einen Server geladen werden müssen. Auch in Fällen der Datensicherheit, wo der Nutzer keine Daten übers Netz schicken möchte oder soll, können die Techniken angewendet werden. So ist es z.b. möglich im Rahmen von Enterprise-Resource-Planning (ERP) eine Web-Applikation bereitzustellen, bei der aber die Stand: Seite 16 / 24