So verwandeln Sie Ihre Website in eine mobile App mit 7 Zeilen JSON

Ein neuer Ansatz zum Mischen von Web Engine in native Apps

Was wäre, wenn ich Ihnen sagen würde, dass die 7 Zeilen von JSON in Orange alles sind, was Sie brauchen, um eine Website in eine mobile App zu verwandeln? Sie müssen Ihre Website nicht mithilfe einer Framework-API neu schreiben, damit sie sich wie eine mobile App verhält. Bringen Sie Ihre vorhandene Website einfach so wie sie ist und mischen Sie sie mit einer einfachen URL-Referenz in eine native App.

Und was ist, wenn Sie durch einfaches Ändern des JSON-Markups sofort auf alle nativen APIs, nativen UI-Komponenten sowie nativen Ansichtsübergänge zugreifen können?

So sieht ein minimales Beispiel in Aktion aus:

Beachten Sie, wie ich eine github.com-Webseite eingebettet habe, der Rest des Layouts jedoch alle nativen UI-Komponenten enthält, z. B. den Navigationsheader und die untere Registerkartenleiste. Der Übergang erfolgt automatisch nativ, ohne dass Sie die Website mithilfe von APIs neu schreiben müssen.

Bevor ich erkläre, wie, fragen Sie sich vielleicht: "Das ist cool, aber können Sie etwas anderes tun, als nur die Webseite in einem nativen App-Frame anzuzeigen?"

Gute Frage, denn das ist das Hauptthema dieses Beitrags. Sie müssen lediglich einen nahtlosen bidirektionalen Kommunikationskanal zwischen der Webansicht und der App erstellen, damit die übergeordnete App alle JavaScript-Funktionen in der Webansicht auslösen und die Webansicht nach außen greifen kann, um native APIs aufzurufen.

Hier ist ein solches Beispiel:

Beachten Sie, dass diese Ansicht Folgendes enthält:

  1. Native Navigations-Header mit integrierter Übergangsfunktion
  2. Eine Webansicht, in die eine QR-Codegenerator-Web-App eingebettet ist
  3. Eine native Chat-Eingabekomponente unten

All dies kann beschrieben werden, indem nur einige der oben gezeigten JSON-Markup-Attribute angepasst werden.

Beachten Sie schließlich, dass sich der QR-Code ändert, wenn Sie etwas über die Chat-Eingabe eingeben. Die Chat-Eingabe löst eine JavaScript-Funktion in der QR-Code-Web-App aus, die das Bild neu generiert.

Kein App-Entwicklungs-Framework hat versucht, dieses Problem der „nahtlosen Integration der Webansicht in native Apps“ grundlegend zu lösen, da alle darauf ausgerichtet sind, entweder 100% native oder 100% HTML5-Seite auszuwählen.

Wenn Sie jemanden über die Zukunft mobiler Apps sprechen hören, hören Sie ihn wahrscheinlich über „Wird es der HTML5-Ansatz sein, der sich durchsetzt? Oder wird es einheimisch sein? "

Keiner von ihnen sieht native und html als etwas, das nebeneinander existieren und darüber hinaus Synergien schaffen und Dinge erreichen könnte, die sonst nicht einfach möglich sind.

In diesem Artikel werde ich erklären:

  • Warum das Mischen von Web-Engine und nativen Komponenten oft eine gute Idee ist.
  • Warum eine nahtlose Integration von HTML und Native nicht einfach ist und wie ich eine implementiert habe.
  • Am wichtigsten ist, wie SIE damit sofort Ihre eigene App erstellen können.

Warum sollten Sie HTML in einer nativen App verwenden?

Bevor wir weiter gehen, wollen wir zunächst diskutieren, ob dies überhaupt eine gute Idee ist und wann Sie diesen Ansatz wählen möchten. Hier sind einige mögliche Anwendungsfälle:

1. Verwenden Sie Web Native-Funktionen

Einige Teile Ihrer App können möglicherweise besser mithilfe der Web-Engine implementiert werden. Beispielsweise ist Websocket eine web-native Funktion, die für die Webumgebung entwickelt wurde. In diesem Fall ist es sinnvoll, die integrierte Web-Engine (WKWebView für iOS und WebView für Android) zu verwenden, anstatt eine Bibliothek eines Drittanbieters zu installieren, die Websocket im Wesentlichen „emuliert“.

Sie müssen keinen zusätzlichen Code installieren, um etwas zu tun, das Sie kostenlos tun können, was uns zum nächsten Punkt bringt.

2. Vermeiden Sie große Binärgrößen

Möglicherweise möchten Sie schnell Funktionen integrieren, für die ansonsten eine große Bibliothek von Drittanbietern erforderlich ist.

Um beispielsweise einen QR-Code-Bildgenerator nativ einzubauen, müssen Sie eine Bibliothek eines Drittanbieters installieren, die die Binärgröße erhöht. Aber wenn Sie die Web View Engine und eine JavaScript-Bibliothek über eine einfache verwenden

3. Es gibt keine zuverlässige mobile Bibliothek

Für einige Spitzentechnologien gibt es noch keine zuverlässige und stabile mobile Implementierung.

Glücklicherweise verfügen die meisten dieser Technologien über Webimplementierungen. Der effizienteste Weg, sie zu integrieren, ist die Verwendung ihrer JavaScript-Bibliothek.

4. Erstellen Sie teilweise native, teilweise webbasierte Apps

Viele neue Entwickler, die ihre Website in eine mobile App portieren möchten, werden entmutigt oder überfordert, wenn sie feststellen, dass einige ihrer vorhandenen Website-Funktionen zu komplex sind, um sie für jede mobile Plattform schnell von Grund auf neu zu schreiben.

Beispielsweise verfügen Sie möglicherweise über eine einzelne Webseite, die zu komplex ist, um sofort in eine mobile App konvertiert zu werden. Der Rest Ihrer Website kann jedoch problemlos konvertiert werden.

In diesem Fall wäre es schön, wenn es eine Möglichkeit gäbe, den größten Teil der App nativ zu erstellen, aber für diese bestimmte komplexe Webseite sollte sie irgendwie nahtlos als HTML in die App integriert werden.

Wie funktioniert es?

A. Jasonette

Jasonette ist ein Open Source-Ansatz auf Markup-Basis zum Erstellen plattformübergreifender nativer Apps.

Es ist wie ein Webbrowser, aber anstatt HTML-Markup in Webseiten zu interpretieren, interpretiert es JSON-Markup in native Apps auf iOS und Android.

So wie alle Webbrowser genau den gleichen Code haben, aber durch Interpretation verschiedener HTML-Markups bei Bedarf alle Arten von verschiedenen Web-Apps bereitstellen können, haben alle Jasonette-Apps genau die gleiche Binärdatei und interpretieren verschiedene JSON-Markups bei Bedarf, um Ihre App zu erstellen . Die Entwickler müssen den Code nie berühren. Stattdessen erstellen Sie Apps, indem Sie ein Markup schreiben, das in Echtzeit in native Apps übersetzt wird.

Mehr über Jasonette erfahren Sie hier.

Während es bei Jasonette im Kern um das Erstellen nativer Apps geht, geht es in diesem Artikel um die Integration von HTML in die native Kern-Engine. Lassen Sie uns darüber sprechen.

B. Jasonette Web Container

Native Apps sind großartig, aber manchmal müssen wir Webfunktionen nutzen.

Die Integration von Webansichten in eine native App ist jedoch eine schwierige Angelegenheit. Eine nahtlose Integration erfordert:

  1. Die Webansicht sollte als Teil des nativen Layouts integriert werden: Die Webansicht sollte als Teil des nativen Layouts in die App integriert werden und wird wie alle anderen nativen UI-Komponenten behandelt. Andernfalls fühlt es sich klobig an und es fühlt sich genau so an, wie es ist - eine Website.
  2. Die übergeordnete App kann den untergeordneten Webcontainer steuern: Die übergeordnete App sollte die untergeordnete Webansicht frei steuern können.
  3. Untergeordneter Webcontainer kann native Ereignisse in der übergeordneten App auslösen: Die untergeordnete App sollte in der Lage sein, die Ereignisse der übergeordneten App auszulösen, um native APIs auszuführen.

Dies ist eine Menge Arbeit, daher habe ich zuerst nur am ersten Teil des Puzzles gearbeitet - einfach einen Webcontainer in das native Layout eingebettet - und es als Version 1 veröffentlicht:

Dies war bereits ziemlich nützlich, hatte aber immer noch die Einschränkung, nicht interaktiv zu sein.

Die übergeordnete App konnte den untergeordneten Webcontainer nicht steuern, und das untergeordnete Element konnte den übergeordneten Webcontainer nicht über Ereignisse informieren, wodurch der Webcontainer vollständig von der Außenwelt isoliert blieb.

C. Jasonette Web Container 2.0: Machen Sie es interaktiv

Nach der Veröffentlichung von Version 1 habe ich mit dem zweiten Teil des Puzzles experimentiert - dem Webcontainer Interaktivität hinzugefügt.

Im nächsten Abschnitt werden die Lösungen erläutert, die hinzugefügt wurden, um die zuvor statischen Webcontainer interaktiv zu gestalten und sie erheblich leistungsfähiger zu machen.

Implementierung: Interaktiver Webcontainer

1. Laden über URL

Problem

Zuvor mussten Sie in Version 1, um den Webcontainer als Hintergrundansichtskomponente zu verwenden, zuerst den Typ $ jason.body.background.type auf "html" setzen und dann den HTML-Text unter $ jason.body.background.text fest codieren Attribut wie folgt:

{"$ jason": {"head": {...}, "body": {"background": {"type": "html", "text": " Hallo Welt "}}}}

Natürlich wollten die Leute in der Lage sein, den Container einfach über eine Web-URL zu instanziieren, anstatt den gesamten HTML-Text in einer einzigen Zeile fest zu codieren.

Lösung

Der Webcontainer 2.0 hat das URL-Attribut hinzugefügt. Sie können eine lokale Datei einbetten: // HTML wie folgt (es wird aus der lokalen HTML-Datei geladen, die Sie mit der App liefern):

{"$ jason": {"head": {...}, "body": {"background": {"type": "html", "url": "file: //index.html"}} }}

Oder binden Sie eine entfernte http [s]: // URL wie diese ein (sie wird aus einem entfernten HTML-Code geladen):

{"$ jason": {"head": {...}, "body": {"background": {"type": "html", "url": "https://news.ycombinator.com" }}}}

2. Übergeordnete App <=> Webcontainerkommunikation

Problem

Bisher dienten Webcontainer nur zur Anzeige von Inhalten und nicht interaktiv. Dies bedeutete, dass KEINE der folgenden Möglichkeiten möglich war:

  1. Jasonette => Webcontainer: Rufen Sie von Jasonette aus JavaScript-Funktionen im Webcontainer auf.
  2. Web Container => Jasonette: Ruft die native API aus dem Web Container Code auf.

Sie konnten lediglich den Webcontainer anzeigen. Dies war ähnlich wie beim Einbetten eines Iframes in eine Webseite, aber die Hauptwebseite hatte keinen Zugriff auf das, was sich im Iframe befand.

Lösung

Der springende Punkt von Jasonette ist das Entwerfen einer Standard-Markup-Sprache zur Beschreibung plattformübergreifender mobiler Apps. In diesem Fall benötigten wir eine Auszeichnungssprache, die die Kommunikation zwischen der übergeordneten App und dem untergeordneten Webcontainer umfassend beschreiben kann.

Um dies zu erreichen, habe ich einen JSON-RPC-basierten Kommunikationskanal zwischen der übergeordneten App und dem untergeordneten Webcontainer entwickelt. Da alles auf Jasonette in JSON-Objekten ausgedrückt wird, war es absolut sinnvoll, das JSON-RPC-Standardformat als Kommunikationsprotokoll zu verwenden.

Um einen JavaScript-Funktionsaufruf in den Webcontainer zu tätigen, deklarieren wir eine Aktion namens $ agent.request:

{"type": "$ agent.request", "options": {"id": "$ webcontainer", "method": "login", "params": ["username", "password"]}}

$ agent.request ist die native API, die eine JSON-RPC-Anforderung in den Webcontainer auslöst. Um es zu verwenden, müssen wir ein Optionsobjekt als Parameter übergeben.

Das Optionsobjekt ist die eigentliche JSON-RPC-Anforderung, die an den Webcontainer gesendet wird. Schauen wir uns an, was jedes Attribut bedeutet:

  • id: Der Webcontainer basiert auf einer untergeordneten Architektur namens Agent. Normalerweise können Sie mehrere Agenten für eine einzelne Ansicht haben, und jeder Agent kann seine eindeutige ID haben. Der Webcontainer ist jedoch ein spezieller Agententyp, der nur die ID $ webcontainer haben kann. Deshalb verwenden wir diese ID hier.
  • Methode: Der aufzurufende JavaScript-Funktionsname
  • params: Das Array von Parametern, die an die JavaScript-Funktion übergeben werden sollen.

Das vollständige Markup würde ungefähr so ​​aussehen:

{"$ jason": {"head": {"action": {"$ load": {"type": "$ agent.request", "options": {"id": "$ webcontainer", "method ":" login "," params ": [" alice "," 1234 "]}}}," body ": {" header ": {" title ":" Web Container 2.0 "}," background ": { "type": "html", "url": "file: //index.html"}}}}

Dieses Markup sagt:

Wenn die Ansicht geladen wird ($ jason.head.actions. $ Load), stellen Sie eine JSON-RPC-Anforderung an den Webcontainer-Agenten ($ agent.request), in dem die Anforderung unter Optionen angegeben ist.

Der Webcontainer ist unter $ jason.body.background definiert. In diesem Fall wird eine lokale Datei mit dem Namen file: //index.html geladen.

Es wird nach einer JavaScript-Funktion namens login gesucht und die beiden Argumente unter params ("alice" und "1234") übergeben.

Login ("Alice", "1234")

Ich habe nur erklärt, wie die übergeordnete App die JavaScript-Funktionsaufrufe des untergeordneten Webcontainers auslösen kann. Sie können jedoch auch das Gegenteil tun und den Webcontainer die native API der übergeordneten App auslösen lassen.

Weitere Informationen finden Sie in der Agentendokumentation.

Beispiel

Kommen wir zurück zu dem QR-Codebeispiel, das ich oben kurz geteilt habe:

  1. Die Fußzeileneingabekomponente ist zu 100% nativ.
  2. Der QR-Code wird vom Webcontainer als Web-App generiert.
  3. Wenn ein Benutzer etwas eingibt und auf "Generieren" drückt, ruft er die Aktion "$ agent.request" im Webcontainer-Agenten auf und ruft die JavaScript-Funktion "qr" auf.

Das Beispiel können Sie hier ansehen.

3. Skriptinjektion

Problem

Manchmal möchten Sie möglicherweise JavaScript-Code dynamisch in den Webcontainer einfügen, nachdem der ursprüngliche HTML-Code vollständig geladen wurde.

Stellen Sie sich vor, Sie möchten eine benutzerdefinierte Webbrowser-App erstellen. Möglicherweise möchten Sie in jede Webansicht Ihr eigenes benutzerdefiniertes JavaScript einfügen, um das Verhalten der Webansicht anzupassen, ähnlich wie die Funktionsweise von Webbrowser-Erweiterungen.

Selbst wenn Sie keinen Webbrowser erstellen, können Sie die Skriptinjektionsmethode verwenden, wenn Sie ein benutzerdefiniertes Verhalten für eine URL wünschen, über deren Inhalt Sie keine Kontrolle haben. Die einzige Möglichkeit, zwischen der nativen App und dem Webcontainer zu kommunizieren, ist die $ agent-API. Wenn Sie den HTML-Inhalt jedoch nicht ändern können, können Sie die $ agent-Schnittstelle nur durch dynamische Injektion in den Webcontainer einfügen.

Lösung

Wie im vorherigen Abschnitt erwähnt, ist der Webcontainer $ jason.body.background nur ein weiterer Agent. Dies bedeutet, dass Sie dieselbe $ agent.inject-Methode verwenden können, die regulären Agenten zur Verfügung steht.

4. URL Klicken Sie auf Handhabung

In der Vergangenheit gab es nur zwei Möglichkeiten, wie ein Webcontainer mit Linkklicks umgehen konnte:

  1. Schreibgeschützt: Behandeln Sie den Webcontainer als schreibgeschützt und ignorieren Sie alle Ereignisse wie Berühren oder Scrollen. Alle Webcontainer sind schreibgeschützt, es sei denn, Sie weisen sie an, sich wie unten beschrieben wie ein normaler Browser zu verhalten.
  2. Regelmäßiges Browserverhalten: Lassen Sie Benutzer mit der Seite interagieren, indem Sie sich wie ein normaler Browser verhalten. Sie deklarieren es, indem Sie "type": "$ default" als Aktionsattribut festlegen.

Problem

Beides sind „Alles oder Nichts“ -Lösungen.

  • Im Fall "Readonly" werden alle Ihre Interaktionen vom Webcontainer vollständig ignoriert.
  • Im Fall "Normales Browserverhalten" fungiert der Webcontainer buchstäblich als Browser. Wenn Sie auf einen Link klicken, werden Sie einfach zu diesem Link weitergeleitet, indem Sie die Seite wie eine Webseite aktualisieren. Es gab keine Möglichkeit, den Klick zu entführen und eine native API aufzurufen.

Lösung

Mit dem neuen Webcontainer können Sie jetzt eine beliebige Aktion an den Webcontainer $ jason.body.background anhängen, um Link-Klick-Ereignisse zu verarbeiten.

Schauen wir uns ein Beispiel an:

{"$ jason": {"head": {"action": {"displayBanner": {"type": "$ util.banner", "options": {"title": "Clicked", "description": "Link {{$ jason.url}} angeklickt!" }}}}, "body": {"background": {"type": "html", "url": "file: //index.html", "action": {"trigger": "displayBanner"} }}}}

Hier haben wir "Trigger": "displayBanner" an den Webcontainer angehängt. Dies bedeutet, dass ein Benutzer, wenn er auf einen Link im Webcontainer klickt, die Aktion displayBanner auslöst, anstatt die Webansicht damit umgehen zu lassen.

Wenn Sie sich die displayBanner-Aktion ansehen, werden Sie auch die Variable $ jason bemerken. In diesem Fall wird der angeklickte Link durch die Variable $ jason geleitet. Wenn Sie beispielsweise auf eine URL mit dem Namen "https://google.com" geklickt haben, hat der $ jason den folgenden Wert:

{"url": "https://google.com"}

Dies bedeutet, dass Sie verschiedene Aktionen selektiv auslösen können, indem Sie den Wert $ jason.url überprüfen.

Nehmen wir ein weiteres Beispiel, in dem wir einen benutzerdefinierten Webbrowser implementieren:

{"$ jason": {"head": {"action": {"handleLink": [{"{{#if $ jason.url.indexOf ('signin')! == -1}}": {" Geben Sie ":" $ href "," options ": {" url ":" file: //key.html "}}}, {" {{#else}} ": {" type ":" $ default "} ein }]}}, "body": {"background": {"type": "html", "url": "file: //index.html", "action": {"trigger": "handleLink"} }}}}

Wir testen, ob die URL die Zeichenfolgenanmeldung enthält, und führen dann je nach Ergebnis zwei verschiedene Aktionen aus.

  1. Wenn es die Anmeldung enthält, wird eine neue Ansicht geöffnet, in der Sie sich nativ anmelden können.
  2. Wenn es keine Anmeldung enthält, führen Sie einfach die Aktion "type": "$ default" aus, damit es sich wie ein normaler Browser verhält.

Beispiel Verwendung

Erstellen eines benutzerdefinierten Webbrowsers

Wir können jetzt die Tatsache nutzen, dass der neue Webcontainer:

  1. Nehmen Sie ein URL-Attribut, um sich selbst zu laden, und fungieren Sie als vollwertiger Browser
  2. Behandeln Sie Link-Klicks abhängig von der URL selektiv

Wir können sogar eine benutzerdefinierte Webbrowser-App mit nur einem Dutzend Zeilen JSON erstellen. Da wir jetzt jeden Link-Klick entführen können, können wir uns $ jason.url ansehen und je nach URL die gewünschten Aktionen ausführen.

Schauen Sie sich zum Beispiel das folgende Beispiel an:

Auf der linken Seite sehen wir, dass sich das Klicken auf einen Link wie ein normaler Browser verhält ("Typ": "$ default")

Auf der rechten Seite sehen wir, dass das Klicken auf einen Link einen nativen Übergang zu einer anderen JASON-Ansicht bewirkt.

All dies kann erreicht werden, indem selektiv verschiedene Aktionen basierend auf $ jason.url ausgelöst werden.

Schritt 1. Fügen Sie dem Webcontainer eine Aktion mit dem Namen visit hinzu:

{... "body": {"background": {"type": "html", "url": "https://news.ycombinator.com", "action": {"trigger": "visit" }}}}

Schritt 2. Führen Sie relevante Aktionen innerhalb von visit aus, basierend auf $ jason.url

Im folgenden Code prüfen wir, ob $ jason.url mit den neuesten, angezeigten, fragenden usw. übereinstimmt (dies sind die Top-Menüelement-Links). In diesem Fall lassen wir den Webcontainer sich wie einen normalen Browser verhalten, indem wir "type": "$ default" setzen.

Wenn sie nicht mit dem Muster übereinstimmen, führen wir einen nativen $ href-Übergang zu einer neuen Ansicht durch und übergeben den angeklickten Link als Parameter.

... "Aktionen": {"Besuch": [{"{{#if /\\/(newest|show|ask)$/.test($jason.url)}}": {"Typ": " $ default "}}, {" {{#else}} ": {" type ":" $ href "," options ": {" url ":" https://jasonette.github.io/Jasonpedia/webcontainer/ agent / hijack.json "," pretoad ": {" background ":" #ffffff "}," options ": {" url ":" {{$ jason.url}} "}}}}},

Schauen Sie sich hier das vollständige JSON-Markup für den Webbrowser an (es sind nur 48 Zeilen!).

Sofortige "Hybrid" App

Wenn Leute normalerweise von „hybriden“ Apps sprechen, meinen sie meistens HTML-Web-Apps, die in einen nativen App-Frame eingeschlossen sind.

Aber das meine ich hier nicht. Wenn ich "Hybrid" sage, meine ich eine wirklich hybride App, bei der eine App mehrere native Ansichten und mehrere webbasierte Ansichten gleichzeitig haben kann. Außerdem kann eine Ansicht mehrere native UI-Komponenten und einen Webcontainer enthalten, die im selben nativen Layout gerendert werden.

Die Überkreuzung zwischen webbasierter Ansicht und nativer Ansicht sollte so nahtlos sein, dass es schwer zu sagen ist, wo man beginnt und endet.

In diesem Beispiel habe ich eine App erstellt, die jasonbase.com in einem Webcontainer als Startansicht anzeigt.

Jasonbase ist ein kostenloser JSON-Hosting-Service, den ich entwickelt habe, um JSON-Markups für Jasonette-Apps einfach zu hosten.

Natürlich ist es nur eine Website, aber ich habe sie in Jasonette eingebettet, sodass beim Klicken auf den Link anstelle des Öffnens einer Webseite ein nativer $ href-Übergang zu einer nativen JASON-Ansicht erfolgt.

Ich musste keinen Code von Jasonbase.com berühren, um diese App zu erstellen.

Ich habe die Website einfach als Webcontainer in Jasonette eingebettet und die Link-Klicks entführt, um sie nativ zu verarbeiten, sodass alle nativen Aufgaben wie das Auslösen nativer APIs und das Vornehmen nativer Übergänge ausgeführt werden können.

Sie können den Code hier überprüfen.

Fazit

Meiner Meinung nach macht all diese Arbeit fabelhaft aus, dass alles auf der Rahmenebene erledigt wird. Die ganze harte Arbeit wird hinter den Kulissen erledigt.

Anstatt die App-Entwickler zu belasten, alle folgenden Aufgaben von Grund auf neu zu implementieren:

  • Betten Sie eine Webansicht in das native Layout ein
  • Erstellen Sie eine JavaScript-Brücke, damit die App Funktionsaufrufe in die Webansicht ausführen kann
  • Erstellen einer nativen Ereignisbehandlungsarchitektur, damit die Webansicht native Ereignisse in der übergeordneten App auslösen kann

Die Lösung bestand darin, eine Abstraktion zu erstellen, die Folgendes umfasst:

  1. Deklarative Markup-Sprache: Beschreibt, wie eine Webansicht in eine native App eingebettet wird
  2. Kommunikationsprotokoll (JSON-RPC): Ermöglicht kinderleichte Interaktionen zwischen der App und ihren untergeordneten Webansichten.

Ich behaupte nicht, dass dieser Ansatz die ultimative Lösung ist, um alles zu lösen, aber ich bin froh zu sagen, dass dies eine großartige Lösung für meinen eigenen Anwendungsfall war.

Ich habe versucht, eine App zu erstellen, die auf einer Super-Edge-Technologie aufbaut, die keine stabilen und zuverlässigen mobilen Implementierungen aufweist (und es ist nicht klar, ob es aufgrund der Art des Protokolls jemals eine mobile Implementierung geben wird). Zum Glück hatte es JavaScript-Implementierungen, so dass ich es problemlos in die App integrieren konnte.

Insgesamt war es großartig und ich bin zufrieden mit dem Ergebnis. Die Dokumentation ist auf dem neuesten Stand, um alle neuen Funktionen widerzuspiegeln. Sie können sich also gerne umsehen und herumspielen.

Haftungsausschluss: Mit großer Kraft geht große Verantwortung einher

Ich möchte mit einem Haftungsausschluss enden: So groß diese neu gewonnene Leistung auch ist, ich denke, Sie müssen ein Gleichgewicht halten, um eine App mit einer großartigen Benutzererfahrung zu erstellen.

Einige nehmen dies und erstellen eine gesamte App nur mit Webansichten, aber dann erhalten Sie eine App, die im Grunde nur eine Website ist, die den Zweck des Erstellens einer dedizierten App zunichte macht.

Ich betone, dass ich nicht sage, dass Sie Apps immer sowohl mit HTML als auch mit Native erstellen sollten. Ich sage, dass dies für viele Menschen in verschiedenen Situationen sehr nützlich sein kann. Gehen Sie einfach nicht über Bord.

Folgen Sie uns, um mehr zu erfahren

Es gibt viele verschiedene Konfigurationen, in denen der native Kern von Jasonette und sein untergeordneter Webcontainer kommunizieren können, um Dinge auf kreative und leistungsstarke Weise zu erledigen, und dieser Beitrag kratzt nur an der Oberfläche.

In Zukunft plane ich, weitere dieser Anwendungsfälle und Tutorials zu veröffentlichen. Wenn Sie also interessiert sind, folgen Sie uns bitte auf Medium oder Twitter.