◆ Sparround

MVC vs MVP vs MVVM vs MVI

All these patterns share one goal: separating UI from business logic so code is testable and resilient to change. They differ in how UI and logic communicate.

  • MVC — a Controller processes input and updates the Model. On Android, classic MVC degenerated into "everything in the Activity" — hence rarely used.
  • MVP — the Presenter talks to a View interface (view.showBalance(...)). The View is passive. Problems: an interface pair per screen, manual Presenter lifecycle management.
  • MVVM — the ViewModel exposes a state stream (StateFlow/LiveData) the View subscribes to. The ViewModel does not know the View — the link is one-way. Android's official recommendation.
  • MVI — a stricter MVVM: one immutable state, everything from the UI is an Intent/Event, state changes happen only in a reducer. Unidirectional Data Flow (UDF) completes the loop.
CriterionMVPMVVMMVI
Link to UITwo-way (interface calls)One-way (state stream)Full loop: Intent → State → UI
Where state livesScattered across Presenter + ViewIn the ViewModel (may be several streams)A single immutable state object
WeaknessBoilerplate, manual lifecycleState can fragment across streamsLearning curve, overkill for small screens

The depth interviews expect: not listing patterns but explaining why the transitions happened. MVP → MVVM: the ViewModel's lifecycle is managed by Jetpack and it holds no view reference, eliminating leaks. MVVM → MVI: state coming from a single source of truth removes races and "half the screen is stale" bugs.

🛠 Practice task

Describe one screen in three styles on paper (or in code): MVP, MVVM, MVI.

  • For each, draw the path of a "button pressed" event with arrows.
  • Turn the MVVM version into real code: a single UiState data class + StateFlow.
  • Then give the same ViewModel an MVI shape: a sealed interface Event + onEvent(event).

Done when: you can give a concrete reason for when you would not choose MVI.

📚 Sources and documentation