Android Beginners

Lesson 18: Understanding App Architecture: MVVM for Beginners

Ahmad Najar Ahmad Najar 1 min read

Understanding App Architecture: MVVM for Beginners

The pattern we've been building toward has a name: MVVM (Model-View-ViewModel). You don't need to memorize the term, but understanding the three roles will make everything from here much clearer.

The three layers

  • Model — your data and the rules for getting/changing it (a Task data class, a repository that fetches tasks from a database or network)
  • ViewModel — holds the current UI state and the logic for updating it (what we built in lesson 17)
  • View — your composables. They only display state and forward user actions — they contain no business logic themselves

Why bother with the separation?

Without it, it's tempting to put everything in your composable — network calls, data logic, and UI all tangled together. That works for a toy app, but becomes unmanageable fast: you can't test business logic without spinning up actual UI, and a single composable ends up doing five jobs at once.

The rule of thumb

// Bad: composable doing everything itself
@Composable
fun TaskListScreen() {
    var tasks by remember { mutableStateOf(fetchTasksFromDatabase()) } // ❌
}

// Good: composable just displays what the ViewModel gives it
@Composable
fun TaskListScreen(viewModel: TaskListViewModel = viewModel()) {
    LazyColumn {
        items(viewModel.tasks) { task -> Text(task.title) }
    }
}

If you ever find yourself writing real logic — filtering, calculations, network calls, database queries — directly inside a composable, that's a signal it belongs in the ViewModel (or a layer below it) instead.

What's coming

Over the next several lessons we'll flesh out the Model layer properly: fetching real data from the internet (lesson 19), and saving it locally so it survives app restarts (lesson 22).

Next: Lesson 19 — making your first real network request with Retrofit.

Android Beginners