directory

  • Interaction between App and Js (I) iOS
  • Interaction between App and Js (II) Android
  • Interaction between App and Js (iii) Recommended General Solutions for Android and iOS

The sample code

Demo: github.com/gwpp/jsinte…

The body of the

In the first two articles, we listed the interaction modes between Android and iOS and JS in detail. There are 5 ways for iOS and 3 ways for Android. If there are others, please continue to add and study together. How do we choose from so many ways to interact? Those of you who have read the first two articles should be able to read some points:

  • There are many methods, but the degree of difficulty is different, and some things need time cost and learning cost to use in a team.
  • Some have introduced tripartite libraries and some are supported natively.
  • Some are common to both Android and iOS, while others are unique to each platform.

Several principles of technology selection

When we do technology selection, there are generally several principles:

  • Ease of use. The ability of the team to hold, if the whole team does not have a person, that is to seriously consider the cost of learning.
  • Platform versatility. We take this very seriously in end-to-end interaction, and we want to have a solution that works perfectly with all platforms, rather than just one way or another.
  • Community support. Working alone or in a small group is hard, and it hurts to have nowhere to ask or discuss anything but your problems.
  • Invasive. If a solution can be easily integrated, the related code is clustered in one or two files; The alternative will be written all over the place. Which one do you choose?
  • Maintainability. What we need is that after the introduction of this program, we only need to encapsulate or precipitate an internal technical document, so that any students can modify it. Not just a specific person or a few people.
  • The other…

A recommendation

Rory’s been saying a lot about this, so what are we supposed to do? Recommendations are as follows:

  1. Intercepting jumps (entry level)

    • Application scenario: There are not many embedded pages and the team is not strong in technical ability

    • IOS: UIWebView/WKWebView can be used in the form of intercepting jumps. For specific operations, see Plan 1 and Plan 2 in interaction between App and Js (I) iOS.

    • Android: Intercept jump form, specific operations see “App and Js Interaction (ii) Android” scheme 1.

    • Reasons for recommendation:

      1. Cross-platform. JS side does not need to care whether it is Android side or iOS side. After the agreed jump link, both sides can be unified.
      2. Easy to use. The JS side just needs towindow.location=xxxxGood, Android, iOS also just block the jump, online tutorials are many, not easy to make mistakes.

    • Disadvantages:

      1. A lot of hard coded code, the agreed links are written dead.
      2. Because return and callback are not supported, communication is one-way and can only be donesendOperation, can’t dogetOperation.

  2. Expose Native objects for JS calls

    • Application scenario: There are many embedded pages and the team has strong technical ability

    • IOS: only UIWebView is supported and an Objective-C object is exposed for JS to call. For detailed operations, see Scheme 3 of App and JS Interaction (I) iOS.

    • Android: Expose a Java object for JS to call, see the detailed operation of “App and JS Interaction (ii) Android” scheme 2.

    • Reasons for recommendation:

      1. Cross-platform. JS side does not need to care whether it is Android side or iOS side. After the agreed jump link, both sides can be unified.
      2. Mobile ends no longer need to intercept jump links, less hard coding.
      3. Supports bidirectional return. That is, JS calls Native methods can get a return, and Native JS calls can also get a return.
      4. The JS side can easily encapsulate interactive code into a lib that can be called by any page.

    • Disadvantages:

      1. IOS only supports UIWebView, and UIWebView’s memory optimization, loading speed and so on are not as good as WKWebView. It is not a good choice to abandon WKWebView in order to use this interaction mode.
      2. Android API 16 has security issues. For details, see jaq.alibaba.com/blog.htm?id…
      3. Only return is supported, but callback is not. Therefore, the return value cannot be obtained in the asynchronous invocation. For example, I want JS to call the APP login and return the user information to JS after the login. This is a very common requirement, but this interaction mode cannot be achieved.
      4. JS side call is very convenient, but the APP side initialization will be more troublesome, especially iOS.

  3. JSBridge (Mature Level)

    • Application scenario: there are many embedded pages, the team has strong technical ability, and the APP and JS team are willing to work together

    • IOS: UIWebView/WKWebView can be used, using the bridge mode, see the specific operation of “App and Js Interaction (I) iOS” scheme 4, scheme 5.

    • Android: Use the bridge mode. For details, see Scheme 3 in App and Js Interaction (ii) Android.

    • Reasons for recommendation:

      1. Cross-platform. JS side does not need to care whether it is Android side or iOS side. After the agreed jump link, both sides can be unified.
      2. Mobile ends no longer need to intercept jump links, less hard coding.
      3. Supports bidirectional callback, which can be called back asynchronously.
      4. The JS side can be wrapped as lib and can be called from any page.
      5. High security.

    • Disadvantages:

      1. Only callback is supported, but return is not supported.
      2. The initialization code of JS, Android and iOS is very complicated. Error screening is more troublesome, the team had better have a three-way master, otherwise sometimes out of the BUG really crazy.

Write in the last

As you can see, the three solutions I recommend are all cross-platform, because this is really important, otherwise the JS crowd will go crazy if there are too many pages.

Our team has used all these three schemes. [1] They were abandoned long ago because the code was too redundant, and the interception of APP failed as soon as the front hand shook. [2] and [3] we hesitated for a long time, because both of them can meet our needs. [2] It is simpler and there are many online materials, but iOS cannot use WKWebView and does not support asynchronous callback. [3] It was a little complicated. There were often problems when I used it at the beginning, because there were often problems in the initialization of JS. Later, I found out that it was because of the code execution order, init was not finished before the APP method was adjusted.

In the end, we chose [3]. Although it does not support return, callback can at least fulfill all the requirements, but sometimes it is not as good as return. As for the complexity of the initialization code, the pit is over once and all is well after that.

The interaction between APP and JS is indeed a lot of pits, the deeper it goes, the more pits I feel. I will share with you some new discoveries in the future, and this series is over. Thank you for all the students who patiently watched, haha ~~