https://kotlinlang.org logo
Title
f

fatih

02/05/2020, 9:43 AM
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.
s

satyan

02/05/2020, 9:46 AM
https://developer.android.com/topic/libraries/architecture/viewmodel Just use a ViewModel which retains its data on configuration change. You would need a LiveData 🙈
f

fatih

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

satyan

02/05/2020, 9:50 AM
It’s still not going to retain it’s state on configuration change.
f

fatih

02/05/2020, 9:53 AM
Then can we say we should not use Flow in View layer?
If you dont have a cache in repository layer?
s

satyan

02/05/2020, 9:55 AM
You could use it, but it’s not going to retain its state if you don’t save it somewhere which survive configuration change.
👍 1
k

kevin.cianfarini

02/06/2020, 4:26 AM
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) }
}
...nevermind. ViewModels survive configuration change. Womp
z

zak.taccardi

02/06/2020, 5:28 PM
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
👍 1