You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When i am on a real unresponsive, slow internet network connection (2G) and i hit the button to mark an article as read, the UI is frozen until the article is marked as read. In the meantime Android system suggests to wait or close the app. If you wait, some more seconds later the article is marked as read and you can go on using the app.
Is there any improvement in this issue when #621 is implemented?
The text was updated successfully, but these errors were encountered:
Strubbl
changed the title
Mark article as read action is blocking UI
On slow internet, Mark article as read action is blocking UI
Mar 11, 2018
I can't remember all the details now, but some operations are mutually-exclusive in terms of DB access, so in some cases actions stuck waiting for the previous operation to complete. I think the article lists should load regardless of other operations, but it is the "mark as read" action that is stuck (maybe there is a sync in the background). So the test case should be something like that:
Start sync on a slow network.
Open an article.
Perform some modifying action ("mark as read", "favorite", "delete", etc.).
Result: the UI is stuck. More precisely, the ArticleReadActivity is waiting for the operation from step 3 to complete, the operation is waiting for the sync to complete.
The fix for that is a bit complex. Some long operations should probably be rewritten into a bunch of smaller ones ("article downloading", "queue sync"), some mutual exclusiveness should be checked and maybe eliminated (like "queue sync" should not block adding to local queue).
When i am on a real unresponsive, slow internet network connection (2G) and i hit the button to mark an article as read, the UI is frozen until the article is marked as read. In the meantime Android system suggests to wait or close the app. If you wait, some more seconds later the article is marked as read and you can go on using the app.
Is there any improvement in this issue when #621 is implemented?
The text was updated successfully, but these errors were encountered: