Cordova the principle of interaction with iOS native code

Very early wrote a blog, summed up the Cordova plug-in how to call the native code: Cordova call Process, just write too much water. Basically no mention of the principle. The recent deepening of a little understanding, once again to add a note

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 plug-in finally shows the JS interface, and the caller does not need to know that they are calling a Cordova plugin

But in no matter what Cordova JS method inside, finally will call the Cordova.exec function:

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

The key cordova.exec function is then entered. This is the last link of the JS end of the Cordova frame. It's the end of the call to iOS native.

In the EXEC function, the platform is inferred first. may be Android,ios or WP, the other platform is omitted in this article. Assuming it's an iOS platform, Cordova will use one of the following 2 ways. To interact with iOS native code

Via IFRAME

Cordova.exec inserts a non-visible iframe into the current HTML to load a special URL into the UIWebView request. This URL includes, of course, the class name of the native plugin to invoke, the method name, the parameters, the callback function, and so on.

Next. This method of uiwebviewdelegate is called because it is requested to load the URL:

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

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

by XHR

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

+ (BOOL) Caninitwithrequest: (nsurlrequest*) therequest

Also entered the native flank. Then call to native plugin in the same way

In 2 ways, Cordova will prefer the XHR approach. An IFRAME is only used when the XHR method is not available.

Just no matter what. All 2 ways to open a channel from JS to native, the rest is to pass the number of parameters and routing problems

Native Call JS

There is also a more simple channel, because iOS provides native support, so there is no need to think of a special approach. That way, through UIWebView:

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

Looking at the code of the Cordova frame native side, I removed the gaze 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];}

Can see, it is through the UIWebView provided this method is finished, but, must run in the main thread

Synchronous and asynchronous issues

From the above analysis can be found. Invoking native,2 from JS is bound to be asynchronous. And from native back to JS. is a synchronous method, and is running on the main line thread

Call the code of the Cordova plug-in, and the return value must be handled in a callback function. Because the result is returned asynchronously. At the same time, the callback function cannot run too long, or it will clog the native main thread

References

This article has been written in the following 2 articles, which are very good:

iOS version PhoneGap principle analysis

An analysis of Cordova for IOS

Cordova the principle of interaction with iOS native code