State in ViewModel in Android Kotlin - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of ViewModel in Android development?

ViewModel holds and manages UI-related data in a lifecycle-conscious way. It survives configuration changes like screen rotations, keeping the UI state intact.

beginner

How does MutableLiveData help in managing state inside a ViewModel?

MutableLiveData allows the ViewModel to hold data that can be observed by the UI. When data changes, the UI updates automatically.

intermediate

Why should UI state be stored in ViewModel instead of Activity or Fragment?

Storing UI state in ViewModel prevents data loss during configuration changes and separates UI logic from UI controllers, making code cleaner and more testable.

advanced

What is the difference between LiveData and StateFlow in ViewModel state management?

LiveData is lifecycle-aware and designed for UI observation. StateFlow is a Kotlin Flow that holds state and supports coroutines, offering more flexibility and modern reactive patterns.

intermediate

How do you update state inside a ViewModel using MutableStateFlow?

You update the state by assigning a new value to the MutableStateFlow variable, for example: _state.value = newValue. Observers get notified automatically.

What happens to ViewModel data when the device rotates?

A Data is preserved and reused

B Data is lost and reset

C ViewModel is destroyed and recreated

D UI crashes

ViewModel survives configuration changes like rotation, so data is preserved and reused.

Which class is commonly used inside ViewModel to hold observable UI state?

A Bundle

B Intent

C MutableLiveData

D View

MutableLiveData holds observable data that UI components can watch for changes.

Which of these is a benefit of using StateFlow over LiveData?

A Supports coroutines and reactive streams

B Not lifecycle-aware

C Works only with Java

D Cannot hold state

StateFlow supports Kotlin coroutines and reactive programming, offering more flexibility.

Where should you NOT store UI state in Android apps?

A ViewModelStore

B ViewModel

C Fragment

D Activity

Storing UI state in Activity risks losing data on configuration changes.

How do UI components get notified of state changes in ViewModel?

A By polling the ViewModel

B Through observers on LiveData or StateFlow

C By restarting the Activity

D By manual refresh

UI components observe LiveData or StateFlow to get automatic updates when state changes.

Explain how ViewModel helps manage UI state during device rotation.

Think about what happens when the screen rotates and how ViewModel keeps data safe.

Describe the difference between LiveData and StateFlow for state management in ViewModel.

Consider their usage and features in Kotlin and Android.

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)