https://kotlinlang.org logo
#coroutines
Title
# coroutines
v

Vivek Sharma

02/02/2021, 5:33 PM
so when I use StateFlow, the consumer dont unregister when view is in STOPPED state, then this will consume more resources or something then why should we use stateflow instead of livedata? I cant understand the use of stateflow and below is snippet written in docs
j

jean

02/03/2021, 6:54 AM
lifeCycleScope
and
viewModelScope
will take take of unregistering when necessary for you : https://developer.android.com/topic/libraries/architecture/coroutines#lifecycle-aware
o

Orhan Tozan

02/03/2021, 2:34 PM
@jean not exactly. Instead of unregistering, it just suspends, so the producer is still active https://developer.android.com/kotlin/flow/stateflow-and-sharedflow:
Note: Using 
launchWhen()
 functions from the Lifecycle Kotlin extensions to collect a flow from the UI layer is not always safe. When the view goes to the background, the coroutine suspends, leaving the underlying producer active and potentially emitting values that the view doesn't consume. This behavior could waste CPU and memory resources.
*`StateFlow`*s are safe to collect using the 
launchWhen()
 functions since they're scoped to *`ViewModel`*s, making them remain in memory when the 
View
 goes to the background, and they do lightweight work by just notifying the 
View
 about UI states. However, the problem might come with other producers that do more intensive work.
A way to combat this is always have a backed shared flow that collects while subscribed.
👍 2
j

jean

02/03/2021, 2:50 PM
thanks for pointing this out to me 🙂 what do you mean by having a backed shared flow?
o

Orhan Tozan

02/03/2021, 2:52 PM
Instead of
Copy code
val users: Flow<List<User>> = observeUsers()
its
Copy code
val users: Flow<List<User>> = observeUsers()
    .stateIn(viewModelScope, SharingStarted.WhileSubscribed(), emptyList())
v

Vivek Sharma

02/03/2021, 3:03 PM
@jean yeah lifecyclescope and vmscope, takes care of coroutines lifecycle defined in that scope, not of the consumer/observer of Stateflow, and thanks @Orhan Tozan
But I was asking like what is adv of stateflow over livedata
o

Orhan Tozan

02/03/2021, 3:05 PM
What the advantage of stateflow over livedata is, is that you have access to the Flow API, plus it's Android agnostic (Kotlin multiplatform). I think when your project is already using coroutines, you should reverse the question and ask yourself: what is the advantage of livedata over stateflow?
v

Vivek Sharma

02/03/2021, 3:09 PM
yeah, livedata is android framework-specific, flow API is not, this is a huge adv in things like KMM thanks, yeah I should ask what is adv of livedata over Stateflow 😅
j

John O'Reilly

02/03/2021, 3:10 PM
just to be aware that there are some subtleties still if using in Compose project https://johnoreilly.dev/posts/jetpack-compose-stateflow-livedata/
(though just to mention I haven't confirmed behaviour in recent compose updates.....I think this is something they were hoping to address...or at least provide mechanism whereby this behaviour could be adjusted)
j

jean

02/03/2021, 3:31 PM
is it possible to set a
SharingStarted
property on a state/shared flow declared like this
val state = Mutable[State/Shared]Flow(initialValue)
? I see the doc says
the problem might come with other producers that do more intensive work
what is intensive enough and does it mean it should be changed to a backed shared flow instead?
v

Vivek Sharma

02/03/2021, 3:33 PM
@John O'Reilly thank you for sharing, will try things in new compose updates
o

Orhan Tozan

02/03/2021, 3:37 PM
@jean what is intensive enough is up to you to decide. What the point essentially comes down to, is that, say you have a screen that is collecting a flow that fetches data every 5 seconds. Now let's say you navigate away from the app. The UI won't be notified anymore about the new flow emits, but the flow is still running and fetching every 5 seconds, despite the user isn't even on the screen
Since the lifescycle scope doesn't actually get canceled, it still is alive
j

jean

02/03/2021, 3:39 PM
yes I get that point 🙂 I’m just curious to know what would justify the change from one to the other.
3 Views