Progressive Web Apps (PWAs) sind voll im Trend und sorgen dafür, dass der Übergang zwischen dem Web und klassischen Apps immer mehr verschwindet. Im folgenden Artikel werden die Stärken und Schwächen einer PWA zusammen mit der Nutzung im Oracle-Umfeld, insbesondere mit APEX, näher unter die Lupe genommen.

Was zeichnet eine Progressive Web APP aus?

Progressive Web Apps sind in erster Linie erst einmal eins: ganz normale Webseiten. Denn Progressive Web Apps arbeiten nach dem Prinzip des „Progressive Enhancement“, nach dem eine Webseite auf jedem Endgerät jederzeit funktionsfähig ausgeführt werden kann, auch wenn es nur eine sehr grundlegende Webseite mit eingeschränkten JavaScript-/CSS-Features ist. Jederzeit bedeutet in diesen Fall wirklich jederzeit, selbst wenn das Gerät über keine Verbindung zum Internet verfügt. Das setzt natürlich voraus, dass die Webseite bereits einmal vorher abgerufen wurde. Dazu später mehr.

Jedes Endgerät weist natürlich seine ganz eigenen Eigenschaften auf, das können Smartphones und andere smarte Geräte sein oder aber auch der PC/Mac. Eine PWA soll auf all diesen Geräten nicht bloß funktionieren, sondern wie eine native App integriert werden und sich auch so verhalten. Wie gut das funktioniert, hängt primär von den Herstellern ab, die die für die PWAs notwendigen APIs implementieren müssen. Google ist bei diesem Thema Vorreiter und die neusten PWA-Features sind in Chrome und der Android-Plattform am schnellsten integriert. Auch Mozilla und Microsoft sind ganz vorne mit dabei. Nur Apple zögert. So wurden zwingend notwendige APIs erst im letzten Jahr von Apple in den Safari-Browser integriert. Damit laufen PWAs zwar grundlegend im Ökosystem von Apple, jedoch werden die neusten Features nur nach und nach implementiert.

Die Zurückhaltung von Apple dürfte einen Grund haben. So ist Apple bekannt für seine restriktive Auswahl von Apps für den hauseigenen App-Store. Einer der zentralen Punkte von Progressive Web Apps ist jedoch, dass deren Distribution und Installation ohne einen App-Store möglich ist. Mit steigender Popularität und Verbreitung von PWAs würde Apple also die Möglichkeiten zur Einschränkung von Apps im eigenen Ökosystem nach und nach verlieren.

Nachfolgend werden weitere Eigenschaften genannt, die eine PWA ausmachen.

  • Responsive: Die Oberfläche der Anwendung passt sich dem Endgerät an
  • HTTPS: Zwingend notwendig für die Nutzung von Service Worker
  • Immer die neuste Version: Da es sich um Webseiten handelt, sind keine Updates durch einen App Store notwendig
  • Push-Benachrichtigungen: Die App kann den Nutzer zur Interaktion animieren
Abbildung 1: Beispiel eines Web-App-Manifests (Quelle: Till Albert)

Abbildung 1: Beispiel eines Web-App-Manifests (Quelle: Till Albert)

Wo werden PWAs bereits eingesetzt und warum?

Interessant sind PWAs vor allem für den E-Commerce-Bereich, denn die Conversion-Rate, die Anzahl der Website-Besucher, die mit der Seite interagieren oder zum Kunden werden, lässt sich mithilfe von PWAs erhöhen. Das liegt vor allem an der einfachen Handhabung von PWAs. Der Nutzer muss nicht erst zwingend eine App installieren, sondern kann diese mit wenigen Klicks aus dem Browser direkt installieren.

Neben der einfachen Handhabung zur Installation tragen noch weitere Features zur Steigerung der Benutzerfreundlichkeit bei. So kann sich der Einsatz einer PWA positiv auf die Ladezeit der Webseite auswirken. Das wird zum einen durch die Service-Worker-Technologie ermöglicht, die das Caching von Dateien und damit auch eine Offline-Fähigkeit ermöglicht. Zum anderen durch den typischen Aufbau einer PWA, bei dem versucht wird, das Grundgerüst der Anwendung immer zu cachen, damit dieses beim Laden der Webseite sofort verfügbar ist. Mehr dazu später.

Die Webseite pwa.bar bietet eine interessante Übersicht über PWAs großer Unternehmen. Laut dieser konnte zum Beispiel AliExpress seine Conversion Rate mithilfe einer PWA mehr als verdoppeln.

Ebenfalls interessant, um mit dem Nutzer in Verbindung zu bleiben, selbst wenn dieser die PWA nicht installiert hat, sind Push-Benachrichtigungen. Mit diesen können Nutzer, sobald sie diese abonniert haben, Benachrichtigungen auch dann erhalten, wenn sie gerade nicht auf der Website selbst surfen.

Aufbau einer Progressive Web App

Wie bereits anfangs erwähnt, handelt es sich im Prinzip um eine ganz normale Webseite. Das eigentliche Herzstück einer PWA ist aber das Service Worker API, das einige wichtige Funktionen bereitstellt, die eine Progressive Web App erst zu dem machen, was sie ist. Dadurch werden wichtige Funktionen wie OfflineFähigkeit, Caching und Push-Benachrichtigungen erst ermöglicht.

Doch was genau muss man sich unter einem Service Worker vorstellen? Am einfachsten lässt es sich wohl mit einer Art Proxy vergleichen, der zwischen dem Webbrowser und dem Server interagiert. Alle Anfragen, die vom Client ausgehen, werden durch den Service Worker verarbeitet. Das hat den großen Vorteil, dass der Service Worker so sicherstellen kann, dass der Client immer eine Antwort erhält. Falls eine Verbindung zum Internet besteht, wird die Anfrage normal weitergeleitet; falls keine Verbindung besteht, so wird in einer kleinen Datenbank im Browser nachgeschaut, ob für den Request bereits ein Eintrag vorhanden ist. Ist das der Fall, wird dieser dann zurückgegeben und der Client kann die Antwort normal verarbeiten. Je nach Konfiguration wird bei jeder Anfrage und vorhandener Internetverbindung die Ressource in der Datenbank aktualisiert. Ist eine Ressource noch nicht in der Datenbank vorhanden und wird dennoch ohne Internetverbindung abgefragt, so kann eine Seite mit einer nutzerfreundlichen Fehlermeldung angezeigt werden. Zwingend notwendig für den Einsatz von Service Worker ist die Verwendung von HTTPS. Aus Gründen der Sicherheit funktionieren Service Worker ohne HTTPS nicht, da sie mächtige Funktionen übernehmen und Antworten des Servers durch eigene Inhalte ersetzen können.

Ein weiterer zentraler Bestandteil einer Progressive Web App ist das Web-App- Manifest. Dabei handelt es sich um ein Dokument im JSON-Format, das verschiedene Meta-Daten enthält und das Verhalten sowie verschiedene Eigenschaften einer PWA beschreibt. Das sind zum Beispiel der Name der App und eine Beschreibung, Icons in verschiedenen Auflösungen, die Standard-Ausrichtung der App oder Theme-Farben. Der Hauptzweck des Manifests ist die Installierbarkeit der PWA auf den verschiedenen Endgeräten. Erst durch das Manifest erkennt der Browser, dass es sich um eine Web App handelt.

Implementierung in APEX

Wie anfangs erwähnt, zeichnet sich eine Progressive Web App durch einige Eigenschaften aus. Dabei kommt uns zugute, dass APEX einige dieser Eigenschaften sowieso im Standard schon unterstützt. So sind alle APEX- Anwendungen, die mit dem Universal Theme entwickelt wurden, von Hause aus bereits responsive und funktionieren in allen gängigen Browsern. Auch ein Appähnliches Interface kann damit schnell implementiert werden. HTTP ist mit APEX ebenfalls kein Problem und sollte sowieso Standard sein.

Damit haben wir mit APEX also schon ein paar Punkte abgedeckt, ohne einen größeren Implementierungs-Aufwand. Einen besonderen Mehrwert zur klassischen APEX-Anwendung haben wir allerdings noch nicht. Das ändert sich jedoch, sobald das Web-App-Manifest in die Anwendung integriert wird (siehe Abbildung 1). Eine einfache und schnelle Möglichkeit, um das Manifest generieren zu können, bietet die Webseite pwabuilder.com, die auch direkt dabei hilft, passende Icons für die verschiedenen Formate der Geräte zu erstellen. Diese Icons werden dann später, wenn die App installiert wird, als App-Icon verwendet.

Besonders wichtig ist dabei das Attribut „start_url“, das den Pfad zum Einstiegspunkt der App enthält, wenn die App gestartet wird.

Das generierte Manifest muss nun noch in die APEX-Anwendung integriert werden. Dazu genügt es jedoch nicht, dieses in die APEX-Anwendung hochzuladen, wie sonst bei JavaScript-Dateien üblich. Denn das Manifest muss von der RootEbene der Anwendung aus erreichbar sein. Wenn also eine APEX-Anwendung die URL https://host.de/ords/f?p=102:30 hat, dann muss das Manifest unter https://host.de/manifest.json erreichbar sein. Dies kann jedoch nur erreicht werden, wenn die Datei im entsprechenden Verzeichnis des Web-Servers abgelegt wird. Ein Zugriff auf den Web-Server ist also zwingend notwendig, womit viele Cloud Dienste nicht dafür geeignet sind, da dieser Zugang oftmals fehlt.

Ist die Datei schließlich auf dem WebServer abgelegt, muss sie noch in der APEXAnwendung referenziert werden. Damit das Manifest korrekt vom Browser erkannt werden kann, muss es im Head-Bereich vor dem Body des HTML-Dokuments geladen werden. Das wird erreicht, indem in den User Interfaces (Shared Components) der APEX-Anwendung die Datei entsprechend verlinkt wird (siehe Abbildung 2).

Sobald dies erledigt ist, kann die APEXAnwendung nun ganz einfach mit einem Klick, ohne Nutzung eines App Stores, als App auf den meisten Endgeräten installiert werden. Das funktioniert, je nach Browser, leicht unterschiedlich, im Chrome- Browser findet man den Eintrag „Progressive Web App installieren…“ im Menü oben rechts. Das gilt übrigens nicht nur für mobile Endgeräte wie Smartphones. Auch auf einem PC oder Mac lassen sich die PWAs über den Browser als Applikation installieren. Sie können, wie eine normal installierte Anwendung, vom Desktop oder Startmenü aus aufgerufen werden und arbeiten in einem eigenständigen Fenster. Damit lässt sich mit relativ wenig Aufwand eine oft gewünschte Anforderung der Anwender umsetzen.

Offline-Fähigkeit mit APEX?

Eines der spannendsten Features einer Progressive Web App ist wohl die Möglichkeit, diese auch ohne eine Verbindung zum Internet nutzen zu können. Wie bereits vorher erwähnt, basiert die OfflineFähigkeit auf einem Service Worker in Verbindung mit einer kleinen Datenbank im Browser. Eine der Grundlagen, damit dieses Konzept erfolgreich funktioniert, ist eine strikte Trennung von Inhalten, die immer wiederverwendet werden, also das Grundgerüst der Anwendung, und den eigentlichen Daten, die bei jeder Anfrage abweichen können. Dieses Prinzip bezeichnet Google als Application Shell. Dieses Grundgerüst wird vom Service Worker immer im Cache beziehungsweise in der Datenbank im Browser gespeichert und kann beim Laden der Seite sofort ohne große Verzögerung angezeigt werden, eben auch offline. Dynamische Daten werden dann mit weiteren Anfragen entweder aus dem Internet oder ebenfalls aus der Datenbank im Browser nachgeladen.

Abbildung 2: Einbindung des Web-App-Manifests in die APEX-Anwendung (Quelle: Till Albert)

Abbildung 2: Einbindung des Web-App-Manifests in die APEX-Anwendung (Quelle: Till Albert)

Möchte man ein solches Konzept nun mit APEX umsetzen, so wird man schnell feststellen, dass dies nur eingeschränkt möglich ist. Grund dafür ist, dass APEX eben seine Inhalte nicht getrennt nach User Interface / Application Shell und Daten vom Server ausliefert, sondern diese vermischt. Das liegt vor allem auch daran, dass das meiste HTML auf der Seite des Servers generiert wird. Installiert man nun trotzdem einen Service Worker, der die APEX-Anwendung cacht, so wird eben die gesamte Seite im aktuellen Zustand in den Cache geschrieben, und nicht nur das Grundgerüst. Auch müsste sichergestellt werden, dass Komponenten, wie das Interactive Grid oder Interactive Report, keine Anfragen an den Server stellen, nachdem die Seite aus dem Cache geladen wurde beziehungsweise, wenn die Anwendung keine Verbindung zum Internet hat. Das passiert zum Beispiel beim Filtern oder Aggregieren von Daten im Interactive Report. Je nach Anwendungsfall kann das für Anwendungen, auf die größtenteils lesend zugegriffen wird, ein Kompromiss sein. Eine offline-fähige CRUD-Anwendung wird man auf diese Weise aber nicht umsetzen können. Zumindest nicht mit den Standard-Mitteln von APEX. Eine Herangehensweise, mit zusätzlichem Aufwand, wäre eine Formular-Seite ohne Standard APEX Fetch und Save-Prozesse. Um das Formular mit Daten zu füllen, müsste nach dem Laden der Seite eine Anfrage an die Oracle- Datenbank via REST gemacht werden, wobei die REST-Anfrage mit purem JavaScript implementiert wird. Das Speichern der Daten müsste ebenfalls auf diese Weise geschehen. Mit dieser Herangehensweise wären bei der Anfrage der Daten diese von der APEXOberfläche getrennt, und könnten mithilfe eines Service Worker in eine Datenbank im Browser geschrieben werden.

Wie auch beim Web-App-Manifest ist auch bei der Erstellung des Service Worker die Seite pwabuilder.com eine große Hilfe. Damit lässt sich, je nach Anwendungsfall, der Service Worker nach Wunsch konfigurieren und dieser kann dann anschließend in die APEX-Anwendung eingebunden werden. Wichtig ist dabei wieder, dass die JavaScript-Datei des Service Worker auf dem Web Server liegt, wie auch das Manifest.

Kurzer Exkurs: PWA mit Oracle JET

Wie man die Offline-Fähigkeit von WebAnwendungen im Oracle-Umfeld einfacher umsetzen kann, lässt sich an Oracle JET zeigen. Das JavaScript-Framework basiert auf einer anderen Architektur. Im Gegensatz zu APEX erfolgt eine strikte Trennung von User Interface und den eigentlichen Daten. Somit lässt sich die Application Shell mithilfe von Service Worker im Browser cachen; die dynamischen Inhalte werden getrennt davon angefragt und gespeichert. Von Oracle gibt es für das Arbeiten mit Offline-Daten in Oracle JET sogar ein eigenes Toolkit, das die Arbeit erleichtert [1]. Das sogenannte „Offline Persistence Toolkit“ ist Open Source und kann in jedem JavaScriptProjekt, auch ohne Oracle Jet, genutzt werden.

Fazit und Ausblick

Die Möglichkeiten der Technologie rund um Progressive Web Apps können eine normale APEX-Anwendung um interessante neue Features erweitern. Auch wenn die Offline-Fähigkeit derzeit nur eingeschränkt mit APEX realisierbar ist, so kann das Web-App-Manifest relativ schnell in eine APEX-Anwendung integriert werden und bringt damit bereits einen deutlichen Mehrwert für den Endanwender mit. Dieser Mehrwert wird in naher Zukunft noch vergrößert werden, wenn mehr und mehr native Features als APIs zur Verfügung gestellt werden. So sind für die nächsten Monate unter anderem ein API für den Zugriff auf die Kontakte auf dem Endgerät geplant sowie ein API für den Zugriff auf bestimmte Ordner des lokalen Dateisystems. Und das ist erst die Spitze des Eisbergs, denn die Liste an geplanten Schnittstellen für die Zukunft ist lang und macht bereits jetzt Freude auf mehr [2].

Quellen [1] https://github.com/oracle/ offline-persistence-toolkit [2] https://developers.google.com/web/ updates/capabilities

Jetzt teilen auf:

Jetzt kommentieren