Explain ViewModel, Repository, and Data Source in MVVM

What's really being asked

This question isn't just about definitions; it's a fundamental check on your understanding of modern Android architecture principles. The interviewer is testing your grasp of separation of concerns, lifecycle awareness, and the single source of truth pattern. Getting this wrong suggests a lack of familiarity with standard practices, which is a major red flag for any level.

The full answer

An ideal answer explains each component's responsibility and then traces the data flow. First, define the ViewModel: it holds and exposes UI-related state to the UI layer (e.g., a Composable function or an Activity). It is lifecycle-aware, surviving configuration changes like screen rotation, and should not hold references to UI elements. It handles UI events and requests data from the next layer down. Second, explain the Repository: it acts as a mediator between the domain layer (ViewModels, UseCases) and data sources. It's responsible for abstracting the origin of the data (network, cache, database) and is often the single source of truth for a given piece of data. Third, describe Data Sources: these are the concrete implementations for fetching and saving data, like a Retrofit service for network calls or a Room DAO for local database access. Finally, trace the unidirectional data flow: the UI observes state from the ViewModel, the ViewModel requests data from the Repository, and the Repository fetches from the appropriate Data Source, with the data flowing back up to the UI.

The mistakes people make

Candidates often break the separation of concerns. A major red flag is describing a ViewModel that directly calls a Retrofit service or a Room DAO. This bypasses the Repository, making the ViewModel responsible for data source logic and much harder to test. Another common mistake is having the UI (Activity/Fragment) call the Repository directly, which couples the UI to data-fetching logic and violates the MVVM pattern. Finally, some candidates incorrectly describe the Repository as only a network layer, forgetting its role in managing and mediating between multiple sources, like a local cache and a remote API.

What usually comes next

Expect questions that probe deeper into the 'why'. For example: "Why is the Repository abstraction useful? Why not just call Retrofit from the ViewModel?" (Answer: testability, swapping data sources, centralizing data logic). Or, "How does the ViewModel expose data to the UI in a lifecycle-safe way?" (Answer: LiveData or, more commonly now, StateFlow). Another good one is, "Where would you handle mapping a network DTO to a domain model?" (Answer: In the Repository, before exposing it to the ViewModel).

A concrete example

To fetch user profile data: 1. The UI calls a method on the ViewModel, like viewModel.loadUserProfile(). 2. The ViewModel, which has a dependency on a Repository, calls userRepository.getProfile("userId"). 3. The Repository first checks its local Data Source (Room cache). If the data is stale or absent, it calls its remote Data Source (userApiService.fetchProfile("userId") via Retrofit). 4. Upon receiving the network response, the Repository saves the fresh data to the Room cache, making it the single source of truth. 5. The Repository exposes a Flow from Room (userDao.getProfile("userId")). The ViewModel collects this Flow, transforms it into a UI state object, and updates its public StateFlow. 6. The UI, which is collecting the ViewModel's state flow, automatically receives the new state and displays the user profile.