What is the best way to handle `Flow` on device rotation in Android if you are only using `Flow` (wi...

# coroutines

[fatih]

What is the best way to handle Flow on device rotation in Android if you are only using Flow (without LiveData)? I see that Dropbox Store library caches the latest and provides when it is requested again. https://github.com/dropbox/Store

The first time you call to suspend store.get(key), the response will be stored in an in-memory cache and in the persister, if provided. All subsequent calls to store.get(key) with the same Key will retrieve the cached version of the data, minimizing unnecessary data calls.

Since the Flow is cold it is going to be collected evertime.

[satyan]

https://developer.android.com/topic/libraries/architecture/viewmodel

Just use a ViewModel which retains its data on configuration change.

You would need a LiveData 🙈

[fatih]

Is it the only way ? 😞 I know that there is a DataFlow (or StateFlow) draft -> https://github.com/Kotlin/kotlinx.coroutines/pull/1354

[satyan]

It’s still not going to retain it’s state on configuration change.

[fatih]

Then can we say we should not use Flow in View layer?

[fatih]

If you dont have a cache in repository layer?

[satyan]

You could use it, but it’s not going to retain its state if you don’t save it somewhere which survive configuration change.

[kevin.cianfarini]

You could used savedstatehandle for view models.

https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate

val statefulFlow = flow {
    emit(savedState.get(...))
    actualFlow.collect { emit(it) }
}

[kevin.cianfarini]

...nevermind. ViewModels survive configuration change. Womp

[zak.taccardi]

Your Flow<T> should be backed by a ConflatedBroadcastChannel<T> until StateFlow<T> arrives in the next coroutines version. ConflatedBroadcastChannel<T> behaves quite similarly to LiveData<T> without the main thread limitation