Implemented Auto Refresh for WebView #77
Conversation
Updated Libs and changed strings in implementations to variables in Libs object
Updated Kotlin Version to v1.3.71 since Kotlin Coroutines v1.3.7 are only supported with Kotlin v1.3.7+
Added multidex following android docs, https://developer.android.com/studio/build/multidex
NetworkStatusEvent will be used with EventBus, it will carry the NetworkStatus to Listeners or Subscribers to that Event Once the NetworkStatusEvent is received, certain actions will be taken, depending on if the device is online or offline.
Checking if user is online is done through opening a socket with 8.8.8.8 (google dns). This online check is according to the stackoverflow answer linked below. It is faster than other options. https://stackoverflow.com/a/27312494/5512292
…line This is used in order to check if the device is back online. Once the device's connectivity changes, ie is connected to internet after being offline, it posts an Event indicating the device is back online.
A coroutine scope is started in the main activity, in oder to prevent work leaks. onDestroy, all coroutines are cancelled. The webview client takes the coroutine scope, again to avoid work leaks, and utilizes it to check if the user is offline when the webview client receives an error Once the webview client receives an error, an Event indicating the user is offline is posted. The webview client is subscribed to the NetworkStatusEvent in order to know the network status. Once the device is offline, the network watcher is started (a broadcast receiver waits until the device is back online). Once the device is back online, the network watcher is stopped and the webview is refreshed It is important to note that the webview client is not automatically registered to the Event. This is because we want to avoid leaks. Therefore, whenever it is manually registered, it should be manually unregistered.
|
|
There was a problem hiding this comment.
Hi @nizarmah thanks again for the PR! This seems like a thorough implementation, but I wasn't able to see it working locally.
I added a couple inline comments and here's a couple GIFs that show what I was doing to test this out. The GIFs turned out a little big so might have to let them load to see them well (~1 min long).
Without the Service Worker:
With the Service Worker:
app/src/main/java/to/dev/dev_android/util/network/NetworkUtils.kt
Outdated
Show resolved
Hide resolved
|
I'm actually astonished that they aren't working at all for you. Here's a video of what's happening on my end. I'll look further into it and let you know. Sorry about this inconvenience. Once I have figured out exactly what is wrong, I'll definitely update this PR. For now, I'll put it as |
nizarmah
changed the title
|
I found a possible issue. The refresh isn't working except once after launching the application. I need to look further in to it. I haven't done the proper testing that I should have, apparently. Sorry for that. |
Uses hostname instead of url, so created BuildConfig.baseHostname instead of trimming the 'https://' and '/' segments of the BuildConfig.baseUrl. This gives for easier changes later on in the future. Also, @fdoxyz requested that change in order to reconnect to the website once it is up again, if it was down. Mentioned in pull request #77.
…Client Previously, an exception was being thrown due to unregistering a network watcher and then trying to unregister it again later on. Now, since it is being cleared back to null, it is no longer being unregistered again if it was previously unregistered
nizarmah
changed the title
app/src/main/java/to/dev/dev_android/view/main/view/CustomWebViewClient.kt
Show resolved
Hide resolved
onReceiveError was being called multiple times, this was resulting in multiple events being posted indicating that the device is offline. Accordingly, it was important to stop re-registering the networkWatcher again and again whenever the events were captured. However, it was previously done in case the coroutineScope did change. However, if the coroutineScope changes, the activity has probably died and been recreated. Therefore, the webview would have already been destroyed and recreated with the new scope. Thus, there is no need to re-register a network watcher if it has already been registered
|
Alright 🎉 I guess that's all! I'm glad you think the solution is working well! I hope you liked my contribution, because I plan to contribute more to the DEV android application. |
…bug/auto-refresh # Conflicts: # app/build.gradle.kts
There was a problem hiding this comment.
Really appreciate all the work for this @nizarmah! And of course help on the repo is greatly appreciated! For feature requests maybe the best route to go with is opening an issue first but feel free to ping me anytime. I'll try to add some more small issues so we can have a clear path as to what to work on.
I just fixed a small conflict from another PR being merged.
|
@fdoxyz yeah it would be great if there were labels indicating which issues can be worked on and which can't. I went through the issues earlier today and it was a bit of a mess. There were many things still open even though they were already merged. Meanwhile, there were other things that were open where I wasn't even able to recreate the bug. And there are also some issues that should be in the web app instead of the android application. I wasn't able to find any issue currently, out of the ones available, to start working on. If I missed one of them that can be done right now, before being implemented on the web app, please let me know. |
What type of PR is this? (check all applicable)
Description
Instead of implementing swipe to refresh, the web view refreshes on its own. Here is how it works:
WebViewClientreceives an errorBroadcastReceiver, which checks if the user is back online on connectivity change.WebViewis reloaded and theBroadcastReceiveris stopped.I took into consideration the work leaks. Everything was unregistered (
BroadcastReceiver) or canceled (Coroutines). Also, nothing runs on the main thread, except theview.reloadbecause it is interacting with theWebView.It is important to note that the webview client is not automatically registered to the Event. This is because we want to avoid leaks. Therefore, whenever it is manually registered, it should be manually unregistered.
Related Tickets & Documents
This resolves issue #76
Screenshots/Recordings (if there are UI changes)
There are no UI changes.
[optional] What gif best describes this PR or how it makes you feel?