2. Now we will declare an instance of ViewModel in our Fragment. Now many of you, who are new to this concept of ViewModels might be wondering, as ViewModel is just a class, we can simply declare an instance of the ViewModel and access public variables in our Activity/Fragment.
Something like -:

Cool and easy right? NOOO. This will not throw an error, but it will not fill our purpose of retaining counter value on configuration changes. That’s not how ViewModel works. We need something called a ViewModelProvider to create a ViewModel. The correct way to create a ViewModel is -:

Here you can see that we pass something called ViewModelStoreOwner. But in our Activity, we pass this while instantiating our ViewModelProvider.

ViewModelProvider(this)[MainActivityViewModel::class.java]

But from where did this ViewModelStoreOwner come from in our Activity? If we check the source code of Activity class, it can be noticed that the Activity class implements the ViewModelStoreOwner interface.

public class ComponentActivity extends androidx.core.app.ComponentActivity implements
        ContextAware,
        LifecycleOwner,
        ViewModelStoreOwner,
        HasDefaultViewModelProviderFactory,
        SavedStateRegistryOwner,
        OnBackPressedDispatcherOwner,
        ActivityResultRegistryOwner,
        ActivityResultCaller

We are close!! Now we are clear that ViewModelStoreOwner is doing something which is helping the ViewModelProvider return the same instance of ViewModel which was present before the configuration change.

The responsibility of an implementation of the interface ViewModelStoreOwner is to retain owned ViewModelStore during the configuration changes and call ViewModelStore.clear(), when this scope is going to be destroyed.

public interface ViewModelStoreOwner {
    /**
     * Returns owned {@link ViewModelStore}
     *
     * @return a {@code ViewModelStore}
     */
    @NonNull
    ViewModelStore getViewModelStore();
}

Let’s dig further deep into the implementation of the getViewModelStore()in our Activity and see what it does.

@NonNull
@Override
public ViewModelStore getViewModelStore() {
    if (getApplication() == null) {
        throw new IllegalStateException("Your activity is not yet attached to the "
                + "Application instance. You can't request ViewModel before onCreate call.");
    }
    ensureViewModelStore();
    return mViewModelStore;
}

If the activity is not created, it returns throwing an error, but if it is it called the ensureViewModelStore() method.

void ensureViewModelStore() {
    if (mViewModelStore == null) {
        NonConfigurationInstances nc =
                (NonConfigurationInstances) getLastNonConfigurationInstance();
        if (nc != null) {
            // Restore the ViewModelStore from NonConfigurationInstances
            mViewModelStore = nc.viewModelStore;
        }
        if (mViewModelStore == null) {
            mViewModelStore = new ViewModelStore();
        }
    }
}

I promise we’re close to the end. Stay tuned if you have reached till here!!!
This method, ensureViewModelStore() initially checks for if the viewModelStore is null, then it declares an instance of a class called NonConfigurationInstances, which basically checks for if the instance of mViewModelStore is already present, if it is, then it returns the same instance otherwise a new instance of ViewModelStore() is returned.

You might be wondering now that how come NonConfigurationInstances class is able return the old instance of ViewModelStore, which was present before the configuration change? Shouldn’t this be destroyed as well with the Activity?

if (nc != null) {
            // Restore the ViewModelStore from NonConfigurationInstances
            mViewModelStore = nc.viewModelStore;
        }

The answer is no because NonConfigurationInstances is a static class. We all know that static classes object are not bound to any activity or fragment. It remains in the memory as long as the app is in the memory, or till it is cleared manually or programatically.

static final class NonConfigurationInstances {
    Object custom;
    ViewModelStore viewModelStore;
}

OK! so NonConfigurationInstances, a singleton class, is able to return an old instance of the ViewModelStore, which was present before the configuration change, and that is how our instance and ultimately our data is restored. Makes sense.

But the last question, and I BET IT IS THE LAST is that how this static class knows when to destroy the ViewModelStore instance and when to not??The answer lies in the default constructor of this activity class.

getLifecycle().addObserver(new LifecycleEventObserver() {
    @Override
    public void onStateChanged(@NonNull LifecycleOwner source,
            @NonNull Lifecycle.Event event) {
        if (event == Lifecycle.Event.ON_DESTROY) {
            // Clear out the available context
            mContextAwareHelper.clearAvailableContext();
            // And clear the ViewModelStore
            if (!isChangingConfigurations()) {
                getViewModelStore().clear();
            }
        }
    }
});

Inside the onStateChanged() method, which is called whenever the state of the activity changes, every time onDestroy() is called, it checks if it is because of the configuration change or not??? If not, it simply clears the instance of ViewModelStore from memory and a new instance gets created next time. If the call to onDestroy() is due to the configuration changes, it does not destroy the instance of ViewModelStore from static class. This is how ViewModelProvider differentiates between onDestroy()due to configuration change and onDestroy() due to Activity being permanently destroyed.

Yayy!!! Finally we revealed the magical powers of ViewModel and ViewModelProvider. Now we can also create our own implementation of ViewModel. Thanks for reading this long but insightful article. Please share your feedback in comments if you found it helpful or not.