Offline Web Applications mit HTML5 – Teil 2

Die HTML5 Web Storage Spezifikation definiert zwei Key Value Storage Objekte zur Speicherung von Daten auf dem lokalen Endgerät des Anwenders. Das Konzept des Web Storage ähnelt Cookies, ist aber für größere Datenmengen ausgelegt. Cookies werden immer zurück an den Webserver übertragen, wenn eine neue Seite geladen wird. Bei Web Storage ist das nicht der Fall (falls die Daten doch an den Server übertragen werden sollen, muss man das mit Hilfe von Ajax selbst anstoßen). Es wird somit praktikabel größere Datenmengen zu speichern, als es mit Cookies Sinn macht.

Die beiden zentrale JavaScript Objekte von Web Storage sind localStorage und sessionStorage. Die beiden Objekte sind in der Verwendung identisch, sie unterscheiden sich in ihrer Persistierung und im Scope.

• localStorage ist für langfristige Speicherung gedacht. Die Daten werden nach dem Schließen des Fensters gespeichert und der Storage wird über alle Browserfenster geteilt.
• sessionStorage ist für kurzlebige Daten gedacht, die sich auf ein einzelnes Browserfenster beziehen. Die Daten, die im sessionStorage Objekt abgelegt werden, werden nicht persistiert, wenn das Fenster geschlossen wird- Sie werden auch nicht mit anderen Fenstern geteilt.

Die folgenden Code-Beispiele zeigen anhand des localStorage Objektes die wichtigsten Funktionen von Web Storage. Die Verwendung von sessionStorage erfolgt analog und wird deswegen nicht extra beschrieben.

Zuerst einige Methoden, um Daten in den Storage zu speichern:
// Speichern des Werts der Variable pUserName im localStorage Feld userName
localStorage.setItem(“userName”, pUsername);
// Ein bestimmtes Item löschen:
sessionStorage.removeItem(“userName”);
// Alle Einträge löschen:
sessionStorage.clear();

Zum lesenden Zugriff auf den Storage existieren die folgenden Methoden:
// bestimmten Eintrag auslesen
var myUserName = sessionStorage.getItem(“userName”);
// Anzahl der Einträge im Storage auslesen
sessionStorage.length
// Eintrag an einer bestimmten Position auslesen
sessionStorage(index i)

Vor allem beim localStorage spielt außerdem das Event Handling noch eine wichtige Rolle. Da sich alle Seiten einer Domäne das gleiche localStorage Objekt teilen, muss die Webanwendung damit umgehen können, dass das Script einer Seite Daten im localStorage verändert, die auch von anderen Seiten verwendet werden. Damit es nicht zu unvorgesehenem Verhalten kommt, können Scripts Event Handler am Storage registrieren. Storage Objekte generieren ein „storage“ Event sobald ein Script einen Wert im Key-Value Storage hinzufügt, verändert oder löscht..

Bei der Web SQL Database handelt es sich um eine JavaScript Datenbank (basierend auf SQLite). Die Spezifikation definiert eine sehr leichtgewichtige relationale Datenbank. Diese ist gedacht zur lokalen Speicherung von Daten, die zu groß sind, um sie in Cookies zu speichern (oder zu wichtig, um sie jedesmal unbeabsichtigt löschen zu lassen, wenn der User seine Cookies leert). Sie eignet sich noch besser als Web Storage zur Speicherung von größeren langlebigen Datenmengen.

Im Folgenden werden die grundlegenden Funktionalitäten der Web SQL Datenbank anhand eines Beispiels gezeigt.
//Verbindung öffnen
db = openDatabase(“ToDo”, “0.1”, “Eine Liste von Aufgaben”, 20000);
Die Funktion openDatabase nimmt vier Parameter entgegen:

– “ToDo”: hierbei handelt es sich um den Objektnamen der Datenbank
– “0.1”: Die Version der Datenbank
– “Eine Liste von Aufgaben”: Eine Beschreibung der Datenbank
– “20000”: Die geschätzte Datenbankgröße

Um eine Query abzusetzen wird die Funktion database.transaction() aufgerufen.
Diese hat einen einzigen Parameter, nämlich eine Funktion die sich um die
Ausführung der Query kümmert. Diese (oftmals anonyme) Funktion hat ein
Argument vom Typ transaction:
db.transaction(
function(tx) {
Die transaction wiederum hat eine Funktion, executeSql, die 4 Argumente entgegennimmt:
tx.executeSql
(“SELECT COUNT(*) FROM ToDo”, [],
function(result){},function(tx, error){});

Beim ersten Argument handelt es sich um den Query String. Das zweite optionale Argument erwartet ein Array von Strings, die anstatt von Fragezeichen in der Query eingesetzt werden (analog zu Prepared Statements in Java). Das dritte Argument ist eine Funktion, die im Erfolgsfall ausgeführt wird. Falls die Query erfolgreich ausgeführt wird, springt die Applikation in diese Funktion, die als Argument das geladene result entgegennimmt. Das vierte Argument ist eine Funktion, die im Fehlerfall ausgeführt wird.
Die Funktion wird aufgerufen, falls der Query nicht erfolgreich ausgeführt werden kann. Da das tx Objekt als Argument übergeben wird, kann man im Fehlerfall erneut versuchen Queries auszuführen. Eine Fehlerbeschreibung erhält man aus dem 2. Argument.

Zum jetzigen Zeitpunkt wird Web Storage von den folgenden Browsern unterstützt:
Internet Explorer 8.0
Mozilla Firefox (ab 3.0)
Safari (ab 4.0)
Google Chrome (ab 4.0)
Opera (ab 10.5)

Web SQL Database wird von den folgenden Browsern unterstützt:
Safari (ab 3.2)
Google Chrome (ab 3.0)
Opera (ab 10.5)

Alle bisherigen Implementierungen von Web SQL Database basieren auf Sqlite. Auch die Beschreibung des SQL Dialekts in der Spezifikation ist bisher lediglich eine Referenz auf Sqlite. Dies kann für einen Standard nicht als akzeptabel angesehen werden. Die Spezifikation hat deswegen laut Eigenaussage des W3C Konsortiums aktuell eine Sackgasse erreicht. Um die Standardisierung weiterzuführen, werden verschiedene Implementierungen der Spezifikation benötigt. Dies ist vor allem notwendig, da Sqlite einige Abweichungen zu anderen SQL Engines hat (z.B. bezogen auf die Möglichkeiten, welche Datentypen in Spalten gespeichert werden können).

Spezifikation – Web SQL Database
Spezifikation – Web Storage
Web Storage Demo Anwendung bei html5demos.com
Web SQL Database Demo Anwendun bei html5demos.com
Die Demo Anwendungen funktionieren nur in den oben angegebenen Browsern.
Unterstützung bieten.

Im nächsten Blogeintrag stellen wir die Web Workers Spezifikation vor. Diese ermöglicht das parallele Ausführen von losgelösten JavaScript-Prozessen im Hintergrund und kann somit bei den für Offline Anwendungen notwendigen Synchronisationsarbeiten eine Unterstützung bieten.