把轉變為json_如何使用7行JSON將您的網站轉變為移動應用程序

把轉變為json

by Ethan

通過伊桑

將Web引擎融合到本機應用程序的新方法 (A New Approach for Blending Web Engine into Native Apps)

What if I told you the 7 lines of JSON above, colored in orange is all you need to turn a website into a mobile app? No need to rewrite your website using some framework API just to make it behave like a mobile app. Just bring your existing website as is, and blend it into a native app with a simple URL reference.

如果我告訴您上述JSON的7行(用橙色涂成橙色 )，將網站變成移動應用程序只需要什么？無需使用某些框架API來重寫您的網站，僅使它的行為類似于移動應用即可。只需將您現有的網站保持原樣，然后使用簡單的URL引用將其混合到本機應用程序中即可。

And what if, just by tweaking the JSON markup a bit, you can access all the native APIs, native UI components, as well as native view transitions out of the box?

而且，如果僅通過稍微調整JSON標記就可以直接使用所有本機API，本機UI組件以及本機視圖轉換，該怎么辦？

Here’s what a minimal example looks like in action:

這是一個實際的最小示例：

Notice how I’ve embedded a github.com web page but the rest of the layout is all native UI components, such as the navigation header and the bottom tab bar. And the transition is automatically native without you having to rewrite the website using any APIs.

請注意，我是如何嵌入github.com網頁的，但是其余的布局都是本機UI組件，例如導航標題和底部的標簽欄。并且過渡是自動的本機，而無需使用任何API重寫網站。

Before I explain how, you may ask: “That’s cool, but can you do anything meaningful other than just displaying the web page in a native app frame?”

在我解釋如何做之前，您可能會問：“這很酷，但是除了將網頁顯示在本機應用程序框架中之外，您還能做其他有意義的事情嗎？”

Great question, because that’s the main topic of this post. All you need to do is create a seamless 2-way communication channel between the web view and the app, so the parent app can trigger any JavaScript functions inside the web view and the web view can reach outside to call native APIs.

很好的問題，因為這是本文的主題。您需要做的就是在Web視圖和應用之間創建無縫的雙向通訊渠道 ，以便父應用可以觸發Web視圖內部的任何JavaScript函數，并且Web視圖可以到達外部以調用本地API。

Here’s one such example:

這是一個這樣的例子：

Note that this view contains:

請注意，此視圖包含：

Native navigation header, complete with built-in transition functionality
本機導航標題，具有內置的轉換功能
A Web view, which embeds a QR code generator web app
Web視圖，其中嵌入了QR碼生成器Web應用程序
A native chat input component at the bottom
底部的本地聊天輸入組件

All this can be described by just tweaking some of the JSON markup attributes we saw above.

所有這些都可以通過調整一些我們在上面看到的JSON標記屬性來描述。

Finally, note that the QR code changes as you enter something from the chat input. The chat input triggers a JavaScript function inside the QR code web app that re-generates the image.

最后，請注意，當您從聊天輸入中輸入內容時，QR碼會更改。聊天輸入觸發QR代碼Web應用程序內JavaScript函數，該函數重新生成圖像。

No app development framework has tried to fundamentally solve this problem of “seamless integration of web view into native apps” because they’re all focused on picking either 100% native or 100% HTML5 side.

沒有應用程序開發框架試圖從根本上解決“將Web視圖無縫集成到本機應用程序”這一問題，因為它們都集中在選擇100％本機或100％HTML5方面。

Whenever you hear someone talk about the future of mobile apps, you would probably hear them talk about “Will it be the HTML5 approach that wins out? Or will it be native?”

每當您聽到有人談論移動應用程序的未來時，您可能就會聽到他們談論“將是HTML5的方法勝出嗎？ 還是本地的？”

None of them see native and html as something that could co-exist and furthermore, create synergy and achieve things that are not easily possible otherwise.

他們都沒有將native和html視為可以共存的東西，此外，它們還可以產生協同作用，并實現原本不容易實現的事情。

In this article I’m going to explain:

在本文中，我將解釋：

Why blending web engine and native components is often a good idea.
為什么混合Web引擎和本機組件通常是一個好主意。
Why a seamless integration of HTML and Native is not easy, and how I implemented one.
為什么不容易將HTML和Native進行無縫集成，以及我是如何實現的。
Most importantly, how YOU can use it to build your own app instantly.
最重要的是，如何使用它立即構建自己的應用程序。

為什么要在本機應用程序中使用HTML？ (Why would you use HTML in a native app?)

Before we go further, let’s first discuss whether this is even a good idea, and when you may want to take this approach. Here are some potential use cases:

在繼續之前，我們先討論一下這是否是個好主意，以及何時使用此方法。以下是一些潛在的用例：

1.使用Web本機功能 (1. Use Web Native Features)

Some parts of your app may be better implemented using the web engine. For example, Websocket is a web-native feature that’s designed for the web environment. In this case it makes sense to use the built-in web engine (WKWebView for iOS and WebView for Android) instead of installing a 3rd party library that essentially “emulates” Websocket.

使用網絡引擎可能會更好地實現您應用的某些部分。例如， Websocket是針對Web環境設計的Web原生功能。在這種情況下，使用內置的Web引擎( 適用于iOS的WKWebView和適用于Android的WebView )是有意義的，而不是安裝本質上“模仿” Websocket的第三方庫。

No need to install additional code just to do something that you can do for free, which brings us to the next point.

無需安裝其他代碼即可完成您可以免費做的事情，這將使我們進入下一步。

2.避免大二進制文件 (2. Avoid Large Binary Size)

You may want to quickly incorporate features that will otherwise require a huge 3rd party library.

您可能需要快速合并一些功能，否則這些功能將需要龐大的第三方庫。

For example, to incorporate a QR code image generator natively, you will need to install some 3rd party library which will increase the binary size. But if you use the web view engine and a JavaScript library through a simple <script src>, you get all that for free, and you don’t need to install any 3rd party native libraries.

例如，要在本地合并QR碼圖像生成器，您將需要安裝一些第三方庫，這會增加二進制文件的大小。但是，如果您通過簡單的<script s rc>使用Web視圖引擎和JavaScript庫，則可以免費獲得所有內容，而無需安裝任何第三方的本機庫。

3.不存在可靠的移動圖書館 (3. No Reliable Mobile Library Exists)

For some cutting edge technologies, there is no reliable and stable mobile implementation yet.

對于某些尖端技術，尚沒有可靠且穩定的移動實現。

Fortunately most of these technologies have web implementations, so the most efficient way to integrate them is to use their JavaScript library.

幸運的是，這些技術中的大多數都具有Web實現，因此集成它們的最有效方法是使用其JavaScript庫。

4.構建部分本地的，基于網絡的應用 (4. Build part-native, part-web-based apps)

Many new developers looking to port their website into a mobile app get discouraged or overwhelmed when they find out some of their existing website features are too complex to quickly rewrite from scratch for each mobile platform.

當許多新的開發人員發現自己現有的某些網站功能過于復雜而無法為每個移動平臺快速從頭開始重寫時，他們會灰心或不知所措。

For example, you may have a single web page that’s too complex to immediately convert to a mobile app, but the rest of your website may be easily converted.

例如，您可能只有一個網頁太復雜而無法立即轉換為移動應用程序，但是您網站的其余部分可能很容易轉換。

In this case, it would be nice if there was a way to build most of the app natively, but for that particular complex web page, somehow seamlessly integrate it into the app as HTML.

在這種情況下，如果有一種方法可以原生構建大部分應用程序，那將是很好的選擇，但是對于該特定的復雜網頁，以某種方式將其作為HTML無縫集成到應用程序中。

它是如何工作的？ (How does it work?)

賈森內特 (A. Jasonette)

Jasonette is an open source, markup-based approach to building cross-platform native apps.

Jasonette是一種基于標記的開源方法，用于構建跨平臺的本機應用程序。

It’s like a web browser, but instead of interpreting HTML markup into web pages, it interprets JSON markup into native apps on iOS and Android.

它就像一個網絡瀏覽器，但是沒有將HTML標記解釋為網頁，而是將JSON標記解釋為iOS和Android上的本機應用程序。

Just like how all web browsers have exactly the same code but can deliver you all kinds of different web apps by interpreting various HTML markup on demand, all Jasonette apps have exactly the same binary, and it interprets various JSON markup on demand to create your app. The developers never need to touch the code. Instead, you build apps by writing a markup that translates to native app in real-time.

就像所有網絡瀏覽器具有完全相同的代碼，但是可以通過按需解釋各種HTML標記為您提供各種不同的Web應用程序一樣，所有Jasonette應用程序都具有完全相同的二進制文件，并且可以按需解釋各種JSON標記來創建您的應用程序。開發人員無需觸摸代碼。相反，您可以通過編寫可實時轉換為本地應用程序的標記來構建應用程序。

You can learn more about Jasonette here.

您可以在此處了解有關Jasonette的更多信息。

While Jasonette at its core is all about building native apps, this particular article is about integrating HTML into the core native engine, so let’s talk about that.

Jasonette的核心是構建本機應用程序，而這篇特別文章是關于將HTML集成到核心本機引擎中的，所以讓我們來談談。

B. Jasonette Web容器 (B. Jasonette Web Container)

Native apps are great but sometimes we need to make use of web features.

本機應用程序很棒，但有時我們需要利用網絡功能。

But integrating web views into a native app is a tricky business. A seamless integration requires:

但是將Web視圖集成到本地應用程序中是一項棘手的工作。無縫集成需要：

Web view should be integrated as a part of native layout: The web view should blend into the app as a part of the native layout and is treated just like any other native UI components. Otherwise it will feel clunky, and it will feel exactly like what it is — a website.
Web視圖應作為本機布局的一部分集成： Web視圖應作為本機布局的一部分融合到應用程序中，并且與其他任何本機UI組件一樣被對待。否則，它將感覺笨拙，并且會感覺完全像是一個網站。
Parent app can control child web container: The parent app should be able to freely control the child web view.
父級應用程序可以控制子級Web容器：父級應用程序應能夠自由控制子級Web視圖。
Child web container can trigger native events on the parent app: The child app should be able to trigger the parent app’s events to run native APIs.
子Web容器可以觸發父應用程序上的本機事件：子應用程序應能夠觸發父應用程序的事件以運行本機API。

These are a lot of work, so I first worked on only the first piece of the puzzle — simply embedding a web container into native layout — and released it as version 1:

這些工作量很大，因此我首先僅解決難題的第一部分- 只需將Web容器嵌入本機布局中 ，然后將其發布為版本1：

JSON Web ContainerHTML inside JSON Turns into Native App Componentsjasonette.com

JSON中的JSON Web容器 HTML變成了本機應用程序組件 jasonette.com

This was already pretty useful, but it still had the limitation of being non-interactive.

這已經非常有用，但是仍然存在非交互式的局限性。

The parent app couldn’t control the child web container, and the child couldn’t notify the parent of any event, keeping the web container completely isolated from the outside world.

父級應用程序無法控制子級Web容器，子級也無法將任何事件通知父級，從而使Web容器與外界完全隔離。

C. Jasonette Web容器2.0：使其具有交互性 (C. Jasonette Web Container 2.0: Make it Interactive)

After releasing version 1, I experimented with the second piece of the puzzle — adding interactivity to the web container.

發布版本1后，我嘗試了第二個難題– 為Web容器增加了交互性。

The next section explains the solutions that were added to make the previously-static web containers interactive, making them significantly more powerful.

下一節將說明為使以前靜態的Web容器具有交互性而添加的解決方案，從而使它們明顯更強大。

實施：交互式Web容器 (Implementation: Interactive Web Container)

1.通過URL加載 (1. Load by URL)

問題 (Problem)

Previously in version 1, to use web container as a background view component, you had to first set the $jason.body.background.type to "html" and then hard-code the HTML text under $jason.body.background.text attribute like this:

在以前的版本1中，要將Web容器用作背景視圖組件，必須首先將$jason.body.background.type設置為"html" ，然后將HTML文本硬編碼在$jason.body.background.text像這樣的屬性：

{  "$jason": {    "head": {      ...    },    "body": {      "background": {        "type": "html",        "text": "<html><body><h1>Hello World</h1></body></html>"      }    }  }}

Naturally people wanted to be able to instantiate the container using simply a web URL instead of having to hardcode the entire HTML text in a single line.

自然，人們希望能夠僅使用Web URL實例化容器，而不必在一行中對整個HTML文本進行硬編碼。

解 (Solution)

Web container 2.0 has added the url attribute. You can embed a local file:// HTML like this (it loads from the local HTML file you ship with the app):

Web容器2.0已添加url屬性。您可以像這樣嵌入本地file:// HTML(它會從與應用一起提供的本地HTML文件中加載)：

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

Or embed a remote http[s]:// URL like this (it loads from a remote HTML):

或嵌入這樣的遠程http[s]:// URL(從遠程HTML加載)：

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

2.父應用程序<=> Web容器通信 (2. Parent App <=> Web Container Communication)

問題 (Problem)

Previously, web containers were only for displaying content, and not interactive. This meant NONE of the following was possible:

以前，Web容器僅用于顯示內容，而不用于交互。這意味著不可能執行以下操作：

Jasonette => Web Container: Call JavaScript functions inside the web container from Jasonette.
Jasonette => Web Container ：從Jasonette調用Web容器內JavaScript函數。
Web Container => Jasonette: Call native API from web container code.
Web容器=> Jasonet te：從Web容器代碼中調用本地API。

All you could do was display the web container. This was similar to how you would embed an iframe in a web page, but the main web page had no access to what was inside the iframe.

您所能做的就是顯示Web容器。這類似于將iframe嵌入網頁中的方式，但是主網頁無法訪問iframe內部的內容。

解 (Solution)

The whole point of Jasonette is to design a standard markup language to describe cross platform mobile apps. In this case, we needed a markup language that could comprehensively describe communications between the parent app and the child web container.

Jasonette的全部重點是設計一種標準的標記語言來描述跨平臺的移動應用程序。在這種情況下，我們需要一種可以全面描述父應用程序和子Web容器之間的通信的標記語言。

To achieve this, I came up with a JSON-RPC based communication channel between the parent app and the child web container. Since everything on Jasonette is expressed in JSON objects, it made perfect sense to use the JSON-RPC standard format as the communication protocol.

為此，我想出了父應用程序和子Web容器之間基于JSON-RPC的通信通道。由于Jasonette上的所有內容都以JSON對象表示，因此使用JSON-RPC標準格式作為通信協議是很有意義的。

To make a JavaScript function call into the web container, we declare an action called $agent.request:

為了對Web容器進行JavaScript函數調用，我們聲明了一個名為$agent.request ：

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

$agent.request is the native API that triggers a JSON-RPC request into the web container. To use it, we must pass an options object as its parameter.

$agent.request是本機API，可觸發JSON-RPC請求進入Web容器。要使用它，我們必須傳遞一個options對象作為它的參數。

The options object is the actual JSON-RPC request that will be sent to the web container. Let’s look at what each attribute means:

options對象是將發送到Web容器的實際JSON-RPC請求。讓我們看一下每個屬性的含義：

id: Web container is built on top of a lower level architecture called agent. Normally you can have multiple agents for a single view, and each agent can have its unique ID. But Web container is a special type of agent which can only have the id of $webcontainer, which is why we use that ID here.
id ：Web容器建立在稱為agent的較低級架構之上。通常，一個視圖可以有多個代理，每個代理可以有其唯一的ID。但是Web容器是一種特殊類型的代理，只能具有$webcontainer的ID ，這就是我們在此處使用該ID的原因。
method: The JavaScript function name to call
method ：要調用JavaScript函數名稱
params: The array of parameters to pass to the JavaScript function.
params ：傳遞給JavaScript函數的參數數組。

The full markup would look something like this:

完整的標記如下所示：

{  "$jason": {    "head": {      "actions": {        "$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"      }    }  }}

This markup is saying:

這個標記說：

When the view loads ($jason.head.actions.$load), make a JSON-RPC request into the web container agent ($agent.request) where the request is specified under options.

當視圖加載( $jason.head.actions.$load )時，向Web容器代理( $agent.request )發出JSON-RPC請求，該請求在options下指定。

The web container is defined under $jason.body.background, which in this case loads a local file called file://index.html.

Web容器在$jason.body.background下定義，在這種情況下，該容器將加載名為file://index.html的本地文件。

It will look for a JavaScript function called login and pass the two arguments under params ( "alice" and "1234")

它將尋找一個名為loginJavaScript函數，并在params下傳遞兩個參數( "alice"和"1234" )

login("alice", "1234")

I’ve only explained how the parent app can trigger the child web container’s JavaScript function calls, but you can also do the opposite and let the web container trigger the parent app’s native API.

我僅說明了父應用程序如何觸發子Web容器JavaScript函數調用，但是您也可以執行相反的操作，并讓Web容器觸發父應用程序的本機API 。

To learn more, check out the agent documentation.

要了解更多信息，請查看代理文檔。

例 (Example)

Let’s come back to the QR code example I briefly shared above:

回到上面我簡短分享的QR代碼示例：

The footer input component is 100% native.
頁腳輸入組件是100％native 。
The QR code is generated by the web container as a web app.
QR代碼是由Web容器作為Web應用程序生成的。
When a user enters something and presses “Generate,” it calls $agent.request action into the web container agent, calling the JavaScript function “qr”
當用戶輸入內容并按“ Generate”時，它將在Web容器代理中調用$agent.request操作，并在JavaScript函數中調用“ qr”

You can check out the example here.

您可以在此處查看示例。

3.腳本注入 (3. Script Injection)

問題 (Problem)

Sometimes you may want to dynamically inject JavaScript code into the web container AFTER it’s finished loading the initial HTML.

有時，您可能希望在JavaScript代碼完成加載初始HTML之后將其動態注入Web容器中。

Imagine you want to build a custom web browser app. You may want to inject your own custom JavaScript into every web view to customize the web view’s behavior, kind of like how web browser extensions work.

假設您要構建一個自定義Web瀏覽器應用程序。您可能希望將自己的自定義JavaScript注入每個Web視圖中，以自定義Web視圖的行為，就像Web瀏覽器擴展的工作方式一樣。

Even if you’re not building a web browser, you may want to use the script injection method whenever you want a custom behavior for a URL whose content you have no control over. The only way to communicate between the native app and the web container is through the $agent API. But if you can’t change the HTML content, the only way to add the $agent interface into the web container is through dynamic injection.

即使您不構建Web瀏覽器，也可能希望在您希望對其內容無法控制的URL進行自定義行為時使用腳本注入方法。在本機應用程序和Web容器之間進行通信的唯一方法是通過$agent API。但是，如果您無法更改HTML內容，則將$agent接口添加到Web容器的唯一方法是通過動態注入。

解 (Solution)

As mentioned in the previous section, the $jason.body.background web container is just another agent. This means you can use the same $agent.inject method available to regular agents.

如上一節所述， $jason.body.background Web容器只是另一個agent 。這意味著您可以使用常規代理可用的相同$agent.inject方法。

4. URL單擊處理 (4. URL Click Handling)

In the past, there were only two ways a web container could handle link clicks:

過去，Web容器只能通過兩種方式處理鏈接點擊：

Readonly: Treat the web container as readonly and ignore all events such as touch or scroll. All web containers are readonly unless you tell them to behave like a regular browser, as described below.
只讀：將Web容器視為只讀，并忽略所有事件，例如觸摸或滾動。所有Web容器都是只讀的，除非您告訴它們像常規瀏覽器一樣運行，如下所述。
Regular Browser Behavior: Let users interact with the page by behaving like a normal browser. You declare it by setting "type": "$default" as its action attribute.
常規的瀏覽器行為：讓用戶可以像普通瀏覽器一樣與頁面進行交互。您可以通過將"type": "$default"為其action屬性來聲明它。

問題 (Problem)

Both are “all or nothing” solutions.

兩者都是“全有或全無”的解決方案 。

In the “Readonly” case, all your interactions are completely ignored by the web container.
在“只讀”情況下，Web容器將完全忽略您的所有交互。
In the “Regular Browser Behavior” case, the web container functions literally as a browser. When you click a link, it would just send you to that link by refreshing the page just like a web page. There was no way to hijack the click and call some native API.
在“常規瀏覽器行為”的情況下，Web容器實際上是充當瀏覽器。當您單擊鏈接時，它將像刷新網頁一樣通過刷新頁面將您發送到該鏈接。無法劫持點擊并調用某些本機API。

解 (Solution)

With the new web container, you can now attach any action on the $jason.body.background web container to handle link click events.

使用新的Web容器，您現在可以在$jason.body.background Web容器上附加任何action來處理鏈接單擊事件。

Let’s look at an example:

讓我們看一個例子：

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

Here we have attached "trigger": "displayBanner" to the web container. This means that when a user clicks any link in the web container, it will trigger displayBanner action instead of letting the web view handle it.

在這里，我們將"trigger": "displayBanner"附加到Web容器。這意味著，當用戶單擊Web容器中的任何鏈接時，它將觸發displayBanner操作，而不是讓Web視圖處理它。

Also, if you look at the displayBanner action, you’ll notice the $jason variable. In this case, the clicked link will be passed through the $jason variable. For example, if you clicked a URL named "https://google.com", the $jason will have the following value:

另外，如果查看displayBanner動作，您會注意到$jason變量。在這種情況下，單擊的鏈接將通過$jason變量傳遞。例如，如果您單擊名為"https://google.com"的URL，則$jason將具有以下值：

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

This means you can selectively trigger different actions by checking the $jason.url value.

這意味著您可以通過檢查$jason.url值來有選擇地觸發不同的操作。

Let’s take another example where we implement a custom web browser:

讓我們再來看一個實現自定義Web瀏覽器的示例：

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

We test if the URL contains the string signin and then run two different actions depending on the result.

我們測試URL是否包含字符串signin ，然后根據結果運行兩個不同的操作。

If it contains signin, it opens a new view to take care of signing in natively.
如果包含signin ，它將打開一個新視圖以照顧本地登錄。
If it doesn’t contain signin, just run the "type": "$default" action so that it behaves like a regular browser.
如果它不包含signin ，只需運行"type": "$default"操作，使其表現得像普通瀏覽器。

用法示例 (Example Usage)

構建自定義的Web瀏覽器 (Building a custom web browser)

We can now take advantage of the fact that the new web container can:

現在，我們可以利用新的Web容器可以做到這一點：

Take a url attribute to load itself, functioning as a full-fledged browser
使用url屬性來加載自身，作為成熟的瀏覽器
Selectively handle link clicks depending on the URL
根據URL選擇性處理鏈接點擊

We can even build a custom web browser app with just a dozen lines of JSON. Since we can now hijack every link click, we can take a look at $jason.url and run whatever actions we want depending on the URL.

我們甚至可以只用十幾行JSON構建自定義的Web瀏覽器應用程序。由于我們現在可以劫持每個鏈接單擊，因此我們可以查看$jason.url并根據URL進行所需的任何操作。

For example, take a look at the example below:

例如，看下面的例子：

On the left side we see that clicking a link behaves like a regular browser ("type": "$default")

在左側，我們看到單擊鏈接的行為類似于常規瀏覽器( "type": "$default" )

On the right side we see that clicking a link does a native transition to another JASON view.

在右側，我們看到單擊鏈接會進行本機轉換到另一個JASON視圖。

All this can be achieved by selectively triggering different actions based on $jason.url.

所有這些都可以通過基于$jason.url選擇性地觸發不同的動作來實現。

Step 1. Attach an action named visit to the web container like this:

步驟1.將名為visit的操作附加到Web容器，如下所示：

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

Step 2. Run relevant actions inside visit, based on $jason.url

步驟2.根據$jason.url在visit,運行相關操作

In the following code, we’re checking if $jason.url matches newest, show, ask, and so on (they’re the top menu item links). If they do, we let the web container behave like a regular browser by setting "type": "$default"

在下面的代碼中，我們正在檢查$jason.url匹配newest ， show ， ask等(它們是頂部菜單項的鏈接)。如果這樣做，我們可以通過設置"type": "$default"使Web容器像常規瀏覽器一樣工作

If they don’t match the pattern, we make a native $href transition to a new view and pass the clicked link as a parameter.

如果它們與模式不匹配，我們將執行本機$href過渡到新視圖，然后將單擊的鏈接作為參數傳遞。

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

Check out the full JSON markup for the web browser here (it’s only 48 lines!).

在此處查看 Web瀏覽器的完整JSON標記(只有48行！)。

即時的“混合”應用 (Instant “Hybrid” App)

When people normally talk about “hybrid” apps, they mostly mean HTML web apps wrapped inside a native app frame.

人們通常談論“混合”應用程序時，通常指的是將HTML Web應用程序包裝在本機應用程序框架中。

But that’s not what I mean here. When I say “Hybrid,” I mean a truly hybrid app, where one app can have multiple native views and multiple web-based views simultaneously. Also where one view can have multiple native UI components and a web container rendered in the same native layout.

但這不是我的意思。當我說“ Hybrid”時，是指真正的混合應用程序，其中一個應用程序可以同時具有多個本機視圖和多個基于Web的視圖。同樣，一個視圖可以具有以相同的本機布局呈現的多個本機UI組件和一個Web容器。

The cross-over between web-based view and native view should be so seamless that it’s hard to tell where one starts and ends.

基于Web的視圖和本機視圖之間的交叉應該是如此無縫，以至于很難說出起點和終點。

In this example, I’ve created an app that displays jasonbase.com in a web container as the home view.

在此示例中，我創建了一個應用程序，該應用程序將Web容器中的jasonbase.com顯示為主視圖。

Jasonbase is a free JSON hosting service I built to easily host JSON markup for Jasonette apps.

Jasonbase是免費的JSON托管服務，我構建該服務是為了輕松托管Jasonette應用程序的JSON標記。

Naturally, it’s just a website, but I have embedded it in Jasonette so that when you click the link, instead of opening a web page, it makes a native $href transition to a native JASON view.

自然地，這只是一個網站，但我已將其嵌入Jasonette中，因此，當您單擊鏈接時，無需打開網頁，而是將本機$href轉換為本機JASON視圖。

I didn’t have to touch any of Jasonbase.com’s code to build this app.

我無需觸摸Jasonbase.com的任何代碼即可構建此應用。

I simply embedded the website into Jasonette as a web container, and hijacked the link clicks to handle them natively, so it can do all the native stuff like triggering native APIs and making native transitions.

我只是將網站作為Web容器嵌入Jasonette中，并劫持了鏈接點擊以本地處理它們，因此它可以執行所有本地工作，例如觸發本地API和進行本地轉換。

You can check out the code here.

您可以在此處簽出代碼。

結論 (Conclusion)

In my opinion, what makes all this work fabulously is that everything is taken care of on the framework level. All the hard work is taken care of behind the scenes.

我認為，使所有這些工作變得如此出色的原因是， 所有事情都在框架級別得到了照顧 。所有的辛苦工作都在后臺進行。

Instead of putting the burden on the app developers to implement all of the following from scratch:

不必為應用程序開發人員負擔從頭開始實現以下所有任務的負擔：

Embed a webview into native layout
將Webview嵌入本機布局
Create a JavaScript bridge so the app can make function calls into the web view
創建一個JavaScript橋，以便該應用可以對Web視圖進行函數調用
Creating a native event handling architecture so the web view can trigger native events on the parent app
創建本機事件處理架構，以便Web視圖可以在父應用程序上觸發本機事件

The solution was to create an abstraction made up of:

解決方案是創建一個包含以下內容的抽象：

Declarative Markup Language: for describing how to embed a web view into a native app
聲明性標記語言：用于描述如何將Web視圖嵌入到本機應用程序中
Communication Protocol (JSON-RPC): to allow dead-simple interactions between the app and its child web views.
通信協議(JSON-RPC)：允許應用與其子Web視圖之間進行簡單的交互。

I don’t claim this approach to be the ultimate solution to solve everything, but I’m happy to say that this has been a great solution for my own use case.

我并不是說這種方法是解決所有問題的最終解決方案，但是我很高興地說這對于我自己的用例來說是一個很好的解決方案。

I was trying to build an app that builds on a super edge technology which has no stable and reliable mobile implementations (and it’s not clear if there ever will be a mobile implementation due to the protocol’s nature). Thankfully it had JavaScript implementations so I could easily integrate it into the app without hassle.

我試圖構建一個基于超級邊緣技術的應用程序，該技術沒有穩定可靠的移動實現(由于協議的性質，目前尚不清楚是否會有移動實現)。幸運的是，它具有JavaScript實現，因此我可以輕松地將其集成到應用程序中。

Overall, it’s been great and I’m satisfied with how it turned out. The documentation is up to date to reflect all the new features, so feel free to dig in and play around.

總的來說，這很棒，我對結果感到滿意。該文檔是最新的，可以反映所有新功能，因此可以隨時進行探索和探索。

Disclaimer: With great power comes great responsibility

免責聲明：強大的力量伴隨著巨大的責任

I would like to end with a disclaimer: as great as this newly found power is, I think you need to keep a balance to build an app with a great user experience.

我想以免責聲明結尾：盡管有這種新發現的強大功能，但我認為您需要保持平衡以構建具有出色用戶體驗的應用程序。

Some may take this and build an entire app using web views only, but then you will end up with an app that’s basically just a website, which defeats the purpose of building a dedicated app.

有些人可能會這樣做并且僅使用網絡視圖來構建整個應用程序，但是最終您將得到一個基本上只是一個網站的應用程序，這違背了構建專用應用程序的目的。

I emphasize that I’m not saying you should always build apps with both HTML and native. I am saying this can be very useful for many people in different situations. Just don’t go overboard with it.

我要強調的是，我并不是說您應該始終使用HTML和本機構建應用程序。我是說這對處于不同情況下的許多人非常有用。只是不要太過分。

Follow Along to Learn More

跟隨以了解更多

There are many different configurations in which the Jasonette native core and its child web container can communicate to get things done in creative and powerful ways, and this post is just scratching the surface.

Jasonette本機核心和它的子Web容器可以通過多種不同的配置進行通信，從而以富有創意和強大的方式完成工作，而本文只是從頭開始。

Going forward I’m planning to share more of these use cases and tutorials, so if you’re interested, please follow along on medium or twitter.

展望未來，我打算分享更多這些用例和教程，因此，如果您有興趣，請繼續使用medium或twitter 。