Phonegap source code analysis (1) -- android

Phonegap has submitted the source code to Apache and has become a very popular open-source framework, Cordova. Its cross-platform features have a taste and momentum of Java, it has become a mainstream solution on mobile platforms. Today, I tried its Android source code to see how it combines native with web.

First, let's take a look at the main features provided by phonegap:

• Store and render HTML locally
• Run in native app Mode
• Call native with JS

To put it bluntly, we want to build a localized mobile application with only web technology. What is better than HTML5 is that it can pre-package all the required elements (parts and scripts) and integrate native features to a greater extent. Of course, it is fully compatible with HTML5.

For such a product, if I develop it, I feel that the top priority is:

• How to execute and render HTML
• How can the Web end efficiently call native APIs (synchronous and asynchronous)
• What kind of Scaling Mechanism is provided to be compatible with the new Native function?

With these three problems, I analyzed its source code on Android. Its implementation on other platforms remains to be further explored, but I guess the general structure is consistent. The architecture diagram after my analysis is as follows:

We can see the key points in its architecture:

• Rendering HTML based on webview
• Native APIs are encapsulated based on the plugin mode, including the APIS provided by phonegap and customized by developers.
• Use the prompt method to call android on the Web end.
• The android client returns the asynchronous call result to the Web Client in xhr or jsonp mode.

Next let's take a look at these key points.

1) Rendering HTML based on webview

This is relatively simple and everyone wants to get it. It is actually an embedded browser, and various mobile platforms also provide such components, which is webview on Android.

However, phonegap has made some modifications to webview. It extends webviewclient and webchromeclient to change some standard behaviors. It expands webviewclient with cordovawebviewclient and rewrites methods such as Callback, onpagestarted, and onpagefinished, it extends the Web pure URL web page calling behavior, and has the ability to call intent through GEO: XXX and send text messages through SMS: XXX. In addition, it uses cordovachromeclient to expand webchromeclient and rewrites methods such as onjsalert and onjsconfirm. It uses native-style Windows to call the corresponding js-side alert and confirm, make it more like a native program. More importantly, it rewrites the prompt and uses this method to implement JS calls to the android end. This will be discussed in detail below.

In short, it expands webview Based on cordovawebviewclient and cordovachromeclient to provide native styles and capabilities in addition to standard HTML execution rendering capabilities. I will not talk about the code here. It is relatively simple.

2) Encapsulation of native APIs Based on the plugin Mode

This is also relatively simple, but anyone who wants users to expand will think of a plug-in architecture.

Its structure is also relatively flat. There are three classes in total: plugin, pluginmanager, and pluginresult. a configuration file, plugin. xml. I will not talk about the specific responsibilities. Just look at the name.

3) implement web-side Android-side calls in the form of covering the prompt Method

This is what I want to see most about this framework. Although I am a little disappointed (I feel a little cool), it is more practical and straightforward.

Webchromeclient provides an onjsprompt method, which is adjusted when the web side calls the prompt method. Therefore, it changed the method to the interface exposed by Android to the Web. When the Web calls any Android (Java) method, it calls prompt, after onjsprompt is called, it parses the parameters to proxy subsequent behavior. In this case, it mainly calls plugin and uses plugin to meet the requirements of the Web end. Shows the sequence chart:

The previous steps are easy to understand, but why do we need to send JavaScript to a server in the last step? This is the mechanism for implementing asynchronous calls.

4) The Android client returns the asynchronous call result to the Web Client in xhr or jsonp mode.

If synchronous scheduling is not used, plugin.exe cute returns the result directly and calls back to JS through jspromptresult. Confirm.

Asynchronous calling is the most difficult in this framework, but it is applicable to most native API calls, such as camera, which will start other native programs. After these programs are completed, you also need to get their execution results, such as the photos taken.

Phonegap is actually based on a long backpack to push android back to the Web. I will not explain much about the long backpack. I can check the comet to understand that its mechanism is to initiate Ajax periodic calls on the Web end. Android starts a local socket server and maintains a JS queue, if a request comes, it returns the Js in the queue, and the Web end executes the JS again. In this way, the android end pushes the execution result to the Web end. In sendjavascript, the execution result is actually stored in the queue in the form of JSON waiting for the Web terminal to fetch.

However, xhr (or Ajax) has cross-origin restrictions. For example, if the web-side HTML is downloaded from a remote URL instead of a local file, therefore, it cannot initiate Ajax requests to the local server (because of different domains), so it provides an alternative solution: jsonp, which is also a standard solution to cross-origin Ajax, in fact, it is to download and execute Js. This is not much to mention. You can continue to explore it through the keyword jsonp.

In general, this is a common solution, but it is worth considering whether frequent polling of Ajax will affect performance and battery. In addition, basically, it is similar to the direct native program, which is indeed much better than calling HTML5 directly.

This is my analysis of the source code of phonegap on Android. I want to see how it is implemented on iOS and Windows Phone later, but I have to familiarize myself with objective-C and C #, after the analysis, follow up.