UPDATE: I have provided a better Example in the thread. My issue was how to merge a “manual” mutable flow with external sources. Original Question: How can i avoid declaring initialValue twice for StateFlow if i want a private

MutableStateFlow

for updating and a public

StateFlow

that uses

.stateIn()

Example:

class ExampleViewModel: ViewModel() {
    private val _state = MutableStateFlow<Int>(0) // Set initial value
    
    val state: StateFlow<Int> = _state
        .stateIn(
            scope = ...,
            started = ...,
            initialValue = 0 // Have to duplicate initial value :(
        )
    
    fun onSomeAction() {
        _state.getAndUpdate { lastState -> lastState + 1 }
    }
}

Why do you use

stateIn

here?

because i want the StateFlow to stay alive for the 5s if collector disconnects and needs to reconnect (i.e. activity recreates during config change). In Google’s NowInAndroid app, they use stateIn as well here:

combine(<ExternalFlows>) {
   ...
}.stateIn(
    scope = viewModelScope,
    started = SharingStarted.WhileSubscribed(5_000),
    initialValue = AuthorScreenUiState(AuthorUiState.Loading, ...)
)

But you only need to control this lifetime because you start a coroutine. In the example you gave, there are transformations on other flows that are collected into the state flow. In your case, you already have an eternal state flow, no need for a coroutine

So for my learning can you verify if i concluded this right: • A) I should use

.stateIn()

for consuming cold flows into a StateFlow in the case i want those cold flows to stay active depending on the subscriber sharing behavior i defined? • B) If the ViewModel is the creator of a MutableStateFlow, i dont need to use .stateIn() since that mutable stateFlow is already hot and will stay alive for the lifecycle of the ViewModel, regardless if theres no collectors

A) yes, in a way. To be clear, a state flow is really just a flow that has a state inside. If you want to turn cold flows into a state flow, you have to start a coroutine that consumes the cold flows and updates the state of the state flow, hence why

stateIn

needs a scope - to start this coroutine behind the scenes. And it's also why you define a policy to keep this coroutine alive or cancel it. If you create a mutable state flow directly, you just created some sort of observable state variable. It doesn't need any coroutine on its own, because the state will be updated by other pieces of code (they may use coroutines themselves, but they don't need to because state flows have a

state

property that can be updated without suspending). B) true

Wow! super helpful Joffrey 🙂 So given your feedback, is this init{} block doing what you are describing:

class ExampleViewModel(externalIntFlow: Flow<Int>): ViewModel() {

    data class State(val msg: String, val isLoading: Boolean = false)

    private val _state = MutableStateFlow(State("Empty"))
    val state = _state.asStateFlow()
    
    init {
        viewModelScope.launch { 
            externalIntFlow.map { action ->
                when (action) {
                    1 -> State("One")
                    else -> State("?")
                }
            }.also { _state.emitAll(it) }
        }
    }
    
    fun someAction() = viewModelScope.launch {
        _state.getAndUpdate { it.copy(isLoading = false) }
        delay(1000)
        _state.update { State("Success") }
    }
}

Yes exactly

if all you want to do is expose a non-mutable state flow to consumers,

private val _state = MutableStateFlow<Int>(0)
val state: StateFlow<Int>
    get() = _state.asStateFlow()

That's exactly what OP did in the last snippet (the main issue was merging that "manual" mutable flow with external sources)