LiveData basics in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

LiveData Observer Update Behavior

Given this LiveData and observer setup in an Android app, what will be the output on the UI after calling liveData.value = "Hello"?

Android Kotlin

val liveData = MutableLiveData<String>()
liveData.observe(this) { value ->
  textView.text = value
}
liveData.value = "Hello"

A The TextView will display "Hello" immediately.

B The TextView will remain empty until the next UI refresh.

C The app will crash because LiveData cannot be updated directly.

D The TextView will display "null" because the initial value is missing.

💡 Hint

LiveData notifies observers immediately when the value changes.

When you set liveData.value, all active observers receive the new value right away, updating the UI.

❓ lifecycle

intermediate

LiveData and Lifecycle Owner

What happens if you observe LiveData with a lifecycle owner that is already in the DESTROYED state?

Android Kotlin

liveData.observe(lifecycleOwner) { value ->
  // update UI
}

A The observer will receive updates until the lifecycle is destroyed.

B The observer will never receive updates because the lifecycle is destroyed.

C The app will throw an IllegalStateException immediately.

D The observer will receive updates even after the lifecycle is destroyed.

💡 Hint

LiveData respects the lifecycle state of its observers.

Observers tied to a destroyed lifecycle owner do not receive updates to avoid memory leaks.

📝 Syntax

advanced

Correct LiveData Declaration

Which of the following Kotlin code snippets correctly declares a MutableLiveData of integers and sets its initial value to 10?

A val liveData = MutableLiveData<Int>(10)

B val liveData = MutableLiveData<Int>.value(10)

C val liveData = MutableLiveData<Int> { 10 }

D val liveData = MutableLiveData<Int>().apply { value = 10 }

💡 Hint

MutableLiveData initial value is set via the value property, not constructor.

MutableLiveData constructor does not take initial value; set it by assigning to value property.

🔧 Debug

advanced

LiveData Observer Not Updating UI

Why does this LiveData observer not update the TextView when the value changes?

Android Kotlin

val liveData = MutableLiveData<String>()
liveData.observe(this) { value ->
  textView.text = value
}
// Later in code
liveData.postValue("Update")

A postValue does not notify observers; only setValue does.

B The observer is not active because the lifecycle owner is paused.

C postValue updates happen on background thread; UI update must be on main thread.

D The TextView is null, so update fails silently.

💡 Hint

postValue schedules update on main thread asynchronously.

postValue posts update to main thread asynchronously; if UI update code runs immediately after postValue, UI may not reflect change yet.

🧠 Conceptual

expert

LiveData Behavior on Configuration Change

After a device rotation (configuration change), what happens to the LiveData observers and their data in a typical Android app using ViewModel and LiveData?

A The ViewModel survives, LiveData keeps its data, and new observers receive the last value immediately.

B The ViewModel and LiveData are recreated, so data is lost and observers start empty.

C LiveData data is saved but observers are not recreated automatically after rotation.

D Observers remain the same instance and continue receiving updates without interruption.

💡 Hint

ViewModel survives configuration changes to keep data.

ViewModel instances survive configuration changes; LiveData inside them keeps data; new observers get last emitted value immediately.

Practice

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

easy

A. To manage database queries directly

B. To perform background tasks without blocking the UI

C. To store user preferences permanently

D. To hold data that UI components can observe and update automatically

Solution

1. Step 1: Understand LiveData's role

   LiveData is designed to hold data that UI components can observe, so they update automatically when data changes.

2. Step 2: Compare with other options

   Background tasks, storing preferences, and database management are handled by other components, not LiveData.

3. Final Answer:

   To hold data that UI components can observe and update automatically -> Option D

4. Quick Check:

   LiveData = Observable data holder [OK]

Hint: LiveData = data holder that UI watches [OK]

Common Mistakes:

• Confusing LiveData with background task handlers
• Thinking LiveData stores data permanently
• Mixing LiveData with database management

2. Which of the following is the correct way to declare a mutable LiveData variable in Kotlin?

easy

A. val data = MutableLiveData<String>()

B. val data = LiveData<String>()

C. var data = LiveData<String>()

D. var data = MutableLiveData

Solution

1. Step 1: Identify MutableLiveData syntax

   MutableLiveData requires specifying the type with angle brackets and calling its constructor with parentheses.

2. Step 2: Check each option

   val data = MutableLiveData<String>() correctly uses val data = MutableLiveData<String>(). val data = LiveData<String>() uses LiveData which is immutable. var data = LiveData<String>() uses LiveData with var but still immutable. var data = MutableLiveData misses type and parentheses.

3. Final Answer:

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

4. Quick Check:

   MutableLiveData syntax = val data = MutableLiveData<String>() [OK]

Hint: MutableLiveData needs type and parentheses [OK]

Common Mistakes:

• Using LiveData instead of MutableLiveData to change data
• Omitting parentheses when creating MutableLiveData
• Not specifying the generic type

3. Given the code below, what will be printed when liveData.value = "Hello" is called?

val liveData = MutableLiveData<String>()
liveData.observe(this) { value ->
    println(value)
}

medium

A. Nothing is printed

B. Compilation error

C. Hello

D. null

Solution

1. Step 1: Understand observe behavior

   The observer is set to print the new value whenever liveData changes.

2. Step 2: Assigning value triggers observer

   Setting liveData.value = "Hello" triggers the observer lambda, printing "Hello".

3. Final Answer:

   Hello -> Option C

4. Quick Check:

   Observer prints new value = Hello [OK]

Hint: Setting value triggers observer print [OK]

Common Mistakes:

• Thinking observer triggers only on lifecycle start
• Expecting null because initial value is empty
• Confusing observe with observeForever

4. What is wrong with this code snippet?

val liveData = MutableLiveData<Int?>()
liveData.observe(this) { value ->
    println(value)
}
liveData.value = 10
liveData.value = null

medium

A. LiveData cannot hold null values

B. Nothing is wrong; null is allowed in MutableLiveData

C. Setting liveData.value to null causes a crash

D. Observe must be called after setting value

Solution

1. Step 1: Check if MutableLiveData accepts null

   MutableLiveData can hold null values if the generic type allows it (Int? or nullable type).

2. Step 2: Analyze code behavior

   The code declares MutableLiveData<Int?>(), which allows null since Int? is nullable. Setting to 10 and then null works fine without crash; observer prints both.

3. Final Answer:

   Nothing is wrong; null is allowed in MutableLiveData -> Option B

4. Quick Check:

   MutableLiveData accepts null if type nullable [OK]

Hint: MutableLiveData can hold null if type nullable [OK]

Common Mistakes:

• Assuming LiveData never accepts null
• Thinking observe order matters for value setting
• Confusing runtime crash with compile error

5. You want to update UI only when LiveData has a non-null and non-empty string. Which code snippet correctly observes liveData to achieve this?

val liveData = MutableLiveData<String>()
liveData.observe(this) { value ->
    // What to put here?
}

hard

A. if (value != null && value.isNotEmpty()) { updateUI(value) }

B. if (value == null || value.isEmpty()) { updateUI(value) }

C. updateUI(value ?: "")

D. updateUI(value!!)

Solution

1. Step 1: Define condition for UI update

   We want to update UI only if value is not null and not empty.

2. Step 2: Check each option logic

   if (value != null && value.isNotEmpty()) { updateUI(value) } checks both conditions correctly. if (value == null || value.isEmpty()) { updateUI(value) } updates UI on null or empty, opposite of requirement. updateUI(value ?: "") updates UI always with fallback empty string. updateUI(value!!) forces non-null with !! which can crash.

3. Final Answer:

   if (value != null && value.isNotEmpty()) { updateUI(value) } -> Option A

4. Quick Check:

   Check non-null and non-empty before update [OK]

Hint: Check both null and empty before UI update [OK]

Common Mistakes:

• Updating UI on null or empty values
• Using !! operator risking crash
• Ignoring empty string check