The activity?s life cycle starts with this method. In this method you should load your view hierarchies by loading the layouts into the content view of the activity. You also initialize any activity level variables that may be used during the life time of the activity. Like many of the callbacks you also call the parent?s onCreate() method first.
When onCreate is called an activity may be in one of 3 states. The activity may have been a brand new activity starting out its life for the first time. Or it may be an activity that is automatically restarted because of a configuration change such a device rotating from one orientation to another. Or it is an activity that is restarted following a previous process shutdown due to low memory memory conditions and being in the background. In the onCreate callback you should take these scenarios into account if what you need to do in each scenario is different.
Now we can understand the argument to this method the savedInstanceBundle. You can use this bundle to look into the previous state of the activity. This bundle may have been originally used to save the state of the activity during a configuration change or when the activity and its process shutdown due to low memory conditions. The state that is saved into this bundle argument is usually called the instance state of the activity. The instance state is somewhat temporary in nature that is tied to this instance of the application during this invocation. This type of state is not expected to be written to permanent storage like files. The user will not be too disconcerted if this state is to revert to an initial state when the application is revived. The callback we will explain soon the onPause() is used, if demanded by the application, to save the state that must be persisted to long term storage. If that happens you may want to use the onCreate() method to load that state as well as part of the start up.
There is another consideration that this method can take into account. When an activity is restarted or recrated because of an orientation change the old activity is destroyed and a new activity is created in its place. This means the new activity has a new reference in memory. The old activity reference is no longer valid. If there is an external thread or a global object that is holding on to the old activity, that would be wrong. So there needs to be a mechanism when the activity is recreated to tell the external object that there is a new activity reference. To do that, the recreated activity needs to know the reference of that external object. This external object reference is called ?non configuration instance reference?. There is a callback method, which we will shortly cover, called onRetainNonConfigurationInstance() that can return a reference to this external object. Android SDK then keeps this reference and makes it available to the recreated activity through a method called getLastNonConfigurationInstance(). You can also do this with headless fragments.
There is another nuance to the onCreate method. You may want to ensure that in the layouts you have right views and fragments (which you will learn in the fragments chapter) to match when the state was saved. Because a subsequent onRestoreInstanceState() (which is called after onStart) assumes that all the view and fragment hierarchies are present to restore their respective state. Mere presence of previous state will not recreate the views. So it is up to this method to load the right layouts to be shown. This is usually not an issue if you don?t delete or add views during the interaction with the activity.
satya - 5/9/2014 1:21:47 PM
Understand more about activity life cycle