I have a Flow that's collected in my ViewModel. The Flow is actually from firestore which notifies me of updates. In my VM I update my snapshot state with the result of that Flow. My composable updates correctly. Life is good. But when I leave my app... the Flowable keeps on listening to updates. How do I do stop listening to my Flow once the app is backgrounded. It seems like it'd be easier if my flow was collected in the Composable, but there has to be a way to do this while collecting in my VM... right? Short example in thread

Doesn't that force me to collect in my Composable vs collecting in my VM?

If you want collection to only be happening when your UI is present, then collecting in the ViewModel was always the wrong thing to be doing

you can have your viewmodel's flow stop collecting from firestore when the UI unsubscribes. That's also mentioned in the article linked above, so you can continue subscribing to the repository on your viewmodel, while stopping when the app is backgrounded

So exposing a

State

from the VM is a "bad" thing? Because in such way Composable cannot "unsubsribe" from it?

One idea is that you could expose that subscription to the UI so that it decides when this collection is happening. Remove the

init

block and expose it as something that the UI can subscribe to

class MyViewModel(
  val myFlow: Flow<Int> = flow {
    while (currentCoroutineContext().isActive) {
      delay(1000)
      emit(1)
    }
  },
) : ViewModel() {
  var myState by mutableStateOf(0)
  fun subscribeToFirestoreChanges(): Flow<Unit> {
    return flow {
      myFlow.collect {
        myState = myState.plus(it)
      }
    }
  }
}

Then on the UI simply turn the subscription on with the safe

repeatOnLifecycle

and decide on which state you want it to be on from (in this case

Lifecycle.State.STARTED

)

fun MyComposable(viewModel: MyViewModel) {
  val lifecycleOwner = LocalLifecycleOwner.current
  LaunchedEffect(viewModel, lifecycleOwner) {
    lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
      viewModel.subscribeToFirestoreChanges().collect()
    }
  }
  val text = viewModel.myState
}

Not sure if there are any problems with such an approach. I’ve done it once here and here since my

subscribeToAuthResultUseCase

was fetching for a status update every 1 second and only wanted that to happen while on screen. And this worked just fine for this use case👌

If you want collection to only be happening when your UI is present, then collecting in the ViewModel was always the wrong thing to be doing

Hm. Then I probably never want to be calling collect{} in a VM as I can't think of any reason when I want to be collecting something even when I'm not on the screen. I wonder if I can write a lint rule to prevent me from making this mistake.

there is nothing wrong with

collect

in the viewmodel, the business logic belongs there and the UI layer should not be talking to your data layer. What needs to happen is for your viewmodel to be aware when the UI is no longer collecting the state so that it can unsubscribe its own collectors

Hm. Yeah I'm trying to think of a convenient way to do that.

you can use

stateIn

in your viewmodel to expose the UI state, and have it active only while subscribed, with an optional timeout (for configuration changes, for instance), so that it has a grace period before it disconnects

Using

stateIn

would work with a

Flow

not with

State<T>

which I guess is not what Colton is going for. The new

collectStateWithLifecycle

API works when collecting a Flow not when you got compose State in your ViewModel afaik. I was trying to help for this specific case. Personally I also try to expose everything as a Flow anyway with

stateIn

in order to get this functionality for free. But it’s true that I haven’t managed to get that working for all the cases I’ve encountered.

another option is to use a disposable effect to start/stop the collection,

DisposableEffect(key1 = viewModel) {
    viewModel.onStart()
    onDispose { viewModel.onStop() }
}

this is a more manual approach but it would allow you to start/stop the collection when the composable enters/exits the composition

Definitely interesting to think about it that way since android lifecycles wont be there on desktop for example.

shameless self promo: https://medium.com/nerd-for-tech/handling-lifecycle-events-on-jetpack-compose-f4f53de41f0a

I will try a couple of these approaches out. I think overall I have to change my thinking a bit BUT in the meantime I would be fine with a quick and dirty implementation so that im not using a ton of data when the user isn't even looking at the screen.

The flows will in fact cancel if you don't keep it alive for that time in-between the rotation unless you either use stateIn as you said. If I understand it correctly, doing this https://kotlinlang.slack.com/archives/CJLTWPH7S/p1618760581089700?thread_ts=1618691113.058800&cid=CJLTWPH7S may also make it so that the UI will not stop listening if you only do a rotation.

Gotcha. Okay so at least that part works as I imagined. and yeah, opting out of config changes is on my plate to do at some point. I do like to treat it as a quickway totest config changes (like wallpaper changes) which you can't opt out of.

why not apply

stateIn

to your

myFlow

? that would achieve the same result without the wrapper flow if you used "while subscribed"

Uhm. Not sure how that would look/work. Let me try?!

you can add to your flow

onEach { myState = myState.plus(it) }

Not sure I'm following anymore. How would I "apply

stateIn

to your

myFlow

?"

collecting one flow for the side effect on another flow - I don't like that at all

I agree that it looks a bit smelly, but I'm failing to see how else I'd do this.

If you're going to collect a Flow in the UI anyways, just collect the actual flow and skip the roundabout through State

I had this in mind

val myFlow = flow {
    while (true) {
      delay(1000)
      emit(1)
    }
  }
  .onEach { /* TODO */ }
  .stateIn(...)

@Ian Lake I agree and it looks that way in this example, but I guess throughout my application I have a bunch of other flows that are doing way more complex things... which results in some state being updated which my composables use. That's why I don't feel like just dumping all of that logic into the composable makes sense.

onEach

is another way to collect your flow, when you use

launchIn

scope.launch { flow.collect { ... } }

==

flow.onEach { ... }.launchIn(scope)

to be clear

I've always avoided onEach (like I said, for rx java reasons) so thanks for highlighting that!

or

.collect { ... }

==

.onEach { ... }.collect()

and

scope.launch { .collect() }

==

.launchIn(scope)

, but you almost never see the parameterless

.collect()

Alright. Thanks everyone. I have ended up with this! VM:

var myState by mutableStateOf(0)

val myFlow = flow {
  while (true) {
    delay(1000)
    emit(1)
  }
}.onEach { myState = myState.plus(it) }
 .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), Unit)

Composable screen:

vm.myFlow.collectAsStateWithLifecycle(initialValue = Unit)

The only thing that I'm not in absolute love with is the fact that I have two initial values declared, once as the 3rd arg stateIn and another as the arg in collectAsStateWithLifecycle. No wrapper flows or anything!

your VM flow is a

StateFlow

, you don't need to define another init value in your composable if you expose it as a

StateFlow

your VM flow is a

StateFlow

, you don't need to define another init value in your composable if you expose it as a

StateFlow

oh. neat

flatmapLatest expects a flow, I guess your method is a suspending function instead, in which case map is correct

So much to learn. Thanks again for teaching!