JSON realizes seven lines of code to turn the website into a mobile application

This article introduces how to use Jasonette to integrate web views and native components to build a true "hybrid" application, turning your website into a mobile application. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

If I told you that you only need the above 7 lines of orange JSON code to turn a website into a mobile application, would you believe it? There is absolutely no need to rewrite the website using some framework API to get the same behavior as a mobile app. If you already have an existing website, you can "package" it as a native app by simply referencing the URL.

On this basis, you only need to slightly adjust the JSON code content, and you can directly access all native APIs, native UI components, and native view transitions (View Transition).

The most simplified example effect is shown below:

As you can see from this, I have embedded a GitHub.com Web page, but the rest of the layout on the interface are native UI components, such as the navigation bar and the tab bar at the bottom. And we don't need to use any API to rewrite the website, we can automatically get the native switching effect.

Before introducing the specific method, you may ask: "It looks cool, but apart from displaying Web pages within the native application framework, what is the significance of this technology?

Ask Great! This is also the focus of this article. We only need to create a seamless two-way communication between the web view and the application, so that the parent application can trigger any JavaScript function within the web view, and then the web view can be accessed from the outside Call the native API.

For example:

Please note that this view contains:

• ##Native navigation bar, and built-in switching function

• A Web view, which embeds a Web application that can generate QR codes

• Include a native text input component at the bottom

All of the above can be achieved by slightly adjusting the properties of the JSON code.

Finally, please note that with Enter different content in the text input area, and the QR code will change accordingly. The entered text can trigger the JavaScript function inside the QR code generator web application to regenerate the QR code image.

There is currently no A development framework has tried to fundamentally solve the problem of "seamlessly integrating web views with native applications" because these frameworks have focused on a completely native, or completely HTML5 approach

Whenever we hear someone When discussing the future of mobile apps, you're likely to hear something like, "Will HTML5 or the native approach win out?" "Such a statement.

No one seems to think that native and html can coexist, and the collaboration and final realization of the two does not seem to be easy.

This article will introduce to you:

• Why the integration of web engines and native components is often a better approach.

• Why seamless integration of HTML and native is so Difficult, and how to implement it.

• More importantly, how to use such technology to quickly build your own applications.

##Why use HTML in native applications?Before going further, let’s first look at whether it is good or bad, and when it is appropriate to use this method. . Some potential use cases for this approach are as follows:

1. Using Web native functions

It may be more appropriate to use a Web engine to implement some of the content in the application. approach. For example, WebSocket is a native Web function and is mainly designed for the Web environment. In this case, it is more suitable to use the built-in Web engine (iOS's WKWebView and Android's WebView) instead of installing some A third-party library that "emulates" WebSocket.

Wouldn't it be better to use a free tool to achieve your goal without installing any additional code. This also leads to the next reason.

2. Avoid binary files that are too large in size

Some functions may require the help of huge third-party libraries, and you may want to use such functions quickly.

For example , in order to include the QR code image generator natively, you may need to install some third-party libraries, which will cause the binary file size to increase. But if you use the Web view engine and call the JavaScript library through a simple

3. Lack of reliable mobile libraries

For some cutting-edge technologies, it may not be available for the time being. There is no stable and reliable mobile terminal implementation.

Fortunately, most of these technologies have web implementations, so the most efficient integration method is to use JavaScript libraries.

4. Build a part-native, part-web-based application

Many novice developers want to port their websites into mobile applications, but find that they have It’s common to get frustrated or frustrated when parts of your website are too complex to quickly rewrite for each mobile platform.

For example you might have a very complex web page that cannot be quickly converted to a mobile app, but the rest of the site can be converted easily.

Faced with this situation, if most of the content of the application is built in a native way through some method, wouldn't it be very easy to directly integrate particularly complex pages into the application in the form of HTML? Great.

How is this achieved?

A. Jasonette

Jasonette is an open source method for building cross-platform native applications based on markup language.

The technology looks like a web browser, but instead of interpreting HTML markup language into web pages, it interprets JSON markup into native apps on iOS and Android.

Just as all web browsers have the exact same code, but provide users with all different types of web applications by interpreting different types of HTML tags as needed, all Jasonette applications have the exact same libraries , which can interpret different types of JSON tags as needed and create your application. Developers do not need to touch the code itself at all. They only need to write tags and "translate" the code into native applications in real time to develop their own applications.

Although the core role of Jasonette is to build native applications, the focus of this article is to introduce how to integrate HTML into the core native engine. Let’s take a look at it together.

B. Jasonette Web Container

Native applications are great, but sometimes we still need to use web functionality.

But the integration of web views and native applications is a troublesome process. Seamless integration requirements:

• Web views should be integrated as part of the native layout: Web views should be included in the app as part of the native layout and operate in the same way as other Any native UI components remain consistent. Otherwise it will feel clunky and make the user feel like they are actually visiting the website.

• Parent application can control the child web container: The parent application should be able to control the child web view at will.

• The child web container can trigger the parent application's native events: The child application should be able to trigger the parent application's events to run the native API.

This is a lot of work, so let’s start with the first step: embedding the web container directly into the native layout — and publishing it as version 1:

JSON Web container, HTML in JSON will become native application components.

This alone is very practical, but since it cannot interact, there are still certain limitations.

The parent application cannot control the child web container, and the child container cannot send any event notifications to the parent application, which results in the web container being completely isolated from the outside world.

C. Jasonette Web Container 2.0: Making it Interactive

After releasing version 1, we started working on the second problem: adding interactivity to the web container.

The following will introduce how to add interactive capabilities to the previously created static web container to make it more powerful.

Implementation: Interactive Web Container

1. Loading via URL

Question

Previously in version 1, in order to use the web container as the background view component, we first needed to set $jason.body.background.type to "html", and then in $jason.body Add hardcoded HTML text under the .background.text property, for example:

Generally speaking, people tend to prefer to use the Web URL directly to instantiate the container ization rather than having the entire HTML code hard-coded as a single line of code.

Solution

Web container 2.0 added the url attribute, we can embed local HTML in the form of file://, for example (can be published from the local accompanying application HTML file loading):

# Or you can embed the remote http[s]:// URL, for example like this (can load from remote HTML):

2. Two-way communication between parent application and web container

Problem

Before, Web containers can only be used to display content and cannot be interacted with. This means that all of the following are not possible:

• Communication from Jasonette to the web container: calling JavaScript functions inside the web container from Jasonette.

• Web container to Jasonette communication: calling native APIs from within the web container code.

At this time we can only display the content of the web container. This is like an iframe embedded in a web page, and the content in the iframe is completely inaccessible to the main page.

Solution:

Jasonette's biggest goal is to design a standardized markup language that can describe cross-platform mobile applications. Therefore we need a markup language that can comprehensively describe the two-way communication between the parent application and the child web container.

To do this I use a JSON-RPC based communication pipeline between the parent application and the child web container. Since everything in Jasonette is expressed through JSON objects, using the JSON-RPC standard format as the communication protocol becomes a very natural and reasonable way.

In order for JavaScript functions to call the Web container, an operation named $agent.request needs to be declared:

$agent.request is a native API that triggers JSON-RPC requests and sends them to the web container. In order to use the API, an options object must be passed as a parameter.

The options object is actually a JSON-RPC request sent to the web container. The meaning of each attribute is as follows:

• id: The Web container is built on an underlying architecture called Agent. Generally speaking, we can use multiple Agent, each Agent can have its own unique ID. But the web container is a special type of Agent and can only use $webcontainer as the ID, so the ID needs to be used here.

• method: The name of the JavaScript function to be called.

• params: Array of parameters passed to the JavaScript function.

So in full view, the tags used should be similar to this:

This string of tags is actually Saying:

When the view loads ($jason.head.actions.$load), send a JSON-RPC request ($agent.request) to the Web container Agent, and the specific request is specified through options of.

The Web container is defined under $jason.body.background. In this example, a local file named file://index.html will be loaded.

It will then find a JavaScript function named login and pass the two parameters under params ("alice" and "1234").

The above describes how the parent application triggers the JavaScript function call of the child Web container. We can also do the opposite and let the Web container trigger the native API of the parent application. .

Please refer to the Agent documentation for details.

Agent documentation: https://docs.jasonette.com/agents/

Example
Continue to return to the above introduction QR code generator example:

• The text input component at the bottom is 100% native.

• QR code is generated by a web container running as a web application.

• When the user enters content and presses "Generate", the $agent.request operation in the Web container Agent will be called, and then the JavaScript function "qr" will be called.

For specific examples, please refer to:
https://github.com/Jasonette/Jasonpedia/blob/gh-pages/webcontainer/agent/fn/index.json

3. Script injection

Problem

Sometimes we may need to complete the initial HTML loading in the Web container Finally, the JavaScript code is dynamically injected into the web container.

Suppose we want to build a custom web browser application, we may want to inject our own custom JavaScript into each web view to customize the behavior of the web view, which is somewhat similar to that of a web browser. Extension.

Even if you don’t need to build a web browser, you still need to use script injection when you want to implement custom behavior for URLs whose content is not controlled by us. Native applications and web containers can only communicate through the $agent API, but if the HTML content cannot be changed, the $agent interface can only be added to the web container through dynamic injection.

Solution

As mentioned above, the $jason.body.background web container is also an agent, which means we can use it exactly the same as a normal Agent The $agent.inject method.

4. Processing of URL clicks

In the past, the web container could only handle link click operations in two ways:

• Read-only: treat the web container as read-only, ignoring all such as touch or scroll events. At this time all web containers are read-only unless explicitly told to behave like a normal browser, as described below.

• Normal browser behavior: Like a normal browser, allowing the user to interact with the page. A declaration is required for this, setting "type": "$default" as the action attribute.

Problem

Both are “All or nothing” solutions.

• For "read-only", the web container ignores all user interactions.

• For "normal browser behavior", the web container will behave consistent with the browser. After clicking the link, the page will be refreshed to display the link content like a normal web page, but the click cannot be hijacked and other native APIs called.

Solution

By using the new Web container, any action can be attached to the $jason.body.background Web container, and then Handle events like link clicks.

Let’s look at an example:

Here we attach " trigger": "displayBanner", which means that when the user clicks on any link within the Web container, the displayBanner operation will be triggered instead of being handled directly by the Web view.

In addition, if you look at the displayBanner operation, you will find that the variable $jason appears here. In this example, the clicked link will be passed through the $jason variable. For example, if a URL called "https://google.com" is clicked, $jason will get the following value:

This means we can check The value of $jason.url then selectively triggers different actions.

Let’s take a look at the implementation of a custom web browser as another example:

We will check whether the URL contains the string signin , and perform two different operations based on the results.

• #If signin is included, open a new view and complete the login operation natively.

• If signin is not included, the "type": "$default" operation will be run directly to achieve behavior similar to that of an ordinary browser.

Usage demonstration

Build a custom web browser

Many interesting operations can be achieved by taking advantage of the following features of the new version of the Web container:

• Realizes self-loading through the url attribute and acts as a full-featured browser.

• Selectively handle link click operations based on different URLs.

We can even build a custom web browser with dozens of lines of JSON code. Since every link click can now be hijacked, we can check $jason.url and run whatever actions we need based on the results.

For example, the following example:

##As you can see from the picture above, the behavior after clicking the link is different from normal browsing The device is the same ("type": "$default").

As you can see from the picture below, after clicking the link, you can switch to another JASON view in a native way.

All of this can be selectively triggered based on the value of $jason.url.

Step 1: Attach an operation named visit to the web container:

Step 2: Based on the value of $jason.url Run related operations inside visit

In the following code, we will check whether $jason.url matches content such as latest, show, ask, etc. (all top-level menu item links). If it matches, setting "type": "$default" will make the web container behave like a normal browser.

If the mode does not match, you can open a new view through native $href conversion and pass the clicked link as a parameter.

See the full JSON markup for this web browser (only 48 lines!):

https://github.com/Jasonette /Jasonpedia/blob/gh-pages/webcontainer/agent/hijack.json

Build "hybrid" applications in an instant

When people usually talk about "hybrid" applications, they mainly refer to HTML web applications encapsulated within a native application framework.

But this is not the application mentioned here. The so-called "hybrid" here refers to a true hybrid application, that is, an application that can contain multiple native views and multiple web-based views at the same time. In this kind of application, a view can have multiple native UI components, and a web container rendered with the same native layout.

The interweaving of web views and native views should be as seamless as possible, making it completely indistinguishable to users.

#In this example, I created an app that displays content from jasonbase.com in a web container and uses it as a home page view.

Jasonbase is a free JSON hosting service I developed that makes it easy to host the JSON markup used by Jasonette applications.

Of course, this is a website in its own right, but I embedded it into Jasonette so that instead of opening the web page after clicking the link, it will display the native JASON view through native $href conversion.

You can build this application without touching any Jasonbase.com code.

You only need to embed the website into Jasonette as a web container, and then hijack the native processing of link click operations, so that you can realize various functions of native applications, such as triggering native APIs and performing native conversions.

The complete code can be found here: https://github.com/Jasonette/Jasonpedia/blob/gh-pages/webcontainer/agent/hybrid.json

Conclusion

In my opinion, what makes this so awesome is that everything is handled well at the framework level. All the hardest work is done behind the scenes.

App developers do not need to waste time and effort to implement the following from scratch:

• Embed the web view into the native layout

• Create a JavaScript bridge so that the application can call functions in the web view

• Create a native event handling architecture so that the web view can trigger native events of the parent application

The entire solution creates an abstraction consisting of:

• Declarative markup language: used to describe how to embed a Web view Native application.

• Communication Protocol (JSON-RPC): For extremely simple communication between the application and its child web views.

I don’t think this method can solve all problems, but judging from my own use cases, it is a good solution to say the least.

I try to build applications with very cutting-edge technologies, which are so cutting-edge that there is no stable and reliable implementation on the mobile side (due to some nature of the protocol, it is not even clear whether there will be a mobile version in the end) accomplish). Fortunately, these technologies are implemented in JavaScript, so integrating them into your application is easy and effortless.

Overall, this technique is great and I'm very happy with the results so far. The latest version of the documentation already contains all new features, and everyone is welcome to study it in depth and try it out.

Statement: The greater the ability, the greater the responsibility you need to bear

Finally, I want to say: Although this new technology is indeed very powerful, I think everyone When developing applications, more comprehensive trade-offs should be made in terms of user experience.

Some people may use this technology to build an application entirely composed of Web views, but in the final analysis, your application is actually just a website, which is contrary to the original intention of developing a dedicated application.

It’s important to stress that I don’t think every app you have should contain both HTML and native components. I just think that this approach will be more useful for many people facing certain specific situations, just don't go overboard.

Summary: The above is the entire content of this article. The code is very simple, you can try it. I hope it will be helpful to everyone's learning. For more related tutorials, please visit JavaScript Video Tutorial, jQuery Video Tutorial, bootstrap Tutorial!

The above is the detailed content of JSON realizes seven lines of code to turn the website into a mobile application. For more information, please follow other related articles on the PHP Chinese website!