Rethink UI of history refresh not to occlude the view

[teolemon]

What

• Rethink UI of history refresh not to occlude the view

Expected behavior

• Refresh should not block you from interacting with the app

Part of

• 🎯 What can I work on ? #525

Screenshot/Mockup/Before-After

[teolemon]

Notice the double spinner

[teolemon]

[monsieurtanuki]

@teolemon There's no technical issue about removing the dialog.

Regarding UX, what should happen?

• just a 3-second snackbar that says "Refreshing the data..."
• no way to stop the refresh?
• no way to prevent the user from refreshing while another refresh is pending?

[teolemon]

Probably a persistent snackbar at the top of the refreshing list, with a link to stop the refresh, and ignoring pull to refresh until a/ refresh is complete b/cancel is pressed
WDYT?

[monsieurtanuki]

Let's say we're talking about refreshing a product list - as opposed to refreshing a product.

The goal of this issue is to add the ability to do whatever while the list is refreshed, for instance:

• click on an item
• go back / go to another list
• go to the preferences

The question behind is: "how do I know if a product list is being refreshed?".

1. it's easy if you remain on the list page - but that doesn't solve the issue
2. it is probably easy if you click on items then go back to the list page - the list page widget remains, hidden, with its call to a Future
3. it is more problematic if you go back to the home page then go back to the same list page - the list page widget was disposed and a new one was created - in that case we need to somehow store the fact that this new list page is being refreshed

A solution would be to maintain a sort of static Set<String> where we put the list "key" when we refresh it (and remove when we're done or if it failed).

As for the UI, I would put a CircularProgressIndicator in the AppBar, but it's a matter of taste.