JAXenter: Hallo Manuel, hallo Thomas! Die Idee der offlinefähigen Apps ist ja gar nicht mal so neu. Dennoch ist die Entwicklung nicht trivial. Welche Herausforderungen gilt es dabei zu bewältigen?

Manuel Rauber und Thomas Hilzendegen: Eine offlinefähige App bedeutet, dass sowohl der Anwendungsrahmen (der Code der App) als auch die Daten selbst offline zur Verfügung gestellt werden müssen und die App nicht einfach nur mit einem Fehler abstürzt. Gerade bei den Daten beginnen hier schon die ersten Use-Case-abhängigen Herausforderungen. Sollen die Daten nur gelesen werden? Oder sollen die Daten auch im Offlinemodus verändert/gelöscht werden können?

Sobald man über schreibende Zugriffe nachdenkt, kommt automatisch die Überlegung von Konfliktmanagement hinzu. Gewinnt der letzte schreibende Zugriff? Soll der Benutzer entscheiden können, was im Falle eines Konflikts passiert? Alle schreibenden Änderungen müssen im Offlinemodus auf dem Gerät gespeichert werden, sodass sie beim Onlinegehen an das API geschickt werden können. Hierbei ist auch zu beachten, wie IDs der neuen Datensätze generiert werden. Zusätzlich haben Browser unterschiedliche Limits in Bezug auf die zu speichernde Datenmenge.

Weitere Herausforderungen entstehen im Backend. Zum einen muss in jedem Datensatz ein Tracking von Änderungen möglich sein. Bspw. bietet der Microsoft SQL Server den Spaltentyp rowversion hierfür an. Er kann genutzt werden, um Schnittstellen (JSON-basierte Web-APIs) zu entwickeln, die auf Basis der rowversion Delta-Updates generieren. Hierbei handelt es sich um alle geänderten Daten auf Basis der zuletzt gespeicherten rowversion auf dem Client. Bei gelöschten Datensätzen müssen die IDs separat gespeichert werden, sodass diese auch Bestandteil des Delta-Updates sind.

Spannend wird das Vorhaben, wenn Daten auf Basis von Security (Benutzerrollen und -rechten) dem Benutzer nicht mehr zur Verfügung stehen, denn hierbei ändert sich mit hoher Wahrscheinlichkeit der eigentliche Datensatz nicht. Das bedeutet, dass sich die rowversion nicht ändert, dennoch muss dieser Datensatz als „vermeintlich gelöscht“ an den Client übertragen werden.

JAXenter: Progressive Web Apps versprechen hier Abhilfe. Wie funktionieren sie?

Rauber und Hilzendegen: Obwohl Progressive Web Apps die Eigenschaft „Offline“ in sich tragen, lösen PWAs nicht gleich alle Probleme. Eine PWA hilft, den Anwendungsrahmen (Code) offline zur Verfügung zu stellen, aber nur bedingt bei den Daten. Möchte man die Daten, die man bereits angeschaut hat, nur rein lesend „offline“ anzeigen, kann eine PWA mit dem Service Worker hier auch unterstützen. Bei einem echten Synchronisierungsvorgang hilft eine PWA aber leider nicht.

JAXenter: Wie hoch schätzt Ihr den Mehraufwand beim Erstellen einer Progressive Web App im Vergleich zu anderen Single-Page Applications ein?

Rauber und Hilzendegen: Eine PWA würden wir nicht als Mehraufwand bezeichnen. Die eigentliche Single-Page Application muss sowieso erstellt werden, da diese die normale Anwendung darstellt. PWA ist nur ein weiteres Feature dieser Anwendung. Da eine PWA aus verschiedenen Charakteristika besteht, die aus einer Anwendung eine PWA machen, ist es abhängig von den Anforderungen, die man unterstützen möchte und die das dazu passende Feature implementiert.

JAXenter: Wo liegen die Nachteile einer PWA?

Rauber und Hilzendegen: Aktuell ist zu beachten, dass noch nicht alle neuen APIs, die eine PWA ausmachen, unter allen Browsern zur Verfügung stehen. Zum Beispiel ist hier das Push API zu nennen, das bereits in Chrome (auch unter Android) funktioniert, aber es unter iOS noch nicht mal klar ist, ob es überhaupt seitens Apple implementiert werden wird.

Auch sollte man sich bewusst sein, dass eine offlinefähige App nicht unbedingt auch offlinefähige Daten bedeutet, da hierfür mehr nachgedacht und implementiert werden muss. Dazu kommt, dass gewisse APIs im PWA-Umfeld verwirrend benannt sind. Allen voran das Background Sync API, dessen Name vermeintlich bedeutet, dass man Synchronisationsvorgänge starten kann. Doch es handelt sich dabei vielmehr um einen intelligenten Scheduler, der es erlaubt, zu gewissen Zeitpunkten Code auszuführen. Die Entscheidung, ob dieser Code einen echten Synchronisierungsvorgang startet, obliegt dem Entwickler.

Generell gilt natürlich auch, dass gewisse Browserlimitationen auch bei PWAs gelten, sei es die Bereitstellung von Speicherplatz oder die allgemeine Browserperformance. Und, wie im Web üblich, gilt, dass nicht alle nativen Funktionen genutzt werden können, wenn der Browser hierfür generell kein API bereitstellt.

JAXenter: Ihr demonstriert in eurem Workshop beim MobileTech Conference & Summit die Entwicklung einer PWA mit Angular und .NET Core. Welche Besonderheiten gilt es bei der Entwicklung von PWAs mit Angular zu beachten?

Rauber und Hilzendegen: Bei PWAs mit Angular ist zu beachten, dass die Anwendung zwangsläufig als Production Build erzeugt werden muss, damit der Service Worker von Angular funktioniert. Dieser Build ist deutlich zeitintensiver als ein Development Build, weswegen die Entwicklungsgeschwindigkeit darunter leiden könnte.

Ansonsten sind generell die Besonderheiten von PWAs und dem Web als Applikationsplattform zu beachten, unabhängig davon, ob Angular oder ein anderes Framework eingesetzt wird.

JAXenter: Zum Schluss nochmal eine Einschätzung aus eurer Praxis: Wann lohnt sich der Mehraufwand einer PWA – und wann nicht?

Rauber und Hilzendegen: Nutzt man die vom Angular Service Worker gegebenen PWA-Funktionalitäten, ist der Mehraufwand im Vergleich zur eigentlichen Anwendung nicht sehr hoch. Im Vergleich zu einer echten App, die im jeweiligen Store veröffentlicht wird, hat man aber folgende Vorteile:

• Die App unterliegt nicht den Regulationen und Prüfungen des Store-Anbieters.
• Auch Updates können somit jederzeit bereitgestellt werden und müssen nicht erneut durch den jeweiligen Store-Anbieter überprüft und freigegeben werden.

Der Mehraufwand für eine PWA lohnt sich aktuell nicht, wenn das Hauptziel der App iOS-Benutzer sind, da die Unterstützung auf iOS für PWAs bisher sehr rudimentär ist und o. g. Vorteile nicht als notwendig erachtet werden oder generell eine native im Store erhältliche App gewünscht ist.

JAXenter: Vielen Dank für dieses Interview!

Geschrieben von: Hartmut Schlosser

Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser