Der Weg vom HTML-Manifest zur PWA (Progressive Web App)
Das HTML Manifest war ein einfacher Mechanismus, um Webseiten in die Nähe nativer Apps zu rücken, aber mit gravierenden Einschränkungen: Die Anwendungen liefen nicht Fullscreen, sahen nicht aus wie native Anwendungen und es gab keinen Mechanismus, der die Seite als Manifest und damit Offline-fähig anzeigte.
Das HTML-Manifest war der Vorläufer für PWAs – Progressive Web Apps –, die jetzt den nativen Apps deutlich näher kommen.
Progressive Web Apps (PWA) lösen das alte HTML-Manifest ab. Sie lassen sich unter Android direkt auf dem Homescreen installieren, auch Apple hat sich nach langem Zögern für eine bessere Unterstützung entschieden. PWAs laufen im Fullscreen-Modus und bedienen sich mit einem Javascript ServiceWorker. Diese Seite ist also nur noch eine Reminiszenz an das alte HTML-Manifest.
Vorbereitungen für HTML Manifest
Die Vorbereitungen sind minimal. Auf dem Server muss eine .appcache-Datei (vormals mit der Endung .manifest) angelegt werden.
Vorsichtshalber kann die .htaccess-Datei den Dateityp .appcache mit AddType text/cache-manifest .appcache verankern. Die modernen Server erkennen den Dateityp, auch wenn der Mimetype nicht vom Server unterstützt wird.
Das HTML-Tag der Seite braucht ein zusätzliches Attribut manifest. Der Wert des manifest-Attributs ist die URL mit der appcache-Datei.
In der Appcache-Datei muss als erste Zeile CACHE MANIFEST stehen. Nach CACHE: werden die Ressourcen aufgelistet, die in den lokalen Cache des Benutzers übernommen werden sollen.
<!DOCTYPE html> <html lang="de" manifest="webstorage.appcache"> … </html>
webstorage.appcache
CACHE MANIFEST CACHE: index.html branding.png prettyphoto.jpg style.css script.js
Jede einzelne Ressource, die auf der Seite angesprochen wird, muss in den Appcache eingetragen werden. Fehlt eine Ressource, z.B. weil prettyphoto.jpg gelöscht wurde, kann der Appcache evtl. nicht zur Verfügung stehen und das Laden der Seite ohne Internet-Verbindung scheitert.
.htaccess
AddType text/cache-manifest .appcache
appcache-Datei
Das Cache Manifest kann weiter detailliert werden:
webstorage.appcache
# 2018-02-12 v0.1 # Daten, die gecached werden sollen CACHE: /style.CSS /branding.png /script.js # Seiten, die nur online genutzt werden können NETWORK: # Statische Seiten, wenn eine Anwendung nicht erreichbar ist FALLBACK: /static.html /logo.png /logo-offline.png
Webfonts im App-Cache
Zwar können auch Fonts in den App-Cache der Manifest-Datei einbezogen werden, aber wenn die Seite unter https läuft, müssen Daten aus externen Domains draußen bleiben.
webstorage.appcache
# 2018-02-12 v0.1 # Daten, die gecached werden sollen CACHE: /style.CSS /branding.png /script.js https://fonts.googleapis.com/css?family=Carrois+Gothic /fonts/ptc55f-webfont.woff2
Fontdateien, die in derselben Domain zur Verfügung gestellt werden, müssen wie alle anderen externen Resourcen in der Appcache-Liste aufgeführt werden.
Hartnäckiger App-Cache
Mit dem Cache-Manifest speichert der Browser die Seite lokal. Das Cache-Manifest wird also erst nach dem Abschluss der Entwicklung und der Tests eingesetzt.
Eines Tages ist es soweit: Die Webseite wird geändert. Da der Application Cache ausgesprochen beharrlich ist, läßt er sich in keinem Browser ohne Weiteres auffrischen. Änderungen an der Web App werden nicht angezeigt.
Wenn die Manifest-Datei geändert wird oder Fehler aufweist, geben die Browser nach und leeren das Manifest aus dem Cache. Manifest-Datei also einmal leeren – dann zweimal ein Refresh (u.U. Tab schließen und öffnen) – dann sollten Änderungen durchschlagen. Für erneute Tests wird das Manifest-Attribut natürlich aus dem html-Tag entfernt.
Das spezielle window-Objekt window.ApplicationCache gibt einem Script Zugriff auf den Application Cache des Browsers.
window.applicationCache.update(); // versucht, den Application Chache aufzufrischen window.applicationCache.status // Aufgefrischt? window.applicationCache.swapCache // neuen Cache einspielen
Nach dieser Prozedur ist der Cache zwar aufgefrischt, aber der Benutzer hat weiterhin die alte Version der Seite. Die Seite muss im Browser neu geladen werden. Dem Benutzer kann man diese Aktion nicht überlassen – er kann schließlich nicht sehen, dass seine Seite oder seine Anwendung neue Inhalte aufweist. Ein EventListener muss feststellen, dass ein neuer Cache bereit gestellt und geladen wurde und die Seite neue laden:
<script>
function onUpdateReady() {
alert('Eine neue Version dieser Seite liegt vor. Lade die Seite gleich noch einmal!');
window.location.reload();
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if (window.applicationCache.status === window.applicationCache.UPDATEREADY) {
onUpdateReady();
}
if (window.navigator.onLine) {
document.querySelector('.online').innerHTML = "Dein Browser in online";
} else {
document.querySelector('.online').innerHTML = "Du siehst die Seite offline";
}
</script>
Das alert sollte man dem Besucher ersparen, aber die Seite per Javascript neu laden.
Am Rande: Danke für den Hinweis John Doe!
Web App mit Chrome / Safari testen
Mit Chrome läßt sich der Appcache einer Web App während der Tests einfach löschen. In die URL-Zeile von Chrome alle Seiten mit Application Cache anzeigen:
chrome://appcache-internals/
Remove item und weg ist der App Cache.
Safari hat zwar Cache-Speicher löschen unter den Entwickler-Tools, aber die Seite muss ein zweites Mal neu geladen werden. Besser das Browserfenster schließen und Seite in einem neuen Browserfenster öffnen.
Gute Wirkung erzielt auch das Reload / Neuladen der Seite mit gehaltener Shifttaste.
Simulator Android Studio / XCode
PWAs müssen noch intensiver als Webseiten getestet werden. Gerätetests mit verschiedenen Version sind das A&O.
Damit man nicht gleich einen ganzen Zoo diverser iOS- und Android-Geräte pflegen muss, helfen die Geräte-Simulatoren. Für die Simulation von iOS-Geräten gibt es XCode, für Android-Geräte Android-Studio.
