Should You Use Compose State or StateFlow in Your ViewModels?

Summary

In this video, the speaker discusses the pros and cons of using `StateFlow` versus `ComposeState` for managing UI state in Jetpack Compose. While both approaches are functional, the speaker recommends using `StateFlow` in the view model due to its flexibility, ability to handle lifecycle changes, and support for flow operators like `map` and `filter`. Additionally, `StateFlow` allows for better state persistence across process death and keeps the view model separate from Compose, making it more reusable. Overall, `StateFlow` is presented as the more scalable and robust option for state management in Android projects.

Takeaways

• 😀 Using StateFlow in the ViewModel provides more flexibility for transforming state using Kotlin flow operators like map and filter.
• 😀 Compose State is simpler to use initially but lacks the powerful features of StateFlow, especially when dealing with derived or transformed states.
• 😀 StateFlow helps manage state across different lifecycle changes and helps persist state across process death using SavedStateHandle.
• 😀 The use of Compose's built-in State management is less boilerplate but doesn't support flow operators, which limits its use in complex scenarios.
• 😀 By using StateFlow, the ViewModel remains free from Compose-specific code, making it more reusable in other contexts or platforms (e.g., KMM).
• 😀 Using StateFlow and SavedStateHandle together ensures that state survives process death, meaning when the app is killed and reopened, the state can be restored.
• 😀 Compose State does not offer a way to persist state through process death easily, requiring additional work to restore its value.
• 😀 If you use StateFlow, the process of managing state changes is more declarative and clear, with automatic lifecycle handling.
• 😀 You can use StateFlow for advanced use cases like transforming or combining states, while Compose State is more suited for simple state management.
• 😀 The speaker recommends using StateFlow over Compose State for its enhanced flexibility, robustness, and ease of managing complex scenarios like process death and state transformation.
• 😀 Despite the recommendation, Compose State can still be useful for simpler projects, but it's important to consider the limitations when building more complex apps.

Q & A

What is the primary focus of the video?

The video discusses how to manage UI state in Jetpack Compose, comparing the use of Compose's native state management versus `StateFlow` in a ViewModel. The speaker highlights the advantages and disadvantages of each approach and provides a clear recommendation.

What is the difference between Compose's native state management and `StateFlow`?

Compose's native state management uses `mutableStateOf` to directly manage UI state, while `StateFlow` is a reactive stream used to manage state in a ViewModel. `StateFlow` offers more advanced features, like using Flow operators and handling process death more effectively.

Why does the speaker recommend using `StateFlow` in the ViewModel?

The speaker recommends using `StateFlow` because it provides more flexibility, allows for the use of Flow operators (like `map`, `filter`, and `combine`), and integrates better with Android’s process death handling. Additionally, it keeps the ViewModel Compose-free, making it more reusable.

What are some Flow operators that can be used with `StateFlow`?

Flow operators that can be used with `StateFlow` include `map`, `filter`, and `combine`. These operators help to transform and derive new state from the existing state, offering more advanced state management capabilities.

What issue does `StateFlow` help address related to process death?

When an app is killed due to system constraints (process death), the state is usually lost. `StateFlow` with `SavedStateHandle` allows the state to persist and be restored, preventing the UI from resetting and providing a seamless experience for the user.

What is the role of `SavedStateHandle` in managing process death?

`SavedStateHandle` is used to store state data that needs to survive process death. It integrates with `StateFlow` to save and restore UI state across app sessions, ensuring that the app's state remains consistent even if the app is terminated by the system.

Why is Compose’s state management less preferable than `StateFlow` in certain situations?

Compose's native state management lacks the advanced features that `StateFlow` offers, such as Flow operators for state transformation and handling process death efficiently. Additionally, Compose's state management directly couples the ViewModel with Compose, making it less reusable in non-Compose projects.

How does `StateFlow` enable reusability in ViewModels?

By using `StateFlow`, the ViewModel is kept free of Compose-specific code, making it more reusable in different contexts. This is particularly useful if the ViewModel needs to be shared across platforms, like Android and iOS using Kotlin Multiplatform (KMM), where Compose is not supported.

What is the downside of using Compose's native state management when dealing with `SavedStateHandle`?

When using Compose's native state management with `SavedStateHandle`, there are extra steps required to manage state restoration. You need to manually handle the assignment of default values and updates to both the Compose state and the `SavedStateHandle`, which can result in more code and complexity.

How does `StateFlow` simplify the handling of state restoration after process death?

With `StateFlow`, the restoration of state after process death is simplified. By using `SavedStateHandle`, state changes are automatically stored and restored when the app is reopened, without needing to update multiple state variables, as is necessary when using Compose’s native state management.