This dsbridge is similar to the way I developed the hybrid development in the past, so I feel very good and recommend it to you all.
Dsbridge-ios:https://github.com/wendux/DSBridge-IOS
Dsbridge-android:https://github.com/wendux/DSBridge-Android
For comparison with Webviewjavascriptbridge, please visit dsbridge VS webviewjavascriptbridge.
Original link: http://www.jianshu.com/p/3946605109ed
Five minutes to learn about Dsbridge
Web-side
Suppose the native end implements two Api:testsyn, Testasyn. Parameters are passed in JSON, Testsyn is the synchronization API, the result is returned directly after execution, and Testasyn is an asynchronous API (which may take a time-consuming operation), and the result is returned asynchronously when execution is finished. Let's look at how the Web side calls.
JavaScript calls native
var bridge = Getjsbridge (), var str=bridge.call ("testsyn""Testsyn " }"); Bridge.call ("testasyn""Testasyn " }, Function (v) { alert (v);})
Simple enough to explain! It's so classy. If you don't know, you might want to look at the most popular Webviewjavascriptbridge today (the Admiral will be history), and I'm sure you'll be back when you're finished.
Getjsbridge
Function: Gets the JavaScript Bridge object.
Wait, does it look like the other libraries I used before, don't need to declare a Setupwebviewjavascriptbridge callback as Webviewjavascriptbridge? You have this question very normal, first answer: No, Dsbridge does not need any front-end installation code, with the use of. Dsbridge's design principle is: Let the three-terminal use is the simplest! When Dsbridge gets bridge, it does not rely on any callbacks, nor does it need to wait for the end of the page load (if you don't, you can compare the Webviewjavascriptbridge front-end call method). PS: This test on the ios>=8,android>sdk19 is no problem, Dsbridge is also compatible with the version of Ios7.0-8.0,android Sdk16-19, but considering the problem of test coverage, it is recommended that all the code in the DOM Execute after ready.
Bridge.call (Method,[args,callback])
Function: Call Native API
Name of Method:api function
Args: Parameters, type: JSON, optional parameters
Callback (String returnvalue): Required only when calling asynchronous APIs.
Synchronous invocation
If you are an experienced developer, you must see the second line is already bright eyes, think of what node is the most criticized, there is no one in the cross-platform Jsbridge to support synchronization, all need to get the value of the call will have to pass a callback, if the call logic is more complex, it will appear " Callback Hell ". However, Dsbridge has completely changed this point. Support for synchronization is one of the biggest highlights of Dsbridge.
asynchronous invocation
For some more time-consuming APIs, Dsbridge provides asynchronous support, as shown in the third line of code, where you need to pass a callback (if there are no arguments, the callback can be used as the second argument), and the callback will be called when the API is complete, and the result is passed as a string.
For native to invoke the JavaScript API
Suppose you want to provide a function test in your Web page for native calls, as long as you declare the function as a global function:
function test (ARG1,ARG2) { return arg1+arg2;}
If your code is in a closure, hang the function on the window:
window.test=Function (arg1,arg2) { return arg1+arg2;}
This can be called on the end
iOS-side Implementation API
The implementation of the API is very simple, just need to put the API you want to burst to JS in a class, and then unified registration can be.
//JSAPITEST.M@implementationjsapitest-(NSString *) Testsyn: (Nsdictionary *) args{return[(NSString *) [args Valueforkey:@"msg"] Stringbyappendingstring:@"[syn call]"];}- (void) Testasyn: (nsdictionary *) args:(void(^) (NSString *_nullable result)) handler{handler ([(NSString*) [args Valueforkey:@"msg"] Stringbyappendingstring:@"[Asyn Call]"]);}@end
Testsyn is the synchronization API, JS in the call Synchronization API will wait for native to return, after the return JS continue to execute down.
Testasyn is an asynchronous API that invokes Handler.complete notification JS when an asynchronous operation is invoked, and the callback set in JS is called.
To be compatible with iOS and Android platforms, the iOS native API interface is agreed as follows:
- The return value type is nsstring when it exists and is void when it does not exist.
- Parameters are passed in JSON; Dsbridge will automatically convert the JS parameter to Nsdictionary
Note: Methods implemented in JSAPITEST.M can not be declared in the JsApiTest.h
Registration API
Dwebview * webview=[[Dwebview alloc] Initwithframe:bounds];jsapi=[[Jsapitest alloc] Init];webview. Javascriptinterfaceobject=jsapi;
Dwebview is provided in the SDK, you can use the other two, which is described later in this article.
Visible for native, through a separate class implementation of the JS API, and then directly register (and do not need to like some other JS bridge each API to be registered separately), this is not only very simple, and the structure is clear.
Invoking JavaScript
The Dwebview provides two APIs for invoking JS
// Invoke JS API (function)-(void) Callhandler: (NSString *) methodName arguments: (Nsarray * _nullable) args Completionhandler: ( void (^) (NSString * _nullable)) Completionhandler; // execute arbitrary JS code -(void) Evaluatejavascript: (NSString *) javascriptstring Completionhandler: ( void (^ _nullable) (NSString * _nullable)) Completionhandler;
Callhandler, MethodName is the JS function name, args is a parameter array, you can accept numbers, strings, and so on.
The two function Completionhandler is the completion callback, which is used to get the result of JS execution.
Call timing
Dwebview JS code can be executed correctly only after JavaScript context initialization is successful, and JavaScript context initialization is usually done sooner than the entire page is loaded, and then Dsbridge can capture JavaScript Context initialization completion time, but some JS API may be declared at the end of the page, or even a separate JS file, if the JavaScript context is just initialized to invoke the JS API, the JS API may not yet load, so it will fail, For this purpose a dedicated API set a callback, it will be called after the end of page loading, in order to distinguish with didpagefinished, we name as follows:
-(void) Setjavascriptcontextinitedlistener: (void(^_nullable) (void)) callback;
If you invoke JS on the end, do so in this callback. Examples are as follows:
__block Dwebview * _webview=webview;[ WebView Setjavascriptcontextinitedlistener:^() { [_webview callhandler:@ 'test " Arguments:[[nsarray alloc] initwithobjects:@1,@ "Hello" , Nil] Completionhandler:^ (NSString * value) { NSLog (@ "%@" ) , value); }];}];
For a complete example, check out the demo project.
About Dwebview
There are three webview in the SDK:
Dwkwebview: Inherited from the wkwebview, internal has implemented JS prompt, alert, confirm function corresponding dialog box.
Duiwebview: Inherit from UIWebView
Dwebview: Custom view, internal ios8.0 below will use Duiwebview, greater than or equal to 8.0 will use Dwkwebview.
All WebView In addition to implementing the above API, provides a handy function for loading Web pages:
-(void) Loadurl: (NSString *) URL;
You can use any one according to your specific business, but in general, Dwebview is preferred, and it is more efficient and resource-saving on new devices.
Dwebview also provides some other APIs and properties, see the header file for specific instructions, there is an API:
-(ID _nullable) getxwebview;
It can return the real webview used inside the Dwebview, and the value will be one of Duiwebview and Dwkwebview instances, you can judge by Iskindofclass, eating function is mainly used to expand Dwebview, Below you can see the approximate implementation of Loadrequest:
-(void) Loadrequest: (Nsurlrequest *) request{ ID webview=[self getxwebview]; if class ] ]) { *) webview loadrequest:request]; } Else { *) WebView loadrequest:request];} }
Attention
Dwebview has implemented the alert, prompt, comfirm dialog box, which you can do without processing or customizing. It is worth mentioning that JS in the call alert function normally as long as the user does not close the Alert dialog box, the JS code will be blocked, but considering the alert dialog box has only a certain button, that is, whether the user is closed or determined will not affect the JS code flow, So dwebview in the pop-up alert dialog box will be the first to return to JS, so that JS can continue to execute, and the prompt box and other users close when closed. If you are the alert that you want to block, you can customize it. Dwebview's prompt and COMFIRM implementations are fully compliant with the ECMA standard and are blocked.
Do not manually set the delegate property of the Duiwebview because Duiwebview has set the property internally and if you need to handle the page loading process yourself, set the Webeventdelegate property.
Mixed development JS Bridge rookie-dsbridge iOS