60

According to which logic does super.onDestroy(); in destructors goes on top? For example:

protected void onDestroy() {        
    super.onDestroy();
    releaseMediaPlayer();
}

and not:

protected void onDestroy() {        
    releaseMediaPlayer();
    super.onDestroy();
}

Like in c++, obj-c, pascal, etc?

Pika Supports Ukraine
  • 3,612
  • 10
  • 26
  • 42
Vassilis
  • 2,878
  • 1
  • 28
  • 43

4 Answers4

71

It really depends on what you want to do in your onDestroy. This is what super.onDestroy does (in that order):

  • Dismiss any dialogs the activity was managing.
  • Close any cursors the activity was managing.
  • Close any open search dialog

If the logic you put inside onDestroy has something to do with those three things that android does, then you may have to worry about the order. Otherwise, and in most of the cases, it does not matter.

Cristian
  • 198,401
  • 62
  • 356
  • 264
13

In the ThreadSample.zip on the Reporting Work Status training, there is a comment in onDestroy()

public void onDestroy() {
    ...
    // Must always call the super method at the end.
    super.onDestroy();
}

So perhaps when using Broadcast Receivers, the super must go at the end.

Zorfling
  • 451
  • 3
  • 11
  • 6
    It makes sense. If you want to do *anything* you certainly don't want to do it on a half-destroyed (cleaned-up) object. – vbence Jan 25 '15 at 18:15
11

Since we are extending from the base android classes, it is always good approach to let the parent class create and initialize itself first during the creation and let the child uninitialize and free the resource first during shutdown/stopping the components. This is the recommended approach to be followed. however, it entirely depends on the use cases and scenarios.

public void onCreate(Bundle bundle){
   super.onCreate(bundle);
   //perform child class initializations.
}

public void onDestroy(){
   //perform uninitialization and free resource
    super.onDestroy();
}
siva
  • 1,850
  • 13
  • 14
5

What's your question? You can do it either way, it depends if you want your superclass's onDestroy() called before yours. Usually I don't think it matters in android.

Also, onDestroy() isn't a destructor. It doesn't actually destroy the object. It's just a method that's called based on a certain state. So your instance is still alive and very well* after the superclass's onDestroy() runs and returns.

*Most likely, android is free to kill the activity at any time, but you can assume it's still there.

Falmarri
  • 47,727
  • 41
  • 151
  • 191
  • 4
    in c++ for example you destroy the super class after you are done with cleaning up your private objects. if you destroy the super class first, I don't think it is a good practice, I even think that the app will crash since the instance will be destroyed! – Vassilis Dec 12 '10 at 20:05
  • As he said, this isn't a destructor, just telling the component to clean up any state it wants to. The object still remains after the onDestroy() call. Generally the order doesn't matter, and won't cause a crash. – hackbod Dec 13 '10 at 07:21