Cordova the principle of interaction with iOS native code

Long ago wrote a blog, summed up the Cordova plugin how to call the native code: Cordova call process, but write too much water, basically did not mention the principle. Recently deepened a bit of understanding, re-added the explanation

JS Call native

Here are the code snippets from our product:

Datepicker.show (Options, function (date) {    var month = Date.getmonth () + 1;    Callback (NULL, date.getfullyear () + "-" + month + "-" + date.getdate ());});

The Cordova plugin eventually shows the JS interface, and the caller does not need to know that they are calling a Cordova plugin

However, within any Cordova JS method, the Cordova.exec function will eventually be called:

Cordova.exec (Successcallback, Errorcallback, "DatePicker", "show", []);

It then enters the key cordova.exec function, which is the last link of the JS end of the Cordova frame, which completes the call to iOS native

In the EXEC function, the first will judge the platform, may be Android,ios or WP, other platforms omitted, if it is the iOS platform, Cordova will use the following 2 ways to interact with iOS native code

Via IFRAME

Cordova.exec inserts an invisible iframe into the current HTML to load a special URL to the UIWebView request, which contains, of course, the native plugin class name, method name, parameters, callback function, etc. to be called.

Next, this method of uiwebviewdelegate is called because the URL was requested to load:

-(BOOL) WebView: (uiwebview*) Thewebview shouldstartloadwithrequest: (nsurlrequest*) Request Navigationtype: ( Uiwebviewnavigationtype) Navigationtype

Here on the native side, from the request to get the JS end of the message sent over, and then call to native plugin

by XHR

Another way, cordova.exec directly initiates a XHR request, is intercepted by the nsurlprotocol of the native side, and calls to this native method:

+ (BOOL) Caninitwithrequest: (nsurlrequest*) therequest

Also entered the native side, and then called to native in the same way plugin

In 2 ways, Cordova will prefer the XHR mode, only if the XHR method is not available, the IFRAME will be used. However, in any case, these 2 methods for from JS to native open a channel, the rest is the transmission of parameters and routing problems

Native Call JS

The other channel is much simpler because iOS provides native support, so there's no need to think of a particular way. This method is passed UIWebView:

-(NSString *) stringbyevaluatingjavascriptfromstring: (NSString *) script;

Looking at the code on the native side of the Cordova frame, I removed the comment and extraneous code:

-(void) Evaljshelper: (nsstring*) js{    if (![ Nsthread Ismainthread] | | !_commandqueue.currentlyexecuting) {        [self performselectoronmainthread: @selector (evalJsHelper2:) Withobject: JS Waituntildone:no];    } else {        [self evaljshelper2:js];}    }

-(void) EvalJsHelper2: (nsstring*) js{    nsstring* Commandsjson = [_viewcontroller.webview STRINGBYEVALUATINGJAVASCRIPTFROMSTRING:JS];}

As can be seen, it is done by the method provided by UIWebView, however, must be executed in the main thread

Synchronous and asynchronous issues

From the above analysis can be found that from the JS call native,2 method must be asynchronous. And from native back to JS, but is a synchronous method, and is running in the main line thread

Call the code of the Cordova plug-in, and the return value must be handled in the callback function, because the result is returned asynchronously. At the same time, the callback function cannot be executed too long, otherwise it will block the native main thread

Reference

This article refers to the following 2 articles, which are well written:

iOS version PhoneGap principle analysis

An analysis of Cordova for IOS