Writing a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (I) — Idea Construction

“Write a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (II) — Plug-in”

“Write a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (III) — Configuration Plug-in”

“Write a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (IV) — Framework Construction”

preface

Based on the previous three chapters, we have completed the basic construction of Hybird framework. Based on the “Writing a Hybrid Framework (III) that is easy to maintain, convenient to use and reliable in performance — Configuration Plug-in”, we have made some optimization, and then made the compatibility of UIWebView. There are many cross-platform solutions, including WEEx, RN and FLUTTER. So is it still necessary to explore WebView? In fact, we can get to the bottom of them, and maybe there will be no confusion. Cross-platform solutions are designed to save costs, iterate quickly, and even achieve hot update capabilities. So who is WebView for? It is the whole front-end developer. Building web applications is still the most efficient, the most extensive, and the most capable of hot update. With the Nebula Framework, alipay has a unique WebView framework for all of its applications, which is not at all in conflict with the cross-end technologies outlined above. Belong to neck and neck.

Today’s talk is how to take a Hybrid WebView framework and make it project independent. It exists in your project like AFN, SD, and is not part of your business, like Nebula from Alipay, and make it part of your project component.

The following four aspects will be analyzed step by step, as far as possible more dry goods.

directory

  • Analysis of the situation
  • Management plan
  • The framework to build
  • conclusion

I. Current situation analysis

The foreword basically explains why we need to build WebView framework at present. At present, every project should be a mixture of front-end and client development, and pure native projects have retired from history. As far as the project is concerned, the H5 will be built in the client and will naturally involve dealing with the client. It is believed that many apps still use the way of original interception to interact with JS and Native end, and intercept JS requests through a defined protocol. This method is simple, but it has too many disadvantages.

First of all, from the technical level, so you need to do to queue control of JS calls in a row, avoid the loss of communication, which is a complex work, and low efficiency, and secondly by false request intercept, once the request parameter stitching is too complex also produces some of the other side effects, such as the long url parameters cannot be intercepted, error parameters after joining together string interception and so on.

Note: url intercepting is not always done this way. Cordova and WebViewJavaScriptBridge, for example, use a different method: curvesaving, adding a javascript layer to handle parameter scheduling rather than intercepting parameters directly.

Secondly, we consider from the business level, when the need for communication is increasing, whether the code in the WebView framework will become more and more redundant, whether the mixed business will become more and more, whether the coupling is higher and higher and so on. Do we continue to make the WebView framework redundant when we have new requirements coming in? Reuse is even less possible.

I believe that many apps are still stuck in the above example, so how to solve these problems? First we should have a good communication scheme, an avant-garde, advanced communication scheme can be compared to the heart of the framework.

Now let’s continue to analyze what communication plan is more suitable for us.

Second, governance scheme

For the governance scheme, you can see my other article “Writing a Hybrid Framework (I) that is easy to maintain, convenient to use and reliable in performance — Idea Construction”, which mainly describes the idea of framework construction. The last two articles extend and further optimize the idea.

At present, it seems that there are many advantages and disadvantages in communication selection.

JS call client:

  • 1. Fake jump blocking: also mentioned above, this should be the first scheme to be passed because it is not secure! As far as the mainstream open source is concerned, both Cordova and WebViewJavaScriptBridge have done a lot of operations on it. For details on the operation of Cordova, please refer to my previous article “curve saving the country” of Cordova framework.
  • 2. Popover blocking: UIWebView does not support popover blocking JS. WKWebView supports Confirm ()/ Prompt () popover interception and synchronous return.
  • 3.JavaScriptCore framework injection: This is an incredibly powerful framework that iOS7 started supporting, so powerful that RN is based on it, and it’s full of dark magic. See JavaScriptCore for details on how to use it, but unfortunately only UIWebView supports it. WKWebView cannot get JSContext from KVC, so WK does not support it.
  • 4. The Messagehandler injection: AddScriptMessageHandler: the addScriptMessageHandler function came with WKWebView for developers in iOS8, so unfortunately it’s only supported by WKWebView, but I understand it as the son of apple communications, which is apple dad.

The above lists all the communication ways of JS to the Native terminal. If we have to choose a scheme to implement, the following two are preferred:

  • WKWebView preferred Messagehandler injection:
[webView.configuration.userContentController addScriptMessageHandler:self name:@"WKJSBridge"];
Copy the code
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {
    if ([message.body isKindOfClass:[NSArray class]]) { [_webViewhandleFactory handleMsgCommand:message.body]; }}Copy the code

The JS invocation is also very simple, with client-injected WKJSBridge to build the communication:

window.webkit.messageHandlers.WKJSBridge.postMessage()
Copy the code

The above code is Messagehandler way of communication process, very simple, from the code can be very clear to see what is the pro son of communication, and then compared to the curve of national salvation type of communication, the contrast is often obvious. WKJSBridge is the JS function injected by WKWebView. Message. body can be any ID object, depending on what type the JS side is passing to the client. The demo is passing the NSArray type.

  • UIWebView preferred JavaScriptCore framework:

JavaScriptCore is extremely powerful. You can directly inject a function into JS for it to call, or directly inject an OC object into JS for it to use, full of black technology. Both RN and Weex are built on this. For more details, see WKJavaScriptBridge.

The client actively invokes JS:

  • EvaluatingJavaScript: function: supports UIWebView only, synchronous callback.
  • 2. EvaluateJavaScript: completionHandler: function: only support WKWebView, asynchronous callback.

There is no doubt about the client callback JS way, each can choose their own.

The selection section of the communication is determined:

  • WKWebView:Messagehandler noteandevaluateJavaScript:completionHandler:The callback.
  • UIWebView:JavaScriptCore framework injectionandevaluatingJavaScript:The callback.

So let’s take a look at what to do about redundancy caused by too much business.

This is also mentioned in the previous article. Check out “Writing a Hybrid Framework that is easy to maintain, easy to use, and reliable — Plug-in” for more information. Plug-in construction, so that each business function becomes a module, a plug-in. What does plug-in mean, it is independent!! There is no coupling to any other class except our Web framework, it is just managed by the framework, quietly working there, deleted project still Build!! After the plug-in is made, drag it to the project to be used directly. In this way, the business modules are completely separated and the framework is completely stripped. New requirements only need to build new modules, without moving the Web framework.

Fetch in the screenshot can be interpreted as JS requests the client to do this function, Device can be interpreted as JS wants the client’s Device information function, etc… It would be nice to expand this module indefinitely if there were new requirements. It’s clear. Please download the project for details. Take a look at my previous article configuring plug-ins for plugin registration. After such processing, is not our code at a glance, easy to maintain, extensible, the focus is no coupling!!

By now, all the problems mentioned above have been solved. Based on the previous articles, we have Coding a Hybrid framework named WKJavaScriptBridge, which is now being promoted in the project. If you think it is helpful, welcome Star, and welcome Issue if you have any questions. About WKWebView’s various pits can be seen in the WKWebView article. Here are the main building ideas for the WKJavaScriptBridge project.

Third, framework construction

Frame address:Github.com/GitWangKai/…

Frame structure:

The main features of the framework are: compatibility with UIWebView and WKWebView, plug-in interactive business module, and of course some other features refer to Readme.md.

Building principles: decoupling, business separation, low code immersion, high scalability, high reuse, easy integration.

Framework class diagram:

UIWebView is compatible with WKWebView and can be customized by the business. The framework does not care what type is passed in, it can be processed.

The construction of the project is mainly based on the pain points mentioned above. The current version is 0.0.1, and it will be expanded in the future. Specific implementation of the source code, if you feel helpful, welcome Star.

Four,

At the end of this paper, I would like to make a conclusion. At present, the above scheme is just a cornerstone for Hybrid, and there will be many work to be extended in the future. At least the components Hybrid handles in WebView are already in place. Based on this, offline packages will be expanded, JS side plug-in processing, Flutter cross-end technology will be introduced, and small program framework will be constructed. Next I’ll build the second feature: the offline package component.

Stay tuned.

If there are any questions or suggestions welcome the issue and make it better.