android - una - ¿Por qué implementar onDestroy() si no se garantiza que se llame?

ciclo de vida de una aplicacion android ejemplo

Question

De acuerdo con el Ciclo de vida de la actividad de Android, la única devolución de llamada garantizada para ser llamada (si una actividad deja el estado En ejecución, que normalmente se espera) es onPause() .

Por lo tanto, debo suponer que hay escenarios en los que tiene sentido implementar onStop() y onDestroy() aunque en realidad no se garantiza que se onDestroy() .

Entiendo que onStop() debe implementarse cuando es posible que una actividad regrese al estado En ejecución a través del estado Detenido (¿por qué haría eso en lugar de regresar directamente es una pregunta diferente).

Pero la necesidad de onDestroy() , cuando puedo poner toda la limpieza / ahorro de estado en onPause() , no está claro para mí.

¿Puede describir una situación de aplicación real (es decir, no analogía a conducir un automóvil, etc.) en la que tendría sentido implementar onDestroy() ?

Answer 1

¿Puede describir una situación de aplicación real (es decir, no analogía a conducir un automóvil, etc.) en la que tendría sentido implementar onDestroy ()?

Cuando desee capturar un cambio de configuración. Todo está en el SDK: http://developer.android.com/reference/android/app/Activity.html

Answer 2

Se llamará a onDestroy si llama explícitamente a finish (); tú mismo.

Tu actividad principal llama a startActivityForResult en una actividad del mapa.

La actividad del mapa con un LocationListener, el usuario hace clic en el mapa y selecciona, por ejemplo, un restaurante local.

La actividad entonces, configura algunos extras que se enviarán de vuelta a su actividad principal, luego se llamará a finalizar (); en sí mismo y en el onDestroy mata el LocationListener y otras variables que has invocado.

Acabo de encontrar esto en los documentos

onDestroy () = La llamada final que recibe antes de que se destruya su actividad. Esto puede ocurrir ya sea porque la actividad está terminando (alguien llamado finish () en ella o porque el sistema está destruyendo temporalmente esta instancia de la actividad para ahorrar espacio. Puede distinguir entre estos dos escenarios con el método isFinishing ().