Friday, March 15, 2013

Activity lifecycle events

It took me quite a bit of trouble to understand Activity lifecycle. I decided to make a practical reference of how the lifecycle callbacks are called. I cover some typical use cases (I think it is quite self explanatory, but if you have question or suggestion how can I make it more readable, please contact me):
  • open activity - press home
  • open activity - press back
  • open activity - rotate activity
  • open activity - rotate activity (with custom handler)
  • open activity - open other activity - press back
  • open activity - open other activity - rotate - press back
  • open activity - open other activity for result - press back
Here is the link to the spreadsheet. And some results of other experiments:
  • onConfigurationChange() is not called when ime (soft keyboard) pops up or hides
  • onConfigurationChange() is called during rotate, if manifest is set so. does min api have to be below 13? if this is called, no lifecycle event will be called (?), however onCreateView is called for each view. - no. it is called even with min api level set to 13
  • when to use onRetainNonConfigurationInstance()? - when you want to preserve activity when configuration changes (keep a music decoder running)
  • will onPause be called, when an alert dialog appears? notificaion bar is dragged down? - no. no. it will be called though when a dialog (full screen activity, but in that case onStop will be called also) of an other application is started eg. by taping on it in notifiation bar. And onSaveInstanceState() will be called also.
  • onRestoreInstanceState() is only called, when onSaveInstanceState() returns non empty bundle? - no, it gets called all times
  • Will onDestroy() be called if the app is removed from the recent task list? - yes. (mostly :-) we have to get used to this framework feature is purposedly unreliable)
  • onSaveInstanceState saves a bundle. when this bundle is returned? does it override intent bundle? what is the difference if android:stateNotNeeded is set in manifest? - rather not do anything with android:stateNotNeeded flag, because it is yet another special solution for yet another marginal problem. But! saveInstanceState saves a bundle indeed. This bundle is given to onCreate() as an argument. This is null, if the activity is newly started (or backpress and start again). It is not null otherwise (mostly when it is being rebuilt after a configuration change (eg. rotation). Remember that, onCreate is not called when the activity only goes to background normally. But, if the framework calls onDestroy() eg. because of a memory shortage, the onCreate() will be called and this argument will be not null). You can try to get non existing values from it, you will get the default value (0 in case of int, false in case of boolean, etc). Intent extras are different. You can set extras when starting an activity. You can call intent.putExtra() overloads. There is a putExtras(Bundle) call also, but this bundle has nothing to do with saveInstanceState argument. These extras can be retrieved from the new activity with getIntent().getXXXExtra(String, defaultValue) (where XXX can be Int, Boolean, etc.). This cal will always return something, even if non existing key is requested, because a default value has to be provided.

No comments: