State in ViewModel in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

What is the output of this ViewModel state update?

Consider this ViewModel code that holds a counter state. What will be the value of counter after calling increment() twice?

Android Kotlin

class CounterViewModel : ViewModel() {
  private val _counter = MutableLiveData(0)
  val counter: LiveData<Int> = _counter

  fun increment() {
    _counter.value = (_counter.value ?: 0) + 1
  }
}

// After calling increment() twice:

A counter.value == 1

B counter.value == 2

C counter.value == 0

D counter.value == null

💡 Hint

Each call to increment adds 1 to the current value stored in _counter.

The initial value is 0. Each increment adds 1, so after two calls, the value is 2.

❓ lifecycle

intermediate

When is ViewModel state preserved?

In Android, when does the ViewModel keep its state intact?

A When the user closes the app from recent apps

B When the app is killed by the system

C During configuration changes like screen rotation

D When the device is restarted

💡 Hint

Think about what happens to Activity and ViewModel during rotation.

ViewModel survives configuration changes such as screen rotations but is cleared when the Activity is finished or the app is killed.

📝 Syntax

advanced

Which option correctly exposes immutable state from ViewModel?

Given a MutableStateFlow in ViewModel, which option correctly exposes it as immutable to the UI?

Android Kotlin

private val _uiState = MutableStateFlow(0)
// Expose immutable state here:

A val uiState: StateFlow<Int> = _uiState

B val uiState: MutableStateFlow<Int> = _uiState

C val uiState: Flow<Int> = _uiState.asStateFlow()

D val uiState: StateFlow<Int> = _uiState.asStateFlow()

💡 Hint

Use the correct method to expose a read-only StateFlow.

The asStateFlow() method returns a read-only StateFlow view of the MutableStateFlow.

🔧 Debug

advanced

Why does UI not update after ViewModel state change?

This ViewModel updates a LiveData value, but the UI does not reflect the change. What is the likely cause?

Android Kotlin

class MyViewModel : ViewModel() {
  val data = MutableLiveData("Hello")

  fun update() {
    data.value = "World"
  }
}

// UI observes data but does not update after update() call.

A MutableLiveData.value was updated from a background thread

B UI is not observing LiveData on the main thread

C LiveData observer was not registered before update() call

D LiveData was declared as val instead of var

💡 Hint

LiveData.value must be updated on the main thread.

Updating LiveData.value from a background thread causes UI not to receive updates. Use postValue() or update on main thread.

🧠 Conceptual

expert

What is the main benefit of using StateFlow in ViewModel over LiveData?

Choose the best explanation for why StateFlow might be preferred over LiveData for state management in ViewModel.

A StateFlow supports coroutines and provides a consistent API for reactive streams

B LiveData cannot be observed from fragments

C StateFlow automatically saves state across process death

D LiveData requires manual lifecycle management

💡 Hint

Think about Kotlin coroutines integration and reactive programming.

StateFlow integrates seamlessly with Kotlin coroutines and provides a consistent reactive streams API, unlike LiveData which is lifecycle-aware but not coroutine-based.

Practice

1. What is the main purpose of using ViewModel in Android development?

easy

A. To replace the Activity lifecycle completely

B. To handle user input events directly

C. To store and manage UI-related data safely during configuration changes

D. To perform network requests on the main thread

Solution

1. Step 1: Understand ViewModel role and compare options

   ViewModel is designed to hold UI data and survive configuration changes like screen rotations. Only To store and manage UI-related data safely during configuration changes correctly describes this purpose; others describe unrelated or incorrect roles.

2. Final Answer:

   To store and manage UI-related data safely during configuration changes -> Option C

3. Quick Check:

   ViewModel stores UI data safely [OK]

Hint: ViewModel keeps UI data safe during screen rotations [OK]

Common Mistakes:

• Thinking ViewModel handles UI events directly
• Assuming ViewModel replaces Activity lifecycle
• Using ViewModel for network calls on main thread

2. Which of the following is the correct way to declare a mutable state in a ViewModel using LiveData?

easy

A. var data = MutableLiveData() as LiveData<String>

B. val data = LiveData<String>()

C. var data = LiveData<String>()

D. val data = MutableLiveData<String>()

Solution

1. Step 1: Identify mutable LiveData declaration and syntax

   MutableLiveData allows changing the value; LiveData alone is read-only. val data = MutableLiveData<String>() correctly declares a mutable LiveData with type String.

2. Final Answer:

   val data = MutableLiveData<String>() -> Option D

3. Quick Check:

   MutableLiveData is mutable LiveData [OK]

Hint: MutableLiveData allows data changes; LiveData is read-only [OK]

Common Mistakes:

• Using LiveData() directly (it's abstract)
• Declaring mutable LiveData as var without MutableLiveData
• Casting MutableLiveData to LiveData incorrectly

3. Given this ViewModel code snippet:

class MyViewModel : ViewModel() {
  private val _count = MutableLiveData(0)
  val count: LiveData<Int> = _count

  fun increment() {
    _count.value = (_count.value ?: 0) + 1
  }
}

What will be the value of count after calling increment() twice starting from initial state?

medium

A. 2

B. 1

C. 0

D. null

Solution

1. Step 1: Trace execution from initial value

   _count starts at 0 as MutableLiveData(0). Each increment adds 1: first call sets 1, second call sets 2.

2. Final Answer:

   2 -> Option A

3. Quick Check:

   0 + 1 + 1 = 2 [OK]

Hint: Each increment adds 1 to current LiveData value [OK]

Common Mistakes:

• Forgetting to unwrap nullable value with ?: 0
• Assuming LiveData updates automatically without setting value
• Confusing private _count with public count

4. Identify the error in this ViewModel code:

class SampleViewModel : ViewModel() {
  val data = MutableLiveData<String>()

  fun updateData(newValue: String) {
    data.value = newValue
  }

  fun getData(): String {
    return data.value
  }
}

medium

A. getData() returns nullable String but declared as non-null

B. MutableLiveData cannot hold String values

C. data.value should be updated using postValue() only

D. ViewModel cannot have functions

Solution

1. Step 1: Analyze getData() return type mismatch

   data.value is nullable String?, but getData() returns non-null String. Returning nullable as non-null causes compile error or runtime crash.

2. Final Answer:

   getData() returns nullable String but declared as non-null -> Option A

3. Quick Check:

   LiveData.value is nullable [OK]

Hint: LiveData.value is nullable; match return types [OK]

Common Mistakes:

• Ignoring nullable type of LiveData.value
• Thinking postValue() is mandatory for all updates
• Believing ViewModel cannot have functions

5. You want to expose a read-only LiveData from your ViewModel while keeping the MutableLiveData private. Which code snippet correctly implements this pattern?

hard

A. private val _state = MutableLiveData<Int>()
val state: MutableLiveData<Int> = _state

B. private val _state = MutableLiveData<Int>()
val state: LiveData<Int> get() = _state

C. val state = MutableLiveData<Int>()

D. val _state = LiveData<Int>()
val state: MutableLiveData<Int> = _state

Solution

1. Step 1: Identify correct encapsulation pattern

   MutableLiveData should be private; expose only LiveData publicly. private val _state = MutableLiveData<Int>() val state: LiveData<Int> get() = _state declares private MutableLiveData and public LiveData getter correctly.

2. Final Answer:

   private val _state = MutableLiveData<Int>()\nval state: LiveData<Int> get() = _state -> Option B

3. Quick Check:

   Expose LiveData, keep MutableLiveData private [OK]

Hint: Expose LiveData getter, keep MutableLiveData private [OK]

Common Mistakes:

• Exposing MutableLiveData publicly
• Declaring LiveData as mutable
• Using LiveData constructor directly (abstract class)