13 Punkte von disjukr 2022-06-15 | Noch keine Kommentare. | Auf WhatsApp teilen

Bei Riiid setzen wir – wie viele andere Startups mit Fokus auf mobile Apps – darauf, Bildschirme, die plattformübergreifend auf allen mobilen Plattformen bereitgestellt werden, als Web zu entwickeln und in Form einer WebView einzubetten.

Zusätzlich nutzen wir für schnelle WebView-Entwicklungsiterationen auch einen Ansatz, bei dem wir statt einer WebView ein iframe verwenden, die mobile Native-Umgebung nachahmen und so eine virtuelle mobile Webseite erstellen, die wir für die Entwicklung der Web-Oberflächen verwenden.

Da als Webseite erstellte Oberflächen im Vergleich zu Native eine kürzere Lebensdauer haben und nur eingeschränkte API-Berechtigungen besitzen, entsteht zwangsläufig die Notwendigkeit, Code zu schreiben, der mit der Hülle kommuniziert, die die WebView einbettet (Native, parent window).

Allerdings haben die Schnittstellen auf Seiten der jeweiligen Hülle unpraktische Einschränkungen – etwa dass keine bidirektionale Kommunikation möglich ist oder nur das Ausführen beliebiger JS-Codefragmente unterstützt wird. Außerdem unterscheiden sich die Interfaces je nach Hülle stark, was das Schreiben von Kommunikationscode mühsam macht.

Wir verwenden ohnehin protobuf und grpc, wenn Web- oder Mobile-Clients mit API-Servern kommunizieren. protobuf ist eine Schema-Sprache zur Beschreibung von Service-Interfaces, und grpc ist die Protokollschicht, die abstrakte, mit protobuf definierte Requests in tatsächliche HTTP-Requests umsetzt.

Da wir für die Kommunikation mit dem Backend bereits protobuf einsetzen und unsere Engineers damit vertraut sind, haben wir schon vor längerer Zeit entschieden, protobuf zu verwenden, um die Probleme bestehender WebView-Kommunikationsmethoden zu lösen und den Workflow zu vereinheitlichen.

In den darauffolgenden Jahren haben wir bei der Entwicklung mehrerer mobiler Apps bereits einen Protobuf-Codegen-Ansatz für die Kommunikation zwischen Hülle und WebView eingesetzt. Beim Bau einer neuen App haben wir uns kürzlich entschieden, diese Technik zu verbessern und als Open Source zu veröffentlichen.
wrp ist vor diesem Hintergrund entstanden: eine Protokollschicht speziell für WebViews, die eine ähnliche Rolle wie grpc übernimmt.

wrp unterstützt TypeScript & React / Kotlin & Compose / Swift & TCA, Streams, bidirektionale Kommunikation, die Wiederherstellung des Kommunikationskontexts, wenn die Webseite neu geladen wird, und bietet bis zu einem gewissen Grad auch Lösungen für Situationen, in denen wegen langsamer Updates der Native-App Versionsunterschiede zwischen WebView und Protokoll auftreten.

Die Hauptfunktionen von wrp wurden gerade erst entwickelt, daher ist es noch nicht stabil. Wenn Sie sich für diese Technik interessieren, würden wir uns freuen, wenn Sie unserem Discord-Server beitreten und mit uns darüber sprechen.


Pbkit-Discord-Server: https://discord.gg/PHmV3nhvQq

Web - TypeScript & React

iOS - Swift & TCA

Android - Kotlin & Compose


(Dies ist eine leicht überarbeitete Fassung eines auf Twitter veröffentlichten Beitrags.)
https://twitter.com/disjukr/status/1537034296959315968

Noch keine Kommentare.

Noch keine Kommentare.