Android Architecture Evolves Beyond ViewModel as Default State Holder
How Compose and Navigation 3 are redefining state management responsibilities
1ViewModel's Historical Role
For years, Android developers treated ViewModel as the default container for screen state. This approach ensured state survival through configuration changes and process death. Over time, ViewModels became responsible for everything from UI state to navigation, business logic, and repository coordination. While this centralized structure worked for the View system, modern Android development demands more nuanced approaches as the ecosystem evolves with new declarative frameworks like Jetpack Compose.
2Compose's Paradigm Shift
Jetpack Compose's most significant architectural contribution isn't a new API, but rather a fundamental question change. Instead of asking 'Where should I put this state?', we now ask 'Who naturally owns this state?'. Official guidance recommends keeping state closest to where it's consumed. This reverses years of automatically pushing every UI value into ViewModels. Compose facilitates proper state locality through remember and rememberSaveable functions, making it natural to keep UI state where it belongs.
3Rise of the State Holder Concept
Google no longer positions ViewModel as the sole state holder. Official documentation now presents ViewModel as one implementation of the broader state holder concept. State holders are categorized into business logic state holders and UI logic state holders. ViewModel is explicitly defined as a business logic state holder, while plain classes are recommended for UI element state (like text field values or dialog visibility). This distinction enables a more precise ownership model in application architecture.
4Navigation 3's Contribution
Navigation 3 continues this separation trend. Navigation arguments are now managed by NavKeys, while UI state is handled by destinations through rememberSerializable. ViewModels are relieved from remembering navigation state. In this new model, each navigation entry owns its related state. This change brings clearer responsibility definitions and simplifies ViewModel's role, making the architecture more maintainable and easier to reason about.
5ViewModel's New Role: State Producer
Modern ViewModels are increasingly becoming state producers rather than containers. They transform repository data streams into UI-consumable formats. Instead of serving as mutable state containers, they now primarily produce UI state. For example, they use combine operators to merge different repository flows into HomeUiState. This subtle but significant shift requires rethinking ViewModel's fundamental purpose in application architecture.
6Layered State Management
Modern Android architecture recommends keeping state as low as possible while maintaining proper ownership. Composables manage UI state, Navigation handles navigation state, ViewModels deal with presentation logic, and Repositories own persistent data. Each layer becomes responsible for the state it understands best. This separation creates a cleaner architecture where nothing exists simply because 'that's where we've always put it,' leading to more maintainable codebases.
7Resilience and State Recovery
Moving UI state out of ViewModels doesn't compromise application resilience. Instead, each layer uses mechanisms designed for its specific lifecycle. UI state leverages rememberSaveable and rememberSerializable, navigation uses NavKeys, and persistent data resides in repositories. This approach maintains protection against both configuration changes and process death while properly distributing state ownership to its natural locations.
8Philosophical Shift in Android Architecture
Compose and Navigation 3 aren't eliminating ViewModels but clarifying their responsibilities. UI state lives in UI, navigation state in Navigation, persistent data in repositories, and presentation logic in ViewModels. The most significant impact of this change is shifting developer mindset from 'How do I store this in ViewModel?' to 'Who naturally owns this state?'. This philosophical evolution represents Android architecture's maturation, leading to more sustainable and maintainable application designs.
Original article: ProAndroidDev - Medium — Android Mimarisinde ViewModel'ın Ötesine Geçiş