saveInstanceState + restoreInstanceState VS configChanges

I came across two ways to prevent the activity from redrawing whenever the screen is rotated.
One is saveInstanceState + restoreInstanceState combo, which I still haven't been able to successfully implement.

The other one was to declare configChanges attribute in the activity tag of the manifest file to orientation

I'm curious as to what is the difference between the two.

Both of the solutions have to do with data persistence during the lifecycle of your activity. Please read here more regarding LifeCycle

The basic difference is that when your app dies, with the save/restoreInstance combo (there are many different ways to do this) is that you can save the state of your app and when your activity is recreated after it was previously destroyed, you can recover your saved instance state from the Bundle that the system passes to your activity.

configChanges

Lists configuration changes that the activity will handle itself. When a configuration change occurs at runtime, the activity is shut down and restarted by default, but declaring a configuration with this attribute will prevent the activity from being restarted. source

Generally speaking i would suggest to NOT lock orientation in your app with the configChanges attr to prevent your activity from dying. Just save its state and restore through LifeCycle

> I'm curious as to what is the difference between the two.

The difference between saveInstanceState + restoreInstanceState combo and configChanges is that configcahnges attribute in the manifest will prevent the activity from being destroyed when the specified change(s) occurred. In Android when you rotate the device or when the screen size change, the activity will be destroyed and recreated.

saveInstanceState + restoreInstanceState combo will not prevent the activity from being destroyed and recreated. In fact, they will just help you pass the data from the destroyed activity to the one which will be recreated.
Inside saveInstanceState you save all the data you want into a bundle object. Then, inside restoreInstanceState you get these data and use them in the recreated activity.

For example, if I use this attribute inside an activity tag in the Manifest file:

android:configChanges="orientation|screenSize"

Now, this activity won't be destroyed when the screen rotates and all the data of the activity will stay as is because it will not be destroyed.

> saveInstanceState + restoreInstanceState combo, which I still haven't been able to successfully implement.

Here is how saveInstanceState + restoreInstanceState combo work:

Let's say I have a global variable called userScore holding the user scores in a game. Now, I did not use the attribute android:configChanges="orientation|screenSize" in my activity tag, so it will be destroyed if the user rotates the screen and the scores will be lost. To prevent them from being lost I will use saveInstanceState + restoreInstanceState like so:

 @Override
    protected void onSaveInstanceState(@NonNull Bundle outState) {
        outState.putInt("Score", userScore); // saving the userScore value 
        super.onSaveInstanceState(outState);
    }

    @Override
    protected void onRestoreInstanceState(@NonNull Bundle savedInstanceState) {
        userScore = savedInstanceState.getInt("Score"); // restoring the userScore value 
        super.onRestoreInstanceState(savedInstanceState);
    }

In one scenarios you are handling all the
Related configuration changes without activity getting restarted.. while in second you are just taking care of your desired user state variables ie saving and restoring them.

When a configuration change occurs at runtime, the activity is shut down and restarted by default, but declaring a configuration with android:configChanges attribute will prevent the activity from being restarted. Instead, the activity remains running and its onConfigurationChanged() method is called, handling configuration changes your self is a complex task and should be avoided..

It is not recommended to handle configuration changes yourself due to the hidden complexity of handling the configuration changes.

However, if you are unable to preserve your UI state using the preferred options (onSaveInstanceState(), ViewModels, and persistent storage) you can instead prevent the system from restarting your activity during certain configuration changes. Your app will receive a callback when the configurations do change so that you can manually update your activity as necessary.

[Reference link]