Bird
Raised Fist0
Android Kotlinmobile~5 mins

MVVM pattern in Android Kotlin - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What does MVVM stand for in Android development?
MVVM stands for Model-View-ViewModel. It is a design pattern that helps separate the user interface (View) from the business logic (Model) using a ViewModel as a bridge.
Click to reveal answer
beginner
What is the role of the ViewModel in MVVM?
The ViewModel holds and manages UI-related data. It communicates with the Model to get data and prepares it for the View. It survives configuration changes like screen rotations.
Click to reveal answer
intermediate
How does the View observe data changes in MVVM?
The View observes LiveData or StateFlow objects exposed by the ViewModel. When data changes, the View automatically updates without manual intervention.
Click to reveal answer
intermediate
Why is MVVM better than putting all code in the Activity or Fragment?
MVVM separates concerns, making code easier to read, test, and maintain. It prevents Activities or Fragments from becoming too large and handles lifecycle changes better.
Click to reveal answer
intermediate
In MVVM, where should network or database operations be performed?
Network or database operations should be done in the Model or Repository layer. The ViewModel requests data from the Model and exposes it to the View.
Click to reveal answer
In MVVM, which component directly updates the UI?
AViewModel
BModel
CView
DRepository
Which Android class is commonly used in ViewModel to hold observable data?
AService
BIntent
CBundle
DLiveData
What is a key benefit of using ViewModel in MVVM?
AIt survives configuration changes
BIt handles UI rendering
CIt stores user preferences
DIt manages network connections
Where should business logic be placed in MVVM?
AModel
BViewModel
CActivity
DView
Which of these is NOT a responsibility of the ViewModel?
AFetching data from Model
BHandling user input events directly
CExposing data to View
DSurviving configuration changes
Explain the roles of Model, View, and ViewModel in the MVVM pattern.
Think about who does what in the app: data, UI, and the middleman.
You got /3 concepts.
    Describe how MVVM helps manage screen rotations in Android apps.
    Consider what happens when the screen turns and the Activity restarts.
    You got /3 concepts.

      Practice

      (1/5)
      1. What is the main role of the ViewModel in the MVVM pattern?
      easy
      A. To render the UI components on the screen
      B. To directly handle user input events and update the UI
      C. To store raw data from the database without any processing
      D. To hold and manage UI-related data and expose it to the View

      Solution

      1. Step 1: Understand ViewModel responsibility

        The ViewModel holds UI data and prepares it for the View, separating UI logic from data sources.
      2. Step 2: Differentiate ViewModel from other components

        The View handles UI rendering and user input, while the Model manages raw data. ViewModel acts as a bridge.
      3. Final Answer:

        To hold and manage UI-related data and expose it to the View -> Option D
      4. Quick Check:

        ViewModel = UI data holder [OK]
      Hint: ViewModel holds data for UI, not UI itself [OK]
      Common Mistakes:
      • Confusing ViewModel with View
      • Thinking ViewModel handles UI rendering
      • Assuming ViewModel stores raw database data only
      2. Which of the following is the correct way to observe LiveData in a Kotlin Android View (Activity or Fragment)?
      easy
      A. viewModel.data.observe(this, Observer { value -> updateUI(value) })
      B. viewModel.data.observeForever { value -> updateUI(value) }
      C. viewModel.data.observe { value -> updateUI(value) }
      D. viewModel.data.observe(this)

      Solution

      1. Step 1: Recall LiveData observe syntax

        LiveData.observe requires a LifecycleOwner and an Observer object or lambda with explicit Observer.
      2. Step 2: Identify correct Kotlin syntax

        viewModel.data.observe(this, Observer { value -> updateUI(value) }) uses the correct method signature with LifecycleOwner and Observer lambda.
      3. Final Answer:

        viewModel.data.observe(this, Observer { value -> updateUI(value) }) -> Option A
      4. Quick Check:

        LiveData.observe needs LifecycleOwner + Observer [OK]
      Hint: Use observe(this, Observer { }) in Kotlin [OK]
      Common Mistakes:
      • Using observeForever in UI components
      • Omitting Observer wrapper in observe call
      • Passing lambda without LifecycleOwner
      3. Given this ViewModel code snippet, what will be the output when increment() is called twice?
      class CounterViewModel : ViewModel() {
        private val _count = MutableLiveData(0)
        val count: LiveData<Int> = _count
      
        fun increment() {
          _count.value = (_count.value ?: 0) + 1
        }
      }
      medium
      A. The count LiveData will have value 2
      B. The count LiveData will have value 1
      C. The count LiveData will have value 0
      D. The code will cause a runtime error

      Solution

      1. Step 1: Understand initial LiveData value

        The MutableLiveData _count starts at 0.
      2. Step 2: Trace increment calls

        Each increment adds 1 to current value: first call sets 1, second call sets 2.
      3. Final Answer:

        The count LiveData will have value 2 -> Option A
      4. Quick Check:

        0 + 1 + 1 = 2 [OK]
      Hint: Increment adds 1 each call, so two calls = 2 [OK]
      Common Mistakes:
      • Assuming LiveData does not update value
      • Forgetting initial value is 0
      • Thinking LiveData is immutable
      4. Identify the error in this ViewModel code snippet:
      class UserViewModel : ViewModel() {
        val userName = MutableLiveData<String>()
      
        fun updateName(newName: String) {
          userName.value = newName
        }
      
        fun getName(): String {
          return userName.value!!
        }
      }
      medium
      A. Using MutableLiveData instead of LiveData
      B. Forcing non-null with !! on possibly null value
      C. Not initializing userName with a default value
      D. Missing observer for userName LiveData

      Solution

      1. Step 1: Analyze getName() method

        It returns userName.value!! which forces non-null but value can be null initially.
      2. Step 2: Identify risk of NullPointerException

        If userName.value is null, !! causes crash. This is unsafe without default or null check.
      3. Final Answer:

        Forcing non-null with !! on possibly null value -> Option B
      4. Quick Check:

        !! on nullable LiveData value risks crash [OK]
      Hint: Avoid !! on LiveData.value without null check [OK]
      Common Mistakes:
      • Ignoring null safety on LiveData values
      • Assuming LiveData always has value
      • Confusing MutableLiveData with LiveData usage
      5. You want to fetch user data from a remote API and update the UI using MVVM. Which approach correctly separates concerns and updates the UI safely?
      1. Repository fetches data asynchronously
      2. ViewModel exposes LiveData for user data
      3. View observes LiveData and updates UI
      
      Which code snippet fits this pattern?
      hard
      A. View directly calls repository fetch and updates UI without ViewModel
      B. Repository updates UI directly after fetching data
      C. ViewModel calls repository fetch, updates MutableLiveData; View observes LiveData to update UI
      D. ViewModel updates UI components directly after fetching data

      Solution

      1. Step 1: Understand MVVM data flow

        Repository handles data fetching, ViewModel holds data and exposes LiveData, View observes LiveData to update UI.
      2. Step 2: Match correct separation of concerns

        Only ViewModel calls repository fetch, updates MutableLiveData; View observes LiveData to update UI follows this flow: ViewModel updates LiveData, View observes it, no direct UI updates in ViewModel or Repository.
      3. Final Answer:

        ViewModel calls repository fetch, updates MutableLiveData; View observes LiveData to update UI -> Option C
      4. Quick Check:

        Repository -> ViewModel -> LiveData -> View [OK]
      Hint: Data flows Repository -> ViewModel -> LiveData -> View [OK]
      Common Mistakes:
      • Updating UI directly in Repository or ViewModel
      • View fetching data directly
      • Not using LiveData for UI updates
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard