Is the `liveData` coroutine builder suited for ret...

# android

[Michael Friend]

Is the liveData coroutine builder suited for retrying/refreshing data loads or does everyone typically avoid it when you need that functionality? I’ve started using it recently to lazily load data when needed by the UI, but i cant come up with a clean way of using liveData while also being able to refresh the data (i.e. when coming back to the screen) or retry failed operations. Typically my ViewModels look something like:

val data: LiveData<State<MyData>> = liveData {
    emit(Loading)
    try {
        emit(getData())
    catch (e: SomeEx) {
        emit(Error(e))
    }
}
suspend fun getData(): MyData {...}

But with this i have no way of actually retrying the operation and emitting to the LiveData again if it fails. And in the cases i need to update the data on user events like a refresh button or returning to the screen I’m stuck with the stale data.

[Michael Friend]

I know ideally I can get a flow of data to receive updates when the data changes which solves the issue of getting fresh data when the screen loads, but thats not an option atm and it also doesnt seem to solve the retry case

[okarm]

If you require using LiveData, I'd experiment with a setup similar to the following:

private val performLoad = MutableLiveData(Unit)
val data: LiveData<State<MyData>> = performLoad.switchMap {
    liveData {
        emit(Loading)
        try {
            emit(getData())
        catch (e: SomeEx) {
            emit(Error(e))
        }
    }
}
suspend fun getData(): MyData {...}

fun performLoad() = performLoad.postValue(Unit)

[Michael Friend]

By “if you require using LiveData is there something you had in mind that can be done with Flow or something else? Or are you referring to the liveData coroutine builder?

[okarm]

Yeah, LiveData type. It's just a philosophical question - Lately I migrated away from LiveData, especially in deeper layers behind a ViewModel. I don't like coupling domain with Android libraries. Google recognizes the limitations of LiveData, so they started pushing Flow instead of LiveData as well.

But the pattern would be very similar with all other options. Observe some sort of separate command channel/livedata/flow and flatmap/switchmap to produce a fresh flow/livedata each time a command is received.

[Michael Friend]

I see, I considered a similar pattern but was hoping for something that felt a little simpler without the need for another LiveData. And to make sure data reloads when coming back to the screen would you just mark performLoad() as @OnResume to observe the lifecycle of the fragment?