MVVM pattern in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the role of ViewModel in MVVM

In the MVVM pattern, what is the primary responsibility of the ViewModel?

A To hold and manage UI-related data and handle business logic without referencing the View directly

B To directly update the UI components and handle user input events

C To manage database operations and network calls exclusively

D To act as a data model representing the app's data structure

💡 Hint

Think about which component acts as a bridge between UI and data without knowing UI details.

The ViewModel holds UI data and business logic, exposing data to the View without referencing it directly, enabling separation of concerns.

❓ ui_behavior

intermediate

LiveData observation in MVVM

Given a ViewModel exposing LiveData called 'status', what happens in the View when the LiveData value changes?

Android Kotlin

viewModel.status.observe(viewLifecycleOwner) { newStatus ->
  textView.text = newStatus
}

A The textView's text updates only if manually refreshed by the user

B The textView's text updates only once when the View is created

C The textView's text never updates because LiveData does not notify observers

D The textView's text updates automatically to the new status value whenever it changes

💡 Hint

LiveData notifies observers when data changes.

LiveData automatically notifies observers when its data changes, triggering UI updates like setting textView.text.

❓ lifecycle

advanced

ViewModel lifecycle and data retention

What happens to the ViewModel instance when the associated Activity is recreated due to a configuration change (e.g., device rotation)?

A The ViewModel is destroyed immediately and recreated with the Activity

B A new ViewModel instance is created, losing previous data

C The same ViewModel instance is retained and reused, preserving its data

D The ViewModel instance is shared across all Activities in the app

💡 Hint

ViewModel is designed to survive configuration changes.

ViewModel instances survive configuration changes like rotations, so data is preserved and reused by the new Activity instance.

❓ navigation

advanced

Sharing data between fragments using ViewModel

How can two fragments in the same Activity share data using MVVM pattern?

A Each fragment creates its own ViewModel instance and communicates via interfaces

B Both fragments use the same Activity-scoped ViewModel instance to share LiveData

C Fragments directly access each other's views to share data

D Fragments use static variables to share data globally

💡 Hint

Think about ViewModel scope and shared lifecycle owners.

Using an Activity-scoped ViewModel allows multiple fragments to observe and update shared LiveData, enabling communication without tight coupling.

🔧 Debug

expert

Diagnosing a memory leak caused by ViewModel misuse

A developer stores a reference to an Activity's Context inside a ViewModel. What is the likely consequence?

A Memory leak occurs because ViewModel outlives Activity and holds a strong reference to its Context

B No problem occurs because ViewModel automatically clears references on Activity destruction

C App crashes immediately due to invalid Context usage

D The Context reference is weak and does not affect memory

💡 Hint

Consider how long ViewModel lives compared to Activity and what holding Context means.

ViewModel lives longer than Activity during configuration changes; holding Activity Context causes memory leaks by preventing garbage collection.

Practice

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