Tutorial: Progressive Web Apps mit Workbox, Teil 3

Offlinemodus

Steffen Jahr

Wer eine Anwendung auf Basis von Progressive Web Apps komplett offline betreiben möchte, muss einige Dinge beachten. Beispielsweise ist es wichtig, alle notwendigen Daten an den richtigen Stellen abzulegen.

Die beiden letzten Artikel dieser Serie führten in die Welt der Progressive Web Apps (WPA) und Workbox ein. Dieser Teil beschreibt, wie sich die Anwendung offline nutzen lässt. Eine vom Internet unabhängige Progressive Web App zum Empfangen von Push-Nachrichten liegt als Demo auf GitHub (siehe ix.de/ix1812132).

Jeder kennt das Problem: Man ist unterwegs, öffnet eine Webanwendung und kann sie nicht ausführen, da keine oder nur eine unzureichende Verbindung zum Server besteht. Wer wie im zweiten Teil der Serie beschrieben seine Anwendung auf dem Home-Bildschirm des Smartphones abgelegt hat, könnte annehmen, dass sie nun ohne Internetanbindung funktioniert. Leider trifft das nicht zu, weitere Anpassungen sind notwendig. Denn noch immer handelt es sich um eine Webanwendung, auch wenn sie nicht mehr so aussieht. Ohne Internetverbindung gibt es eine Fehlermeldung (Abbildung 1).

Damit die Anwendung offline arbeiten kann, muss sie inklusive aller notwendigen Daten auf dem Client liegen. Hierbei hilft der Service Worker, das Herzstück jeder PWA. Er ist dafür zuständig, Push-Nachrichten zu empfangen, sie anzuzeigen, die Anwendung offline bereitzustellen und sie mit Updates aktuell zu halten. Beim Service Worker handelt es sich um eine eigene kleine Applikation, die neben der eigentlichen Anwendung werkelt und ihre Aufgaben im Hintergrund erledigt. Sie läuft in einem eigenen Thread, damit das Hauptprogramm bei Schwierigkeiten nicht in Mitleidenschaft gezogen wird. Das bedeutet aber auch, dass es die grafischen Komponenten nicht direkt steuern kann.

Allerdings gibt es die Möglichkeit, die beiden Komponenten über ein Nachrichtensystem kommunizieren zu lassen. Die Anwendung darf dann das User Interface auf Anweisung des Service Workers aktualisieren. Dieser besteht aus einer JavaScript-Datei, die der Entwickler in der Hauptanwendung registriert:

if('serviceWorker' in navigator) {
     navigator.serviceWorker.register ⤦
 ('serviceWorker.js');
}

Bevor das passieren kann, ist zunächst zu prüfen, ob der Browser überhaupt mit dem Service Worker zusammenarbeitet. Das geht über die Eigenschaft serviceWorker auf dem navigator-Objekt, das den User Agent des Browsers repräsentiert. Ältere Browser wollen mit dem Service Worker nicht unbedingt etwas zu tun haben. Gibt es jedoch grünes Licht, lässt er sich mit der Methode register() verankern. Als Parameter dient der Pfad zum Skript.

Service Worker mit Eigenleben

Der Service Worker unterliegt einem eigenen Lebenszyklus, in dem er verschiedene Zustände einnehmen kann (Abbildung 2). Bevor er seinen Job antritt, wird via Parsing geprüft, ob die bei der Registrierung angegebene Datei Fehler enthält. Wenn bereits ein aktiver Service Worker vorhanden ist, wird der neue zwar installiert, aber nicht aktiviert. Ein Reload des Browserfensters tauscht die alte Version gegen die neue aus. Nun wechselt er in den Wartezustand, agiert als Proxy zwischen der Anwendung und dem Netzwerk und überwacht den Datenaustausch (Abbildung 3).

Der Service Worker arbeitet ereignisbasiert, das heißt, man registriert ihn auf Events und gibt an, was er tun soll, wenn ein bestimmter Vorfall eintritt. Einen davon, nämlich push, beschrieb der zweite Tutorialteil. Ein weiterer ist fetch, der alle Anfragen an das Netzwerk überwacht und die Antworten an die Anwendung weiterleitet.

Der Entwickler muss zunächst überlegen, was offline gehalten werden soll, also welche HTML-, CSS- JavaScript-Dateien und sonstige Daten die Anwendung tatsächlich benötigt, falls sie die notwendigen Bestandteile nicht von einem Webserver laden kann. Zwei wichtige Fragen gilt es dabei zu beantworten: Was passiert, wenn die Daten nicht offline abgelegt wurden? Und was, wenn das Netzwerk nicht erreichbar ist? Antworten geben die unterschiedlichen Caching-Strategien: