MVVM

The Problem with Tight Coupling

In a naive Android Activity, UI logic, business rules, and data fetching all live in the same class. This creates a "God Activity" that is hard to test, hard to modify, and breaks the moment requirements change. MVVM solves this by splitting responsibilities into three layers.

Model-View-ViewModel

• Model: Holds your business data and rules. It knows nothing about the UI. A UserRepository returning user profiles is part of the Model layer.
• View: The Activity, Fragment, or Composable that renders UI. It observes the ViewModel and renders whatever state it exposes. The View never calls the Model directly.
• ViewModel: The bridge. It holds UI-related state, transforms Model data into something the View can render, and survives configuration changes like screen rotations.

The critical rule: data flows one direction. The View reads from the ViewModel. The ViewModel reads from the Model. The View never modifies the Model directly — it sends user intent to the ViewModel, which updates the Model, which produces new state, which the View observes.

Kotlin Code Example

// Model layer
data class User(val id: String, val name: String, val email: String)

class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User {
        return api.fetchUser(id)
    }
}

// ViewModel layer
class UserViewModel(private val repository: UserRepository) : ViewModel() {
    private val _uiState = MutableStateFlow<UiState>(UiState.Loading)
    val uiState: StateFlow<UiState> = _uiState.asStateFlow()

    fun loadUser(id: String) {
        viewModelScope.launch {
            _uiState.value = UiState.Loading
            try {
                val user = repository.getUser(id)
                _uiState.value = UiState.Success(user)
            } catch (e: Exception) {
                _uiState.value = UiState.Error(e.message ?: "Unknown error")
            }
        }
    }
}

sealed class UiState {
    object Loading : UiState()
    data class Success(val user: User) : UiState()
    data class Error(val message: String) : UiState()
}

The Activity only observes uiState and renders the appropriate UI. It has zero knowledge of where the user data comes from.

Why One Direction?

Bidirectional data flow creates debugging nightmares. When the View writes to the ViewModel and the ViewModel writes to the View, tracking a bug means following state mutations across multiple classes. Unidirectional flow means state changes happen in one place — the ViewModel — and the View simply observes.

The Data Flow Cycle

1. User taps a button → View calls a ViewModel method
2. ViewModel processes intent → Calls repository or business logic
3. Model produces new data → ViewModel wraps it in a state class
4. ViewModel emits new state → View observes and re-renders

Common State Patterns

// Using sealed class for all possible UI states
sealed interface HomeUiState {
    data object Loading : HomeUiState
    data class Loaded(val items: List<Item>) : HomeUiState
    data class Error(val reason: String) : HomeUiState
}

// Single source of truth for screen state
data class ProfileUiState(
    val userName: String = "",
    val isLoading: Boolean = false,
    val avatarUrl: String? = null,
    val isEditing: Boolean = false
)

// ViewModel updates the entire state object
class ProfileViewModel : ViewModel() {
    private val _state = MutableStateFlow(ProfileUiState())
    val state: StateFlow<ProfileUiState> = _state.asStateFlow()

    fun onNameChanged(newName: String) {
        _state.update { it.copy(userName = newName) }
    }

    fun onSaveClicked() {
        _state.update { it.copy(isLoading = true) }
        viewModelScope.launch {
            // save logic...
            _state.update { it.copy(isLoading = false) }
        }
    }
}

LiveData vs StateFlow

Both work for MVVM. StateFlow is preferred in new projects because it integrates with Kotlin coroutines and Compose natively. LiveData works well with XML views and lifecycle awareness is built in.

// StateFlow (modern approach)
val state: StateFlow<UiState> = _state.asStateFlow()

// LiveData (XML view approach)
val state: LiveData<UiState> = _state.asLiveData()

Common MVVM Mistakes

1. Fat ViewModel: Putting business logic, navigation, and data transformation all in the ViewModel. Business logic belongs in Use Cases or the Model layer.
2. View directly mutating ViewModel state: The View should call a method; the ViewModel decides how state changes.
3. Ignoring state: Exposing multiple separate LiveData streams instead of a single state object leads to inconsistent UI states.
4. Holding View references: A ViewModel must never hold a reference to an Activity, Fragment, or Context. It survives configuration changes — if it held a View reference, it would leak the old Activity.

Testing MVVM

MVVM makes testing straightforward because the ViewModel has no Android framework dependencies.

class UserViewModelTest {
    private val repository = mockk<UserRepository>()
    private lateinit var viewModel: UserViewModel

    @Before
    fun setup() {
        viewModel = UserViewModel(repository)
    }

    @Test
    fun `loadUser success updates state`() = runTest {
        val user = User("1", "Ada", "ada@test.com")
        coEvery { repository.getUser("1") } returns user

        viewModel.loadUser("1")

        val state = viewModel.uiState.value
        assert(state is UiState.Success)
        assertEquals(user, (state as UiState.Success).user)
    }

    @Test
    fun `loadUser failure updates error state`() = runTest {
        coEvery { repository.getUser("1") } throws IOException("Network error")

        viewModel.loadUser("1")

        val state = viewModel.uiState.value
        assert(state is UiState.Error)
    }
}

No Robolectric, no instrumentation tests, no mocked Android framework. Pure JVM unit tests.