5.6.- Programación en Android: El ciclo de la vida - primera parte

5.6.- Programación en Android: El ciclo de la vida – primera parte.

Habíamos dejado pendiente hablar sobre el ciclo de la vida de las activitys en android, y vamos a verlo con una imagen y posteriormente (5.6.1) con un pequeño y sencillo ejemplo, que además nos servirá para mirar como funciona la clase log.

Las actividades atienden a varios mensajes del sistema mediante retrollamadas (callback) desde que comienzan a ejecutarse hasta que finalizan.

Dado que la vida de una activity está relacionada o afectada por otras activities, por sus tareas y por las tareas predecesoras, puede cambiar de estado (y cambia) a menudo, y nosotros debemos escuchar los mensajes del sistema para atender a los estados en los que se haya nuestra activity y actuar en consecuencia (por ejemplo, guardar todas las variables de interés cuando nos vamos al estado de parados (stopped).

En actividad puede existir básicamente en tres estados:

Resumed (En ejecución): La actividad (activity) está en primer plano de la pantalla y tiene el foco.

Paused (En pausa): Otra actividad está en primer plano y tiene el foco, pero la nuestra todavía es visible. Por ejemplo, cuando otra actividad es visible por encima de la nuestra, y esa actividad es parcialmente transparente o no cubre toda la pantalla. Una actividad en el estado de pausa está completamente viva: el objeto activity está en memoria, mantiene toda la información de los estados y de los miembros, y permanece conectada al gestor de ventanas, pero puede ser eliminada (killed) por el sistema en situaciones en las que disponga de muy poca memoria.

Stopped (parada): La actividad está totalmente tapada por otra actividad que está en primer plano, y la nuestra está en segundo plano o background. Una actividad en este estado, todavía está viva: el objeto activity está en memoria, mantiene toda la información de los estados y de los miembros, pero no está conectada al gestor de ventanas. Sin embargo ya no es visible, y el sistema puede borrarla cuando necesite memoria para cualquier cosa.

Si una actividad está parada o en pausa, el sistema puede quitarla de la memoria a través de su método finish(), o simplemente matando el proceso. Cuando la actividad se vuelve a abrir después de haber sido finalizada o matada, debe volver a crearse.

Implementar los métodos para atender las llamadas callbacks

Los callbacks son métodos con los que nuestra actividad atiende a los mensajes con los que el sistema notifica a la aplicación sus cambios de estado (y otros eventos). Todos los métodos de callback son conexiones que podemos modificar/anular (override) para realizar el trabajo adecuado cuando cambia el estado de nuestra actividad.

Veamos el ejemplo que nos muestra la ayuda del SDK de android:

public class ExampleActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // La actividad está siendo creada.
    }
    @Override
    protected void onStart() {
        super.onStart();
        // La actividad está a punto de hacerse visible.
    }
    @Override
    protected void onResume() {
        super.onResume();
        // La actividad se ha vuelto visible (está ejecutándose, o "resumed")
    }
    @Override
    protected void onPause() {
        super.onPause();
        // Otra actividad está cogiendo el foco. (La actividad está a punto de

        // estar en pausa, "paused").
    }
    @Override
    protected void onStop() {
        super.onStop();
        // La actividad ya no es visible. Ahora está parada ("stopped").
    }
    @Override
    protected void onDestroy() {
        super.onDestroy();
        // La actividad está a punto de ser destruida
    }
}

Hay que recordar que si implementamos estos callbacks debemos llamar antes a la implementación ofrecida por la superclase.

Todos los métodos que hay en ese ejemplo definen todo el ciclo de la vida de una actividad en android. Hay tres grupos fundamentales en el ciclo de la aplicación:

Todo el ciclo de la vida de una aplicación ocurre entre la llamada a onCreate() y la llamada a onDestroy(). La actividad debe de hacer la configuración de todos los estados globales, como definir el layout (diseño), en el método onCreate(), y liberar todos los recursos en el método onDestroy().

El ciclo de vida en que es visible la actividad ocurre entre la llamada a onStart() y la llamada a onStop(). Durante este tiempo el usuario puede ver la actividad en la pantalla e interactuar con ella. Por ejemplo podríamos registrar un BroadcastReceiver en onStart() y desregistrarlo/liberarlo en onStop(). El sistema llamará varias veces a estos métodos durante el ciclo de vida de nuestra aplicación, como podremos ver en el próximo capítulo (5.6.1)

El ciclo de vida en primer plano de la actividad ocurre entre la llamada a onResume() y la llamada a onPause(). En este tiempo la actividad está en el primer plano de todas las demás actividades en pantalla y tiene el foco de entrada del usuario. Una actividad puede pasar frecuentemente de primer a segundo plano. Por ejemplo, cuando se llama a onPause() porque se muestra una ventana de diálogo. Como este estado puede tener cambios muy frecuentes, es recomendable que el código en estos métodos no esté muy sobrecargado, con el fin de evitar transiciones lentas que hagan esperar al usuario.

Guardando el estado de la actividad.

Habíamos comentado que cuando una actividad se pausa o se para, el estado de la actividad se retiene, porque el objeto de la actividad todavía está en memoria. Sin embargo, cuando el sistema destruye la actividad para recuperar memoria, se destruye el objeto activity, y perdemos el estado de nuestra actividad. Así cuando el sistema tenga que volver a recrear nuestra actividad (si el usuario navega de vuelta a ella), no sabe que ha sido destruída y espera encontrarse los datos como los había dejado. En estas situaciones, nosotros podemos asegurarnos de guardar la información relevante sobre el estado de la actividad implementando un método de retrollamada (callback) que nos permita guardar la información sobre el estado de la actividad y recuperarla cuando se vuelve a crear dicha actividad.

Este método de retrollamada es onSaveInstanceState(), es llamado por el sistema antes de que la actividad sea destruída y le pasa un objeto tipo Bundle. En Bundle es donde podremos guardar la información sobre la actividad como pares de nombre-valor, utilizando métodos como putString(). Así cuando el sistema mata al proceso de nuestra actividad y el usuario vuelve, el sistema pasa el objeto Bundle al método onCreate() para que nosotros podamos recuperar el estado de la actividad previamente guardado en onSaveInstanceState(). Si no hay información para restaurar se pasa null.

Nota: No hay garantías de que la función onSaveInstanceState() sea llamada antes de destruir la actividad, ya que hay casos en los que no será necesario guardar el estado, por ejemplo si es el usuario el que abandona la actividad pulsando el botón de atras (back), ya que está cerrando explícitamente la actividad. Si se llama al método es siempre antes de onStop(), y posiblemente después de onPause().

Sin embargo, aunque no implementemos onSaveInstanceState(), algunos estados de la actividad son recuperados por la implementación por defecto de dicho método. La implementación por defecto llama a onSaveInstanceState() para cada vista (view) en el layout que permita dar información sobre que guardar. Casi todos los widgets de android implementan este metodo de la forma adecuada, así que cualquier cambio visible a la intarfaz de usuario es automáticamente guardada y recuperara cuando se recrea la actividad.

Ver. 1.0 – Revisión 6.1.2012