I was just going through the Android Developer Site, refreshing on the Activity Life cycle, and in each code example, there is a comment beside the super class methods that says "Always call the superclass method first".
Though this makes sense in the creation half cycle: onCreate, onStart and onResume, I'm a little confused as to what is the correct procedure on the destruction half cycle : onPause,onStop,onDestroy.
Destroying the instance specific resources first, before destroying superclass resources that the instance specific resources may depend upon makes sense, not the other way round.But the comments suggest otherwise. What am I missing?
Edit: Since people seem to be getting confused as to the intent in the question, what I want to know is which of the following is correct? AND WHY ?
1.Google suggests
@Override
protected void onStop() {
super.onStop(); // Always call the superclass method first
//my implementation here
}
2.The other way
@Override
protected void onStop() {
//my implementation here
super.onStop();
}
Best Answer
In my opinion: not a single thing.
This answer from Mark (aka CommonsWare on SO) sheds light on the issue: Link - Should the call to the superclass method be the first statement?. But then, you can see the following comment left on his answer:
Back to square one. Okay, let's look at this from another angle. We know that Java Language Specification does not specify an order in which the call to
super.overridenMethod()
must be placed (or if the call must be placed at all).In case of class Activity,
super.overridenMethod()
calls are required and enforced:mCalled
is set to true inActivity.onStop()
.Now, the only detail left to debate on is the ordering.
I also know that both work
Sure. Look at the method body for Activity.onPause():
Whichever way you sandwich the call to
super.onPause()
, you'll be ok. Activity.onStop() has a similar method body. But take a look at Activity.onDestroy():Here, the ordering could possibly matter depending on how your activity is setup, and whether calling
super.onDestroy()
would interfere with the code that follows.As a final word, the statement
Always call the superclass method first
doesn't seem to have much evidence to back it up. What's worse (for the statement) is that the following code has been taken fromandroid.app.ListActivity
:And, from LunarLander sample application included in android sdk:
Summary and worthy mentions:
User Philip Sheard : Provides a scenario where a call to
super.onPause()
must be delayed in case of an Activity started usingstartActivityForResult(Intent)
. Setting the result usingsetResult(...)
aftersuper.onPause()
will not work. He later clarifies on this in the comments to his answer.User Sherif elKhatib : Explains why letting superclass initialize its resources first and destroy its resources last follows from logic:
He goes on to point out: if a child class is suitably isolated (in terms of resource dependency) from the parent class, the
super.X()
calls need not adhere to any order specification.See his answer on this page to read through a scenario where placement of
super.onDestroy()
call does affect the program logic.From an answer by Mark:
Bob Kerns from this thread:
User Steve Benett also brings attention to this:
User Sunil Mishra confirms that order (most likely) does not play a role when calling Activity class' methods. He also claims that calling superclass methods first is considered a best practice. However, I could not corroborate this.
User LOG_TAG : Explains why a call to superclass constructor needs to be the before everything else. In my opinion, this explanation does not add to the question being asked.
End note: Trust, but verify. Most of the answers on this page follow this approach to see if the statement
Always call the superclass method first
has logical backing. As it turns out, it does not; at least, not in the case of class Activity . Generally, one should read through the superclass' source code to determine if ordering calls to super's methods is a requirement.