Steffen Jahr Thinktecture AG

Verbindet man Service Worker, Cache API, IndexedDB und Background Sync stehen sehr vielfältige und leistungsfähige Features zur Verfügung, um seine Anwendung offline zur Verfügung zu stellen.

Wer seine Anwendung offline nutzen will, muss hierfür verschiedene Arten von Daten offline speichern. Neben den statischen Dateien, die zum Ausführen der Anwendung notwendig sind, gibt es auch noch die Daten der Anwendung, die offline vorgehalten werden müssen. Im ersten Teil dieser Artikelserie über Service Worker habe ich gezeigt, wie man seine Anwendung offline zur Verfügung stellen kann. Schwerpunkt dieses Artikels soll nun sein, welche Möglichkeiten zur Verfügung stehen, um auch seine Daten offline zu halten.

Mit dem Cache-API bietet der Service Worker die Möglichkeit, statische Daten bzw. Antworten auf Anfragen an das Netzwerk zu speichern und weitere Anfragen an das Netzwerk mit diesen Einträgen aus dem Cache zu beantworten. Allerdings ist dies nur in bestimmten Fällen sinnvoll, da sich die Daten auf dem Server ständig verändern. Somit wird für dynamische Daten eine alternative Lösung für den Offlinezugriff benötigt. Hierfür bietet der Browser verschiedene Möglichkeiten wie z. B. SessionStorage, LocalStorage oder IndexedDB. Wie das Cache-API genutzt werden kann, kann im vorherigen Artikel nachgelesen werden.

Artikelserie

  • Teil 1: Service Worker: der Turbo für die eigene Webanwendung
  • Teil 2: Anwendungsdaten offline halten mit IndexedDB

LocalStorage: der einfache Key-Value-Speicher

Der LocalStorage ist die einfachste Art, um Daten einer Anwendung über die Sitzung des Benutzers – auch Session genannt – hinaus zu speichern. Er ist ein synchroner Speicher, in dem immer ein Schlüssel mit einem dazugehörigen Inhalt gespeichert wird. Die Größe des LocalStorages variiert je nach Browser, ist jedoch in der Regel nur wenige MB groß. Der LocalStorage ist Session-übergreifend aktiv, was bedeutet, dass auch nach Schließen des Browsers die Daten noch vorhanden sind. Er ist vor allem für Daten sinnvoll, die nur auf dem Client gespeichert werden sollen und nicht an den Server übertragen werden müssen. Dies kann z. B. genutzt werden, um Einstellungen zu speichern, die nur auf dem spezifischen Gerät relevant sind.

Um Daten im LocalStorage zu speichern, genügt es, die gewünschten Daten mittels localStorage.setItem(‚key‘, value); in den Speicher zu schreiben. Um die Daten wieder auszulesen, kann man sie mittels localStorage.getItem(‚key‘); wieder aus dem LocalStorage entnehmen. Ein großer Nachteil des LocalStorages ist, dass dieser Speicher nicht vom Service Worker genutzt werden kann. Per Definition kann der Service Worker nur auf asynchrone APIs zugreifen; der Zugriff auf den LocalStorage bleibt ihm deshalb verwehrt.

Die lokale Datenbank: IndexedDB

Ein weiterer Speicher, der genutzt werden kann, um Daten im Browser zu speichern, ist die lokale Datenbank IndexedDB. Im Gegensatz zum LocalStorage ist die Größe der IndexedDB nicht auf ein paar MB beschränkt, sondern kann ein Vielfaches davon speichern. Da es sich beim API der IndexedDB um ein asynchrones API handelt, kann die IndexedDB auch vom Service Worker genutzt werden. Werden in der IndexedDB Anwendungsdaten gespeichert, kann auch der Service Worker darauf zugreifen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

PHP Magazin 1.18 - "Alexa Skills"

Alle Infos zum Heft
579818056Anwendungsdaten offline halten mit IndexedDB
X
- Gib Deinen Standort ein -
- or -