Easy Tutorial
❮ Es6 Tutorial Verilog2 Codeguide ❯

7.5.3 Some Considerations for WebView after Android 4.4

Category Android Basic Tutorial

Introduction to This Section:

>

This section refers to the original text: Considerations for Using WebView in Android 4.4.md

Starting from Android 4.4, the WebView in Android is no longer based on WebKit but has started to be based on Chromium. This change has greatly improved the performance of WebView and provided better support for HTML5, CSS, and JavaScript!

Although Chromium has completely replaced the previous WebKit for Android, the API interface of Android WebView has not changed and is fully compatible with the old version. The advantage of this is that APPs built based on WebView can enjoy the efficiency and power of the Chromium core without any modifications.

For WebView after 4.4, we need to pay attention to the following issues:


1. Multithreading

>

If you call the relevant methods of WebView in a child thread instead of the UI thread, unpredictable errors may occur.

So, when your program needs to use multithreading, please also use the runOnUiThread() method to ensure that your operations about WebView are performed in the UI thread:

runOnUiThread(new Runnable(){
@Override
public void run(){
   // Code for WebView goes here
   }
});

2. Thread Blocking

>

Never block the UI thread, which is a truth in the development of Android programs. Although it is a truth, we often unconsciously make some mistakes that go against it. A common mistake in development is to wait for the JavaScript callback in the UI thread.

For example:

// This code is BAD and will block the UI thread
webView.loadUrl("javascript:fn()); 
while(result == null) {  
    Thread.sleep(100); 
}

Never do this. In Android 4.4, a new API is provided to do this.

The evaluateJavascript() is specifically for asynchronously executing JavaScript code.


3. The evaluateJavascript() Method

>

Specifically used for asynchronously calling JavaScript methods and obtaining a callback result.

Example:

mWebView.evaluateJavascript(script, new ValueCallback<String>() {
 @Override
 public void onReceiveValue(String value) {
      //TODO
 }
});

4. Handling URL Redirection in WebView

>

The new WebView has added stricter restrictions for custom scheme URL redirection. When you implement the shouldOverrideUrlLoading() or shouldInterceptRequest() callback, the WebView will only redirect when the URL being redirected is a legal URL.

For example, if you use such a URL:

<a href="showProfile">Show Profile</a>

shouldOverrideUrlLoading() will not be called.

The correct way to use it is:

<a href="example-app:showProfile">Show Profile</a>

The corresponding way to detect URL redirection is:

// The URL scheme should be non-hierarchical (no trailing slashes)
 private static final String APP_SCHEME ="example-app:";
 @Override 
 public boolean shouldOverrideUrlLoading(WebView view,String url){
     if(url.startsWith(APP_SCHEME)){
         urlData = URLDecoder.decode(url.substring(APP_SCHEME.length()),"UTF-8");
         respondToData(urlData);
         return true;
     }
     return false;
}

Of course, you can also use it like this:

webView.loadDataWithBaseURL("example-app://example.co.uk/", HTML_DATA,null,"UTF-8",null);

5. Changes in UserAgent

>

If your App's backend program does different things based on the UserAgent sent by the client, you need to pay attention to the fact that in the new version of WebView, the UserAgent has some subtle changes:

Mozilla/5.0 (Linux; Android 4.4; Nexus 4 Build/KRT16H)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0
Mobile Safari/537.36

You can use the getDefaultUserAgent() method to get the default UserAgent, and you can also set and get a custom UserAgent through:

mWebView.getSettings().setUserAgentString(ua);
mWebView.getSettings().getUserAgentString();

6. Notes on Using add

❮ Es6 Tutorial Verilog2 Codeguide ❯