JS Call app method and app call JS method

When doing an embedded H5 project, we often encounter the interaction between JS and the app, the most common is the method of mutual invocation, then how to implement the method of mutual invocation?

Write in front:

If it is only a small project and the likelihood of a late expansion is negligible, but if it is a long-term project, then the following questions need to be considered.

1. Method naming specification.

If considering the future there will be a large number of methods, then the normalization of the naming is very important, standardized naming, not only to ensure the uniqueness of the name and ensure the readability of the Code to facilitate the development process, but also convenient for later maintenance.

For a chestnut, if there is now a method, is to close WebView, JS call the application method, if called Closepage, then simply can not see the method to invoke the app, confusion and may be the other naming overrides, then if called Jams__closepage, That is, all of the JS and app interaction methods are added JAMS so it is easy to distinguish, and not easily duplicate name.

2. Security.

If you can open other Web links in your app, then the security of these interfaces also needs to be considered, that is, it is important to ensure that these methods are invoked within the specified WebView or authorized webview.

The first method is to determine the WebView address source in the app to match the right to use the method, it is obvious that each time you add a new page and method, the app needs to modify the authorization list.

The second approach is that when the app opens WebView, if it's its own business H5 then it can pass in a token when it's called, validating tokens every time the method is called.

One, JS call app method

Suppose the method is named Jams__mark

Android System:

Window.android.JAMS__mark (params)//@params for incoming parameters, the app can receive iOS system: window.webkit.messageHandlers . Closepage.postmessage (params)//@params for incoming parameters, the app can receive

And then you can encapsulate it like this.

 export function   Jams__mark () { if  (/android/i.test (navigator.useragent)) { 
   
    try  
     {Window.android.JAMS__mark (params)}  /span>catch   (E) {Console.log (e)}}  else  if  (/ios|iphone|ipod|pad/< Span style= "COLOR: #000000" >i.test (navigator.useragent)) { 
    try  
     {window.webkit.messageHandlers.JAMS__mark.postMessage (params  
     catch   (e) {Console.lo G (E)}}}  
   

Second, the app call JS method

The app calls the JS method requires JS to mount the method under window, so that the app can call to the method,

Suppose the method is called Jams__success

Window. jams__success = function () {

Do some thing

If need some params, you can alse return it

return params;

}

The main thing is that if you need to return some data to the app, then the data can not be obtained asynchronously, nor can there be a blocking process of the statement such as alert, no, the app will not be able to get the correct parameters, but to get undefined, such as in the method add an alert (' 1 '), and Return after the alert statement.

Finish

JS Call app method and app call JS method