Android Activity instance state

Question

What is the significance of:

super.onCreate(null);

instead of

super.onCreate(savedInstanceState);

With this change, I am able to avoid many problems that otherwise plague my Activitys each time a configuration change occurs (rotation, locale shift, permission toggle). It seems that with this change, the Activity is started afresh whenever a configuration change triggers it to restart. And I don't seem to lose any data or process state by doing this: all my Activitys are restored exactly to their former state.

My question is, can I do this with impunity henceforth, or am losing something in the bargain? I don't really understand why this works, whether it is safe or not, and what unintended effects it may have on my app.

I chanced upon this trick here.

Related Questions:

Calling super.onCreate() with null parameter?

Will 'Bundle savedInstanceState' be alive after Application is being killed?

Activity state instance - insights?

Activity's instance state: what is automatically stored and restored

Answer 1

onCreate() call first when activity is about to create, Also Android System manage activity lifecycle and can kill the activity with saving its instanceState, in case if acitvity out of focus for user for long time and system is on low memory situation.

An activity has essentially four states

super.onCreate(null) : Would always create activity as it is creating fisrt time , even Android system provide its savedInstanceState, and does't matter what orientation configurations are.

super.onCreate(savedInstanceState) : Activity can use 'savedInstanceState' to reset its state or component where it was last.

To achive this, acitivty's instance state need to be persist before activity lost user attention( that could be onStop or onDestroy)

savedInstaceState can also be important to handle if activity configuration got changed, Please check acitvity life cycle behavior on Configuration change

Answer 2

am losing something in the bargain?

Only if you are working with Fragments. see Calling super.onCreate() with null parameter?

Yes, onCreate(...) is necessary to start an Activity, but passing Bundle as an argument is required when you are working with fragments.

What did you infer from that?

The argument savedInstanceState is anyway null by default. So you aren't really losing anything in a bargain.

But wait, we usually use Bundles to maintain orientation change, right?

the following manifest code declares an activity that handles both the screen orientation change and keyboard availability change:

<activity android:name=".MyActivity"
          android:configChanges="orientation|keyboardHidden"
          android:label="@string/app_name">

Now, when one of these configurations change, MyActivity does not restart. Instead, the MyActivity receives a call to onConfigurationChanged(). This method is passed a Configuration object that specifies the new device configuration. By reading fields in the Configuration, you can determine the new configuration and make appropriate changes by updating the resources used in your interface. At the time this method is called, your activity's Resources object is updated to return resources based on the new configuration, so you can easily reset elements of your UI without the system restarting your activity.

the following onConfigurationChanged() implementation checks the current device orientation:

@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);

    // Checks the orientation of the screen
    if (newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) {
        Toast.makeText(this, "landscape", Toast.LENGTH_SHORT).show();
    } else if (newConfig.orientation == Configuration.ORIENTATION_PORTRAIT){
        Toast.makeText(this, "portrait", Toast.LENGTH_SHORT).show();
    }
}

But Remember: When you declare your activity to handle a configuration change, you are responsible for resetting any elements for which you provide alternatives. If you declare your activity to handle the orientation change and have images that should change between landscape and portrait, you must re-assign each resource to each element during onConfigurationChanged().

Answer 3

As far as I know a lot of data is saved in the bundle savedInstanceState. E.g. all the views' states in your current layout, such as the current content of any EditText or CheckBox.

You could also look up some official sources to check whether you need to keep some data.

Here's a nice article about it

Basically it says that all View class implements the methods onRestoreInstanceState and onSaveInstanceState, which are saving and restoring any temporary states they were in before the state change.

Answer 4

The savedInstanceState is a reference to a Bundle object that is passed into the onCreate method of every Android Activity. Activities have the ability, under special circumstances, to restore themselves to a previous state using the data stored in this bundle.

It is very important to use savedInstantState to get values from Intent which is saved in the bundle.

Answer 5

All your data stored in class variables or local variables is lost whenever you change rotation of device, but in your activity it looks like you have not stored any data as long as user enters any data, but instead you are perhaps reading data on click of a button or something like that, your activity will behave and work normally, and all user inputs like text inside EditText will be restored by Android itself, because it identifies "IDs" (android:id="@+id/anyID") allotted to each view and can restore by itself all the values inserted by user.

I hope this this helps you...

Happy coding :)