🏛️ 03 · learn android
MVVM Architecture
Unidirectional data flow in a UI
The View observes state; the ViewModel owns it; the repository hides the data.
MVVM — Model-View-ViewModel — is a way of structuring a screen so the rules of the UI are testable without a device, and the View is reduced to rendering. It's one of a family (MVP, MVI, MVVM) that all solve the same problem: if the interesting logic lives inside an Activity, it can't be tested except on an emulator, and it entangles business rules with Android framework code.
The core discipline is one direction of travel: the View observes state and dispatches events; it never reaches past the ViewModel to the data layer. The ViewModel holds all screen state and survives configuration changes. The repository hides where data comes from. Dependency injection wires the graph so nothing constructs its own collaborators.
The mental model
How it fits together
Unidirectional data flow
↓
↓
↓
the View never reaches past the ViewModel
Dependency injection
nothing constructs its own collaborators
Key concepts
The ideas to internalise
Unidirectional data flow
View → ViewModel (intent), ViewModel → View (immutable state), ViewModel → Model (repository). The View never calls the Model directly.
ViewModel
A screen's state holder. Survives rotation because the framework holds it across Activity recreation. No View reference — which is what makes it testable.
UiState
A sealed class (Loading / Success / Error) exposed as a StateFlow, so the UI can't render a state the data can't actually be in.
Repository
The single source of truth the ViewModel calls. It hides whether data comes from network, database, or cache.
Dependency injection
Dagger modules declare how to build deps; components declare where they're available. The ViewModel is given its repository rather than instantiating it.
StateFlow
The View collects a StateFlow<UiState> and re-renders on every emission. State is immutable and conflated — no partial-update bugs.
Example index
6 runnable examples
Each is a self-contained Activity + ViewModel pair you can open, read, and run.
- 01data/modelArticle, Source, TopHeadlinesResponse
- 02data/apithe Retrofit NetworkService interface
- 03data/repositoryTopHeadlineRepository — the single source of truth
- 04diDagger modules, components, qualifiers, scopes
- 05ui/baseUiState + ViewModelProviderFactory
- 06ui/topheadlinethe Activity, ViewModel, and Adapter
The takeaway
The rule that makes MVVM work: the View never talks to the data layer directly. It only talks to the ViewModel, which exposes immutable UiState. Dagger wires the dependencies together so nothing constructs its own collaborators — and a ViewModel that can't be given a fake repository can't be tested, which guts the reason MVVM exists.