Understanding ViewModel during configuration change and how its differnt from creating multiple instance of same activity again.

I was recently curious in understanding how viewmodel is retained during configuration change. There is a viewmodel store owner and it has a hashmap that takes a cannonical name of the activity and the value as viewmodel itself. This view model store owner is retained during configuration change by activity which is the lifecycle owner.

So now we know about that, i wanted to test different scenarious

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:id="@+id/textView"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="TextView"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

    <Button
        android:id="@+id/button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Button"
        app:layout_constraintBottom_toTopOf="@+id/textView"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

    <Button
        android:id="@+id/button2"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Button"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/textView" />
</androidx.constraintlayout.widget.ConstraintLayout>

activity_main.xml is simple view with 2 buttons and one textfield to display hashcode of the view model

class MainActivity : AppCompatActivity() {

    private lateinit var binding: ActivityMainBinding

    private val viewModel by viewModels<MainViewModel>()

    override fun onCreate(savedInstanceState: Bundle?) {
        WindowCompat.setDecorFitsSystemWindows(window, false)
        super.onCreate(savedInstanceState)

        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)

        binding.button.setOnClickListener {
            binding.textView.text = "${viewModel.hashCode()}"
        }

        binding.button2.setOnClickListener {
            startActivity(Intent(this@MainActivity,MainActivity::class.java))
        }
    }
}

The activity code just shows viewmodel hashcode. button2 starts the same MainActivity which is launched usign default standard launch mode.

class MainViewModel: ViewModel() {
}

Viewmodel is simple. It does not have to do anything for the purpose of this test.

Now clicking on button in activity shows hashcode of the viewmodel. This is same after configuration change as well.

But when you start a main activity again, a new instance of it created and viewmodel hashcode is different. This means the viewmodel is tied to isntance of the activity. Note we earlier said that viewmodel store owner has a hashmap with cannonical name of activity being key. Don’t get confused thinking the viewmodel instance will be the same if the same activity is started multiple times. Its always a different instance and viewmodel is tied to instance of the activity when you launch the same activity again.

Even when configuration change happens activity instance is destroyed and new activity instance in created. But viewmodel is retained during configuration change. Below link to the blog explain how that happens.

The Curious Case of Survival of ViewModel

This is one of the famous interview questions to test your understanding of how viewmodel is retained.

Coming to fragments its little different with fragment manager taking over the part of retaining view model.

Conclusion: Learning the internal working mechanism helps you to create better apps by using it in different scanerios and also helps you to show your skills during an interview which is required for the job.