Why ViewModel survives configuration changes in Android Kotlin - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why does ViewModel survive configuration changes?

In Android development, why does a ViewModel instance survive configuration changes like screen rotations?

A Because ViewModel uses static variables that persist across configuration changes.

B Because ViewModel saves its data to a local database automatically before configuration changes.

C Because ViewModel is tied to the lifecycle of the Activity or Fragment and is retained by the system during configuration changes.

D Because ViewModel is recreated every time but restores its state from savedInstanceState bundle.

💡 Hint

Think about how Android manages lifecycle and retains objects during configuration changes.

The ViewModel is designed to be tied to the lifecycle of an Activity or Fragment but is retained when configuration changes happen. This means the system keeps the same ViewModel instance alive, so data is preserved without needing to save and restore manually.

❓ ui_behavior

intermediate

What happens to UI data in ViewModel after rotation?

If you store user input in a ViewModel, what will happen to that data after the device is rotated?

A The data is cleared and replaced with default values after rotation.

B The data remains intact and accessible from the ViewModel after rotation.

C The data is saved to a file automatically and reloaded after rotation.

D The data is lost because ViewModel is destroyed and recreated on rotation.

💡 Hint

Remember what ViewModel is designed to do with data during lifecycle changes.

ViewModel survives configuration changes like rotation, so any data stored in it remains available and does not get lost.

❓ lifecycle

advanced

When is a ViewModel destroyed?

Considering Android lifecycle, when does the system destroy a ViewModel instance?

A When the associated Activity or Fragment is finishing and not just being recreated due to configuration changes.

B Immediately after every configuration change like rotation.

C When the app goes into the background for more than 5 minutes.

D When the user presses the home button.

💡 Hint

Think about the difference between finishing an Activity and just rotating the device.

The ViewModel is destroyed only when the lifecycle owner is permanently finished, such as when the Activity is closed, not during temporary configuration changes.

❓ navigation

advanced

How does ViewModel scope affect navigation between fragments?

If two fragments share a ViewModel scoped to their parent Activity, what happens to the ViewModel when navigating between these fragments?

A The same ViewModel instance is shared and survives navigation between fragments.

B Each fragment gets a new ViewModel instance when navigated to.

C The ViewModel is destroyed when leaving the first fragment and recreated for the second.

D The ViewModel data is saved to disk and reloaded for each fragment.

💡 Hint

Consider the scope of the ViewModel and how it relates to the lifecycle owner.

When ViewModel is scoped to the parent Activity, all fragments within that Activity share the same ViewModel instance, preserving data across fragment navigation.

🔧 Debug

expert

Why does this ViewModel data reset after rotation?

You have this code snippet in your Activity: val viewModel = ViewModelProvider(this).get(MyViewModel::class.java) But after rotating the device, the data in viewModel resets. What is the most likely cause?

A ViewModel does not survive rotation by design; you must manually save and restore data.

B You forgot to save the ViewModel data in onSaveInstanceState.

C You should use application context instead of Activity context to create ViewModelProvider.

D You are creating a new ViewModelProvider with 'this' referring to the Activity, but the Activity is recreated, so the ViewModel instance is new.

💡 Hint

Check what 'this' refers to and how ViewModelProvider works with lifecycle owners.

When you use 'this' inside an Activity, it refers to the current Activity instance. After rotation, the Activity is recreated, so a new ViewModelProvider is created, resulting in a new ViewModel instance. To retain data, you must use the same lifecycle owner or use ViewModelProvider tied to a persistent owner.

Practice

1. Why does a ViewModel survive configuration changes like screen rotations in Android?

easy

A. Because it is tied to the lifecycle of the activity or fragment and not recreated on configuration changes

B. Because it saves data to a file on disk automatically

C. Because it uses static variables to hold data

D. Because it runs in a separate background thread

Solution

1. Step 1: Understand ViewModel lifecycle

   A ViewModel is designed to be tied to the lifecycle of an activity or fragment but survives configuration changes like rotations.

2. Step 2: Why it survives configuration changes

   When a configuration change happens, the activity is destroyed and recreated, but the ViewModel instance is retained and reused.

3. Final Answer:

   Because it is tied to the lifecycle of the activity or fragment and not recreated on configuration changes -> Option A

4. Quick Check:

   ViewModel lifecycle = survives config changes [OK]

Hint: ViewModel survives because it outlives activity recreation [OK]

Common Mistakes:

• Thinking ViewModel saves data to disk automatically
• Confusing ViewModel with static variables
• Assuming ViewModel runs on a background thread

2. Which of the following is the correct way to get a ViewModel instance in an Activity using Kotlin?

easy

A. val model = ViewModelProvider.get(this, MyViewModel::class.java)

B. val model = MyViewModel()

C. val model = ViewModelProvider(this).get(MyViewModel::class.java)

D. val model = ViewModel()

Solution

1. Step 1: Identify correct ViewModelProvider usage

   The correct syntax to get a ViewModel instance is using ViewModelProvider with the activity or fragment as owner.

2. Step 2: Check Kotlin syntax

   Using ViewModelProvider(this).get(MyViewModel::class.java) is the standard way to get the ViewModel instance.

3. Final Answer:

   val model = ViewModelProvider(this).get(MyViewModel::class.java) -> Option C

4. Quick Check:

   ViewModelProvider(this).get() = correct syntax [OK]

Hint: Use ViewModelProvider(this).get() to get ViewModel [OK]

Common Mistakes:

• Instantiating ViewModel directly with constructor
• Using incorrect ViewModelProvider syntax
• Confusing ViewModel class with instance

3. Given this code snippet in an Activity, what will be the output after a screen rotation?

class MyViewModel : ViewModel() {
  var counter = 0
}

// In Activity
val model = ViewModelProvider(this).get(MyViewModel::class.java)
model.counter += 1
println(model.counter)

medium

A. 1 on first launch, then resets to 0 after rotation

B. 1 on first launch, then increments to 2 after rotation

C. Always prints 0

D. Throws an error on rotation

Solution

1. Step 1: Understand ViewModel data retention

   The ViewModel instance survives configuration changes, so its data like counter is preserved.

2. Step 2: Trace counter increment

   On first launch, counter is 0, incremented to 1 and printed. After rotation, the same ViewModel instance is used, counter is 1, incremented to 2 and printed.

3. Final Answer:

   1 on first launch, then increments to 2 after rotation -> Option B

4. Quick Check:

   ViewModel retains data = increments preserved [OK]

Hint: ViewModel keeps data, so counter increments across rotations [OK]

Common Mistakes:

• Assuming ViewModel resets on rotation
• Thinking counter always starts at 0
• Expecting an error due to rotation

4. What is wrong with this code that tries to use ViewModel in an Activity?

class MyViewModel : ViewModel() {
  var data = "Hello"
}

// In Activity
val model = MyViewModel()
println(model.data)

medium

A. The println statement is incorrect

B. The data variable must be private

C. ViewModel cannot have variables

D. ViewModel should not be instantiated directly; use ViewModelProvider instead

Solution

1. Step 1: Identify ViewModel instantiation error

   ViewModel must be obtained via ViewModelProvider to survive configuration changes, not created with constructor.

2. Step 2: Explain consequence

   Direct instantiation means a new ViewModel is created every time, losing data on rotation.

3. Final Answer:

   ViewModel should not be instantiated directly; use ViewModelProvider instead -> Option D

4. Quick Check:

   Use ViewModelProvider, not constructor [OK]

Hint: Never instantiate ViewModel with constructor directly [OK]

Common Mistakes:

• Creating ViewModel with constructor
• Thinking private variables fix lifecycle issues
• Blaming println for errors

5. You want to keep user input data safe during screen rotations in your app. Which approach best uses ViewModel to achieve this?

hard

A. Store user input in a ViewModel property and update it on every input change

B. Save user input in SharedPreferences and reload after rotation

C. Use static variables in the Activity to hold user input

D. Recreate the ViewModel on each rotation and reset user input

Solution

1. Step 1: Identify best practice for preserving UI data

   ViewModel is designed to hold UI-related data that survives configuration changes like rotations.

2. Step 2: Choose correct data handling method

   Storing user input in a ViewModel property and updating it on input changes keeps data safe and avoids unnecessary disk operations.

3. Final Answer:

   Store user input in a ViewModel property and update it on every input change -> Option A

4. Quick Check:

   ViewModel holds UI data safely across rotations [OK]

Hint: Keep UI data in ViewModel properties updated live [OK]

Common Mistakes:

• Using SharedPreferences for temporary UI data
• Using static variables which can cause leaks
• Recreating ViewModel loses data