¿Por qué super.onDestroy () en java – Android va en la parte superior en los destructores?

¡Soy nuevo en el desarrollo de java! Que alguien me diga … según qué lógica super.onDestroy(); En destructores va en la parte superior? por ejemplo:

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

y no

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

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

    4 Solutions collect form web for “¿Por qué super.onDestroy () en java – Android va en la parte superior en los destructores?”

    Realmente depende de lo que quieras hacer en tu onDestroy . Esto es lo que super.onDestroy hace (en ese orden):

    • Descartar todos los diálogos que la actividad estaba administrando.
    • Cierre todos los cursores que la actividad estaba administrando.
    • Cerrar cualquier diálogo de búsqueda abierto

    Si la lógica que pones dentro de onDestroy tiene algo que ver con esas tres cosas que hace Android, entonces usted puede tener que preocuparse por la orden. De lo contrario, y en la mayoría de los casos, no importa.

    En el ThreadSample.zip en la formación de informes de estado de trabajo , hay un comentario en onDestroy ()

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

    Así que tal vez al usar Broadcast Receivers, el super debe ir al final.

    ¿Cuál es tu pregunta? Puedes hacerlo de cualquier manera, depende si quieres que la superclase sea onDestroy() llamada antes de la tuya. Por lo general, no creo que importe en android.

    Además, onDestroy() no es un destructor. En realidad no destruye el objeto. Es sólo un método que se llama basado en un determinado estado. Así que su instancia sigue viva y muy bien * después de que la superclase de onDestroy() ejecuta y vuelve.

    * Lo más probable, Android es libre de matar la actividad en cualquier momento, pero puede suponer que todavía está allí.

    Dado que nos estamos extendiendo desde las clases base de android, siempre es un buen enfoque dejar que la clase padre se cree e inicialice primero durante la creación y deje al niño desinitializar y liberar el recurso primero durante el apagado / detención de los componentes. Este es el enfoque recomendado que se debe seguir. Sin embargo, depende enteramente de los casos de uso y escenarios.

     public void onCreate(Bundle bundle){ super.onCreate(bundle); //perform child class initializations. } public void onDestroy(){ //perform uninitialization and free resource super.onDestroy(); } 
    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.