Pourquoi super.onDestroy () en java-Android va sur le dessus dans les destructeurs? [dupliquer]

cette question a déjà une réponse ici:

je suis nouveau dans le développement de java! Quelqu'un peut-il me dire... selon quelle logique super.onDestroy(); les destructeurs vont au-dessus? par exemple:

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

et non

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

comme c++, obj-c, pascal, etc ??

41
demandé sur teoREtik 2010-12-12 22:53:54

4 réponses

Cela dépend vraiment de ce que vous voulez faire dans votre onDestroy . C'est ça le super.onDestroy fait (dans cet ordre):

  • rejeter tout dialogue que l'activité gérait.
  • fermez les curseurs que l'activité gérait.
  • Fermer tout dialogue de recherche ouvert

si la logique que vous mettez à l'intérieur onDestroy a quelque chose à voir avec ces trois choses que android fait, alors vous peut avoir à vous soucier de l'ordre. Sinon, et dans la plupart des cas, il n'a pas d'importance.

55
répondu Cristian 2010-12-12 20:01:03

dans L'exemple thread.zip sur le Déclaration de Statut de Travail à la formation , il y a un commentaire dans onDestroy()

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

alors peut-être qu'en utilisant des récepteurs de radiodiffusion, le super doit aller à la fin.

7
répondu Zorfling 2014-05-26 23:05:49

Quelle est votre question? Vous pouvez le faire de toute façon, cela dépend si vous voulez que votre superclass onDestroy() soit appelé avant le vôtre. D'habitude, je pense que ça n'a pas d'importance avec Androïde.

Also, onDestroy() n'est pas un destructeur. Il ne fait pas de détruire l'objet. C'est juste une méthode qui est basée sur un certain état. Donc votre instance est toujours vivante et très bien* après les runs et retours du onDestroy() de superclass.

* très probablement, android est libre de tuer l'activité à tout moment, mais vous pouvez supposer qu'il est toujours là.

5
répondu Falmarri 2010-12-12 20:12:04

puisque nous nous étendons à partir des classes android de base, il est toujours bon de laisser la classe parent créer et s'initialiser en premier lors de la création et laisser l'enfant uninitialiser et libérer la ressource en premier lors de l'arrêt/arrêt des composants. C'est la démarche à suivre. cependant, cela dépend entièrement des cas d'utilisation et des scénarios.

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

public void onDestroy(){
   //perform uninitialization and free resource
    super.onDestroy();
}
4
répondu 7383 2016-02-25 14:50:42