PWA Fähigkeit

[ctr]

Habe hier im Forum und in den GitHub Issues schon mal gesucht, aber nichts gefunden. Gibt es derzeit Bestrebung, die CV PWA-fähig zu machen?
Nach meinem Verständnis kann es ja hier nur noch um kosmetische Arbeiten (Icon-Pfade, start_url) gehen - das grundsätzliche ServiceWorker Modell ist ja bereits in Benutzung und ein manifest gibt es auch.

Wenn da sonst noch niemand dran ist, würde ich mich mal daran versuchen und entsprechende PRs stellen. Nur als Verständnissfrage: Spielt qoxdoo da irgendwie rein (Generierung der manifest.json - https://github.com/CometVisu/CometVi.../manifest.json ) oder kann das losgelöst betrachtet werden?

Gruß,
Christian

[peuter]

Habe hier im Forum und in den GitHub Issues schon mal gesucht, aber nichts gefunden. Gibt es derzeit Bestrebung, die CV PWA-fähig zu machen?

Meines Wissens arbeitet da niemand dran. Was genau fehlt denn da überhaupt noch und welchen Vorteil hat man dann? Die CometVisu als Bookmark auf dem Homescreen ablegen funktioniert ja bereits (mit Icon), auf diese Weise lässt sich die CometVisu ja bereits wie eine App nutzen. Für Push-Notifications fehlt die Gegenstelle die diese sendet und Offline-Fähigkeit ist prinzip-bedingt ja weniger nützlich. Man braucht ja immer eine Online-Verbindung um die aktuellen Werte zu bekommen.

Wenn da sonst noch niemand dran ist, würde ich mich mal daran versuchen und entsprechende PRs stellen. Nur als Verständnissfrage: Spielt qoxdoo da irgendwie rein (Generierung der manifest.json - https://github.com/CometVisu/CometVi.../manifest.json ) oder kann das losgelöst betrachtet werden?

Die verlinkte Datei wird einfach in den Zielordner kopiert, meines Wissens wird da nichts generiert von Qooxdoo. Wenn man also was ändern möchte am Manifest kann man das einfach in dieser Datei machen.

[ctr]

Was in einem spontanen Lighthouse-Durchlauf aufgefallen ist: Die Icon URLs stimmen nicht. Relativ zur manifest.json (die ja in cv liegt) müsste sie mit

../resource/

anstatt

resource/

beginnen. Daneben gibt es keinen start_url Parameter. Das ist aber nicht so ganz trivial, weil man ja in der (statischen) manifest.json nicht die verwendete Config (und ggf. weitere per URL übergebene Parameter) kennt. D.h. Teile des Manifests müsste man mit JS dynamisch erzeugen (und dann als blob übergeben).

Der Vorteil liegt hauptsächlich in der Verwendung mit Chrome bzw. Android, da nun auch Hintergrundaktivitäten und damit ggf. auch Benachrichtigungen funktionieren würden. Unter iOS ändert sich glaube ich nicht so viel - aber man munkelt ja auch, dass demnächst alternative iOS Browser ihre eigenen Engines mitbringen dürfen, dann würde das auch hier einen Mehrwert bringen. Ansonsten vielleicht noch der gecachte Inhalt und die reine Datenverbindung - kann ich aber spontan nicht mit dem (evtl schon annähernd so guten) Ist-Zustand vergleichen.

[peuter]

In Sachen Cache hast Du halt das was der Browser Dir bietet, normalerweise sollten also alle statischen Daten nur einmal geladen werden. Wenn Du die CometVisu per HTTPS abrufst, steht auch der ServiceWorker zur Verfügung und du hast das selbe Verhalten wie in einer PWA. Das was bei der CometVisu initial fast am meisten Zeit beansprucht ist das Generieren des HTML-Codes aus der geladenen Config. Auch dafür gibt es einen Cache den die CometVisu selbst verwaltet, so dass der HTML-Code nur generiert wird, wenn sich die Config auch geändert hat. An der Stelle macht eine PWA also keinen Unterschied. Mit dem neuen Tile-Design braucht man diesen Cache gar nicht, da die Config selbst bereits gültiger HTML-Code ist der einfach in den Browser geladen wird.

In Sachen Cache wäre also der Unterschied Browser-Cache gegen Service-Worker. Wie gross dieser Unterschied in der Praxis ist, weiß ich nicht.

Für die Benachrichtigungen müsste man erstmal was einbauen, damit man damit nützliche Dinge anstellen kann. Die Grundstruktur für sowas ist bereits drin und wird bisher z.B. hierfür benutzt: https://www.cometvisu.org/CometVisu/...fications.html
Was mir da spontan als sehr nützlicher Use-Case einfällt wäre eine Push-Notification wenn es an der Tür klingelt wenn man die anklickt öffnet sich die CometVisu und zeigt das Kamerabild. Ich hab mich bisher noch nie intensiver mit den Push-Notifications per ServiceWorker auseinander gesetzt, daher weiß ich nicht ob der Use-Case damit abgebildet werden kann, bzw. müsste die CometVisu dann vermutlich ein erweitertes Deep-Link Feature bekommen, damit man diese öffnen und z.B. direkt ein Popup anzeigen lassen kann.

Zum Thema start_url: Default wäre wohl sowas "start_url": "../index.html", Alternativen bräuchte man nur wenn man mehrere Configs parallel oder nicht die default-Config als PWA nutzen möchte. Wenn der Weg das manifest dynamisch im Client zu erzeugen in allen Browser funktioniert, kann man das natürlich so machen