fix(android)(8_1_X): call WebView.stopLoading() from main thread #11171
Conversation
|
| @@ -1066,7 +1069,13 @@ public void reload() | |||
|
|
|||
| public void stopLoading() | |||
| { | |||
| getWebView().stopLoading(); | |||
| new Handler(getMainLooper()).post(new Runnable() { | |||
There was a problem hiding this comment.
Don't we have a different code pattern for dispatching method calls to happen on the main thread? (like a public handleMessage() method with a switch statement)?
Also, is this the only call that needs to happen on the ui thread? What about goForward(), goBack(), etc?
There was a problem hiding this comment.
What Gary is solving is not thread related. He is doing the equivalent of a JS setTimeout(function, 0). He's posting a runnable to the end of the event queue, which is something you may to do if the method is being called from the same object's callback (ie: you need to unwind the stack before performing the action). I can see this being an issue with the onlink callback since it needs immediately feedback before loading a URL. Although I wouldn't think our WebView events would have this problem since they're queued and not invoked immediately.
I too am curious regarding goForward(), goBack(), and other APIs.
Regarding Handler, I'd prefer that we use it for cases like this. It's simpler and it's what most native Android devs use. handleMessage() is more complicated and error prone (message ID collision has happened in our code in the past) and its only real advantage is that it allows inherited classes to override the handling of received message, which isn't applicable here.
Side Note:
Gary, you don't need to create a new main handler here. There is a View.getHandler() method that you can use instead.
https://developer.android.com/reference/android/view/View#getHandler()
|
Closing, marked for |
JIRA Ticket