Hi, what advantages would I have when I collect a flow directly in composable function instead of collecting it in view model? And when would I prefer one over the other?

by, "in view model" you mean using

myViewModel.viewModelScope

? Collecting a flow in a composable function will have a much narrower scope, it will start collecting when that composable enters the composition and stop collecting when it leaves. `viewModelScope`s live much longer and will leave the flow collecting and potentially performing work when nothing needs it.

@Adam Powell if we implement any device connection (via USB, Bluetooth, Ethernet) is it a good decision to create connect function returning flow of connection state (Connecting, Connected, Disconnected)?

this is getting a bit more into general flow design 🙂

Thanks for your answer.

by, "in view model" you mean using myViewModel.viewModelScope ?

yes, to be more concrete I mean doing sth. like this:

private val _state: MutableStateFlow<ConnectBluetoothDeviceUseCase.BluetoothConnectState> =
        MutableStateFlow(
            ConnectBluetoothDeviceUseCase.BluetoothConnectState.Loading
        )

    fun connect(device: BluetoothDevice) {
        viewModelScope.launch {
            connectBluetoothDevicesUseCase.connect(device).collect { connectState ->
                _state.value = connectState
            }
        }
    }

@rsktash We have the same intention. @Adam Powell I was wondering if I should avoid collecting the state that comes from my

ConnectionUseCase

then updating the

StateFlow

in favor of collecting it directly in composable. Would it be a better solution?

lots of hot/cold, factory vs. single connection state management questions in here

There will be only one connection at time in my case. Before calling the connect function I naviagte to a new screen so I don't have to worry about multiple connections and device switching. When I leave the new screen, the connection is closed

@Lilly there you are passing device which means one state for many device connection. I think it will be right decision to return state flow via connect function

If more than one thing wants to know the connection state of the same connection, how do those other collectors gain access to it?

@Adam Powell I will have only one subscriber. It's jsut the question where to collect the flow. The possible states would be Loading, Success or Failure,

if it's a hot flow updated as a side effect of the connection itself, and the connection is managed elsewhere anyway, it doesn't particularly matter where you collect a flow of just the connected/disconnected state. I might even skip pushing that into a StateFlow entirely and just change a

mutableStateOf

instead, if the primary consumer of that information is your compose ui

There is also a shared flow where you can decide to emit or not, connect or disconnect via collecting subscriptionCount

Good point. What is the difference between between

mutableStateOf

and

StateFlow

. They both have the same behavior not? -> to notify ui on changes

if you're doing the

private val _foo = MutableStateFlow<Type>(...)
val foo: StateFlow<Type> get() = _foo

thing and you're just setting

_foo.value = newValue

as things happen, that translates pretty directly to

var foo by mutableStateOf<Type>(...)
  private set

and is generally nicer to work with. And if some other code outside of a composable function wants to observe changes to it, it can use

snapshotFlow { myObject.foo }

and collect that. Composable functions can just refer to

foo

directly and the change observation happens automatically.

Alright, thank you very much