I found the answer in the official docs and sample.
Here are 2 parts:
- How to feedback the progress using LiveData
- How to render the progress on UI
1)The answer is found at the end of Guide to app architecture
Scroll down to the "Addendum: exposing network status" topic.
They suggest to use some LiveData wrapper based on the MediatorLiveData
There is a lot of boilerplate code you have to write and maintain wrapping any of your LiveData which needs to track the progress or loading errors.
2)In the sample Android Architecture Components Basic Sample
you can find the suggested approach how to feedback the loading process on UI.
This sample is really basic so they just hide the UI widgets while the loading is going.
Each fragment layout should have some progress support stuff. Here we have just the variable:
<data>
<variable
name="isLoading"
type="boolean" />
</data>
And each widget(view) we want to hide during the loading process should have the attribute:
app:visibleGone="@{isLoading}"
Since it is the app defined attribute we must take care on it somewhere. So there should be adapter to support visibleGone:
public class BindingAdapters {
@BindingAdapter("visibleGone")
public static void showHide(View view, boolean show) {
view.setVisibility(show ? View.VISIBLE : View.GONE);
}
}
Of course we can use something like FrameLayout and put some progress panel which will obscure our controls and show some rolling progress wheel(instead of simple hiding it and showing the empty screen).
But the problem is you have to take care on it for each your fragment layout. And if you have some complicated screens(e.g. Tabs) it just could complicate your code even more.
Conclusion: #2 is more or less workable solution. Although I would prefer some separate progress fragment screen for all cases and do not bloat up each of my fragment layouts with the loading progress and error handling stuff.
But #1 make me ask what is the real benefit of using the LiveData? To do things right with a good error handling, progress feedback we need to maintain too much boilerplate code.
They claim right at the own guide:
In the recommended app architecture section above, we omitted network
error and loading states to keep the code snippets simple.
Because it seems the design of LiveData is not intended for easy progress and errors handling.