Wrong progress indicators with swipe/refresh in Bookmarks

[nikclayton]

Swiping to refresh in Bookmarks if they initially failed to load (e.g., poor network, or the server did not respond in time) shows both the "swipe to refresh" circular progress spinner, and the "loading content" progress spinner at the same time.

To reproduce:

1. Open Tusky
2. Enable airplane mode (to simulate poor network connection)
3. Open bookmarks. Observe the sad elephant
4. Disable airplane mode
5. Swipe down to refresh
6. Observe both progress spinners appear

@connyduck This is related to our discussion over in the Notifications PR. Which progress spinner should appear in this case? The swipe one, because the user has swiped, or the non-swipe one, because no content has been loaded yet?

---

• Tusky Version: 21

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[connyduck]

Ideally, swipe to refresh is disabled and there is a "retry" button. Upon clicking it, full progress bar appears. Lists view seems to have it right.

This whole error/retry/refresh thing should be consolidated everywhere, right now we have different behaviors all over the place. Different elephants are shown, sometimes with, sometimes without retry button, some lists have swipe to refresh, some don't.

[Lakoja]

I added a PR as a sort of discussion base.

I would say that everything (every list) should behave comparably.
(I guess from a code point that is everything that uses a MessageView.)

Meaning:

• Everything has swipe-to-refresh
• Everything has a retry button for failures
• The only progress indicator is the one from the SwipeRefreshLayout

The last one probably contradicts our efforts in the thread view (two linear progress bars instead).
So at least that one is open to debate.

All the touched locations in the PR are quite different list implementations.
So from a consistent code perspective the question would be: How to abstract that?
Is there for example something like traits in Kotlin?

[connyduck]

Treating thread view differently is reasonable though? It can load partially and some parts may be cached, we don't have that anywhere else.

Regarding the other Activities/Fragments that show refreshable lists and errors, yes they all have very different implementations, we should tackle that eventually. But for now unifying their behavior is a nice quick win that is also noticebale for users, so we should do that.

[Lakoja]

Treating thread view differently is reasonable though? It can load partially and some parts may be cached, we don't have that anywhere else.

I guess from a user's perspective they should still feel/be the same. (The user doesn't care that contents might be loaded differently here.)
Only in case of an error should there maybe be a respective hint: "This is cached, more couldn't be loaded" or similar.

[Lakoja]

This issue was actually not fixed by the PR.
The discussion here is still open: Which progress bar(s) to use?
The PR only made it (more) consistent throughout the code base.