Android WebView and mobile phone back button

[Story Summary]
Today, we are investigating an online Bug.
The product itself is an Android application. Installed and running on Android devices in APK mode. The overall architecture is the naive development framework, which is embedded in the WebView. There is nothing to say about this.
This online Bug occurs when the Android device's backend button fails during certain screen migration. The vast majority of images are acceptable.
For example, image migration in the following Case:
A Overview screen-> B login screen-> C login confirmation screen-> D login end screen-> A Overview Screen
The URL of each stage is:
/List->/xxxregiest? Id = 12->/xxxregiest->/list
The phenomenon is that after the entire migration chain is completed, it returns to the View screen, and then click the back button of the Android device. There is no response ....
 
 
[Investigation and Analysis]
First, I want to use the browser that comes with the Android device for an operation.
On the Android browser, after the entire migration chain is completed, click the return button to display the message "post sending duplicate submission ....
As a result, I thought it was definitely because a form was submitted between image migration, so the WebView failed to roll back.
 
So I changed a flat test and found that the rollback button is valid during the migration from B login screen to C login confirmation screen.
But the migration of B login screen-> C login confirmation screen is also completed by form submission?
Where is the problem?
Aha !!! I saw it.
The reason why the rollback button is invalid is:
/Xxxregiest is not Rest. That is to say, when loading this url, the background program will decide where to forward based on the post message.
B login screen-> C login confirmation screen-> D login end screen, two post data submissions. The system uses token to avoid repeated submission.
That is to say, the two post data submission processes are irreversible. When you click the back button at the end, the last post of the entire data link is submitted repeatedly.
 
[Corresponding]
The method I first came up with was to call the background JsInterface code in the js submitted by form to do webView. clearHistory ().
In this way, the history records in the webView will be cleared before the previous screen is submitted.
However, it was found that clearHistory can only take effect after the current screen is initially completed.

Finally, what is simple and effective is to capture the current keydown event and migrate the final picture based on the current URL.
In short, the process of rewriting the entire Web screen is backward.
Code example:
[Java]
@ Override
Public boolean onKeyDown (int keyCode, KeyEvent event ){
 
If (webViewUrl = null ){
Return super. onKeyDown (keyCode, event );
}
 
Try {
Switch (keyCode ){
Case KeyEvent. KEYCODE_BACK:
 
// Obtain the current url
String currentUrl = webView. getUrl ();
// Sort the process according to the business logic
If (currentUrl. indexOf ("xxx_regist ")! =-1 ){
Return true;
} Else if (currentUrl. indexOf ("list ")! =-1 ){
WebView. clearHistory ();
WebView. loadUrl (this. getResources (). getString (R. string. top_page ));
Return true;
}
// If it is reserved, it is left to webView for judgment.
If (webView. canGoBack ()){
WebView. goBack ();
Return true;
} Else {
// If no url can be returned and the homepage is displayed, the exit dialog box is displayed.
If (webViewUrl. equals (this. getResources (). getString (R. string. top_page ))){
DialogFactory. exitApplicationDialog (this). show ();
Return false;
}
}
} Catch (Exception e ){
}
Return super. onKeyDown (keyCode, event );
}

 

Author: nanjingjiangbiao