IssueTracker

Component used: lifecycle-viewmodel-savedstate

Version used: 2.5.0-rc01

Description

Recently, SavedStateHandle has added support for StateFlow as a coroutines-based alternative to its LiveData support. However, the new API has a design decision that is significantly more fragile by comparison. First, let’s clarify the main difference:

• LiveData exposes a MutableLiveData.
• StateFlow exposes a non-mutable StateFlow.

Now, a simple example can illustrate how code using these APIs would look:

// LiveData
internal class MyViewModel(
    handle: SavedStateHandle // no need to keep a reference to handle
): ViewModel {

    private val _email: MutableLiveData<String> = handle.getLiveData("email") // only one access point
    val email: LiveData<String> get() = _email

    fun onEmailChange(email: String) {
        _email.value = email // we can safely change the email without risk of key/type mismatch
    }
}

// StateFlow
private const val KEY_EMAIL = "email" // requires tracking keys

internal class MyViewModel(
    private val handle: SavedStateHandle  // needs a strong reference to the handle
): ViewModel {

    val emailFlow: StateFlow<String> = handle.getStateFlow(KEY_EMAIL)

    fun onEmailChange(email: String) {
        // As you can see below, now a key and/or type mismatch could cause problems.
        // Besides that, the API is unnecessarily verbose for a simple case.
        handle.set(KEY_EMAIL, email)
    }
}

From the examples above, consider what might happen if:

• set receives the wrong type for the StateFlow.
• We have 2 StateFlows, and we use the wrong keys in the set call.

This brings us to the drawbacks of forcing the StateFlow/manual set API:

1. The API is less safe. It allows us to retrieve a StateFlow of one type and call set with a different type. There is zero type safety between keys and/or type between set and the StateFlow.
2. The key must be tracked in every place a set call occurs.
3. The API is unnecessarily verbose, removing the ability to create a single point of change (StateFlow).
4. Most importantly, the more we use this API in a ViewModel, the more keys and types we need to track, increasing its error-proneness.

Ideally, calling emailFlow.value = newValue should work exactly like calling set directly on a SavedStateHandle. This would eliminate the above side effects while maintaining API consistency with LiveData.

My proposal is to expose StateFlow as MutableStateFlow to match the LiveData implementation, which would allow us to write more streamlined code:

internal class MyViewModel(
    handle: SavedStateHandle // no need to keep a reference to handle
): ViewModel {

    private val _email: MutableStateFlow<String> = handle.getStateFlow("email") // only one access point
    val email get() = _email.asStateFlow()

    fun onEmailChange(email: String) {
        _email.value = email // we can safely change the email without risk of key/type mismatch
    }
}

For context: Although the example is a simplified version of real-world scenarios, the struggle comes from using the new API in a real (closed source) codebase. We ended up creating our own extension function to handle it better, but this requires us to maintain a synchronization mechanism between two StateFlows, which is far from ideal.