Ciclo de vida de la actividad

Las actividades son un bloque de creación fundamental de aplicaciones Android y pueden existir en varios estados diferentes. El ciclo de vida de la actividad comienza con la creación de instancias y termina con la destrucción, e incluye muchos estados entre ellos. Cuando una actividad cambia de estado, se llama al método de evento de ciclo de vida adecuado, notificando la actividad del cambio de estado inminente y permitiendo que el código se adapte a ese cambio. En este artículo se examina el ciclo de vida de las actividades y se explica la responsabilidad de que una actividad tenga durante cada uno de estos cambios de estado para formar parte de una aplicación confiable y bien comportada.

Información general sobre el ciclo de vida de la actividad

Las actividades son un concepto de programación inusual específico de Android. En el desarrollo de aplicaciones tradicional, normalmente hay un método principal estático, que se ejecuta para iniciar la aplicación. Sin embargo, con Android, las cosas son diferentes; Las aplicaciones Android se pueden iniciar a través de cualquier actividad registrada dentro de una aplicación. En la práctica, la mayoría de las aplicaciones solo tendrán una actividad específica especificada como punto de entrada de la aplicación. Sin embargo, si una aplicación se bloquea o el sistema operativo finaliza, el sistema operativo puede intentar reiniciar la aplicación en la última actividad abierta o en cualquier otro lugar de la pila de actividad anterior. Además, el sistema operativo puede pausar las actividades cuando no están activas y reclamarlas si está poco en memoria. Se debe tener en cuenta detenidamente que la aplicación pueda restaurar correctamente su estado en caso de que se reinicie una actividad, especialmente si esa actividad depende de los datos de las actividades anteriores.

El ciclo de vida de la actividad se implementa como una colección de métodos que el sistema operativo llama a lo largo del ciclo de vida de una actividad. Estos métodos permiten a los desarrolladores implementar la funcionalidad necesaria para satisfacer los requisitos de administración de recursos y estado de sus aplicaciones.

Es muy importante que el desarrollador de aplicaciones analice los requisitos de cada actividad para determinar qué métodos expuestos por el ciclo de vida de la actividad deben implementarse. Si no se hace esto, la inestabilidad de la aplicación, los bloqueos, la saturación de recursos y, posiblemente, incluso la inestabilidad subyacente del sistema operativo.

En este capítulo se examina el ciclo de vida de la actividad con detalle, entre los que se incluyen:

  • Estados de actividad
  • Métodos de ciclo de vida
  • Conservar el estado de una aplicación

En esta sección también se incluye un tutorial que proporciona ejemplos prácticos sobre cómo guardar de forma eficaz el estado durante el ciclo de vida de la actividad. Al final de este capítulo, debe comprender el ciclo de vida de la actividad y cómo admitirlo en una aplicación Android.

Ciclo de vida de la actividad

El ciclo de vida de la actividad de Android consta de una colección de métodos expuestos dentro de la clase Activity que proporciona al desarrollador un marco de administración de recursos. Este marco permite a los desarrolladores cumplir los requisitos de administración de estado únicos de cada actividad dentro de una aplicación y controlar correctamente la administración de recursos.

Estados de actividad

El sistema operativo Android arbitra actividades en función de su estado. Esto ayuda a Android a identificar las actividades que ya no están en uso, lo que permite al sistema operativo reclamar memoria y recursos. En el diagrama siguiente se muestran los estados a los que puede pasar una actividad durante su vigencia:

Diagrama de estados de actividad

Estos estados se pueden dividir en 4 grupos principales de la siguiente manera:

  1. Activo o En ejecución : las actividades se consideran activas o en ejecución si están en primer plano, también conocidas como la parte superior de la pila de actividad. Esto se considera la actividad de prioridad más alta en Android y, como tal, solo lo eliminará el sistema operativo en situaciones extremas, como si la actividad intenta usar más memoria de la que está disponible en el dispositivo, ya que esto podría hacer que la interfaz de usuario deje de responder.

  2. Pausado : cuando el dispositivo entra en suspensión, o una actividad sigue siendo visible pero parcialmente oculta por una actividad nueva, no de tamaño completo o transparente, la actividad se considera pausada. Las actividades en pausa siguen activas, es decir, mantienen toda la información de estado y miembro y permanecen adjuntas al administrador de ventanas. Esto se considera la segunda actividad de prioridad más alta en Android y, como tal, solo la matará el sistema operativo si la eliminación de esta actividad cumplirá los requisitos de recursos necesarios para mantener estable y con capacidad de respuesta la actividad activa/en ejecución.

  3. Detenido/En segundo plano : las actividades que están completamente ocultas por otra actividad se consideran detenidas o en segundo plano. Las actividades detenidas siguen intentando conservar su información de estado y miembro durante tanto tiempo como sea posible, pero las actividades detenidas se consideran la prioridad más baja de los tres estados y, como tal, el sistema operativo eliminará primero las actividades en este estado para satisfacer los requisitos de recursos de las actividades de mayor prioridad.

  4. Reiniciado : es posible que Android quite de la memoria una actividad que esté en cualquier lugar desde pausado hasta detenido en el ciclo de vida. Si el usuario vuelve a la actividad que se debe reiniciar, restaure a su estado guardado previamente y, a continuación, se muestre al usuario.

Re-Creation de actividad en respuesta a los cambios de configuración

Para que sea más complicado, Android inicia una llave más en la combinación denominada Cambios de configuración. Los cambios de configuración son ciclos rápidos de destrucción o re-creación de actividades que se producen cuando cambia la configuración de una actividad, como cuando se gira el dispositivo (y la actividad necesita volver a compilarse en modo horizontal o vertical), cuando se muestra el teclado (y la actividad se presenta con la oportunidad de cambiar el tamaño), o cuando el dispositivo se coloca en un dock, entre otros.

Los cambios de configuración siguen causando los mismos cambios de estado de actividad que se producirían durante la detención y reinicio de una actividad. Sin embargo, para asegurarse de que una aplicación se siente con capacidad de respuesta y funciona bien durante los cambios de configuración, es importante que se controlen lo antes posible. Por este motivo, Android tiene una API específica que se puede usar para conservar el estado durante los cambios de configuración. Trataremos esto más adelante en la sección Administración del estado a lo largo del ciclo de vida .

Métodos de ciclo de vida de actividad

Android SDK y, por extensión, el marco de Xamarin.Android proporciona un modelo eficaz para administrar el estado de las actividades dentro de una aplicación. Cuando el estado de una actividad cambia, el sistema operativo notifica la actividad, que llama a métodos específicos en esa actividad. En el diagrama siguiente se muestran estos métodos en relación con el ciclo de vida de la actividad:

Diagrama de flujo del ciclo de vida de la actividad

Como desarrollador, puede controlar los cambios de estado invalidando estos métodos dentro de una actividad. Sin embargo, es importante tener en cuenta que se llama a todos los métodos de ciclo de vida en el subproceso de la interfaz de usuario y impedirá que el sistema operativo realice el siguiente trabajo de interfaz de usuario, como ocultar la actividad actual, mostrar una nueva actividad, etc. Por lo tanto, el código de estos métodos debe ser lo más breve posible para que una aplicación se sienta bien funcionando. Todas las tareas de larga duración se deben ejecutar en un subproceso en segundo plano.

Vamos a examinar cada uno de estos métodos de ciclo de vida y su uso:

OnCreate

OnCreate es el primer método al que se llamará cuando se crea una actividad. OnCreate siempre se invalida para realizar las inicializaciones de inicio que pueda requerir una actividad como:

  • Creación de vistas
  • Inicialización de variables
  • Enlace de datos estáticos a listas

OnCreate toma un parámetro Bundle , que es un diccionario para almacenar y pasar información de estado y objetos entre actividades Si el lote no es null, esto indica que la actividad se está reiniciando y debe restaurar su estado de la instancia anterior. En el código siguiente se muestra cómo recuperar valores de la agrupación:

protected override void OnCreate(Bundle bundle)
{
   base.OnCreate(bundle);

   string intentString;
   bool intentBool;

   if (bundle != null)
   {
      intentString = bundle.GetString("myString");
      intentBool = bundle.GetBoolean("myBool");
   }

   // Set our view from the "main" layout resource
   SetContentView(Resource.Layout.Main);
}

Una vez OnCreate que haya terminado, Android llamará a OnStart.

OnStart

El sistema siempre llama a OnStart una vez OnCreate finalizado. Las actividades pueden invalidar este método si necesitan realizar tareas específicas justo antes de que una actividad sea visible, como actualizar los valores actuales de las vistas dentro de la actividad. Android llamará OnResume inmediatamente después de este método.

OnResume

El sistema llama a OnResume cuando la actividad está lista para empezar a interactuar con el usuario. Las actividades deben invalidar este método para realizar tareas como:

  • Aumentar las velocidades de fotogramas (una tarea común en el desarrollo de juegos)
  • Inicio de animaciones
  • Escucha de actualizaciones de GPS
  • Mostrar las alertas o diálogos pertinentes
  • Conexión de controladores de eventos externos

Por ejemplo, el siguiente fragmento de código muestra cómo inicializar la cámara:

protected override void OnResume()
{
    base.OnResume(); // Always call the superclass first.

    if (_camera==null)
    {
        // Do camera initializations here
    }
}

OnResume es importante porque cualquier operación realizada en debe desa realizarse en OnPauseOnResume, ya que es el único método de ciclo de vida que se garantiza que se ejecuta después OnPause de volver a poner en marcha la actividad.

OnPause

Se llama a OnPause cuando el sistema está a punto de colocar la actividad en segundo plano o cuando la actividad se oculta parcialmente. Las actividades deben invalidar este método si necesitan:

  • Confirmación de cambios no guardados en datos persistentes

  • Destruir o limpiar otros objetos que consumen recursos

  • Aumentar las velocidades de fotogramas y pausar animaciones

  • Anule el registro de controladores de eventos externos o controladores de notificación (es decir, los que están vinculados a un servicio). Esto se debe hacer para evitar pérdidas de memoria de actividad.

  • Del mismo modo, si la actividad ha mostrado diálogos o alertas, deben limpiarse con el .Dismiss() método .

Por ejemplo, el siguiente fragmento de código liberará la cámara, ya que la actividad no puede usarla mientras está en pausa:

protected override void OnPause()
{
    base.OnPause(); // Always call the superclass first

    // Release the camera as other activities might need it
    if (_camera != null)
    {
        _camera.Release();
        _camera = null;
    }
}

Hay dos métodos de ciclo de vida posibles a los que se llamará después OnPausede :

  1. OnResume se llamará si se va a devolver la actividad al primer plano.
  2. OnStop se llamará si la actividad se coloca en segundo plano.

OnStop

Se llama a OnStop cuando la actividad ya no es visible para el usuario. Esto sucede cuando se produce una de las siguientes acciones:

  • Se está iniciando una nueva actividad y se trata de esta actividad.
  • Se está llevando una actividad existente al primer plano.
  • La actividad se está destruyendo.

OnStop es posible que no siempre se llame a en situaciones de poca memoria, como cuando Android está muerto de hambre para los recursos y no puede en segundo plano correctamente la actividad. Por este motivo, es mejor no confiar en OnStop llamarse al preparar una actividad para la destrucción. Los siguientes métodos de ciclo de vida que se pueden llamar después de este serán OnDestroy si la actividad desaparece o OnRestart si la actividad vuelve a interactuar con el usuario.

OnDestroy

OnDestroy es el método final al que se llama en una instancia de Activity antes de que se destruya y se quite completamente de la memoria. En situaciones extremas, Android puede matar el proceso de aplicación que hospeda la actividad, lo que provocará OnDestroy que no se invoque. La mayoría de las actividades no implementarán este método porque la mayoría de las tareas de limpieza y apagado se han realizado en los OnPause métodos y OnStop . Normalmente, el OnDestroy método se invalida para limpiar tareas de larga duración que podrían perder recursos. Un ejemplo de esto podría ser subprocesos en segundo plano que se iniciaron en OnCreate.

No se llamará a ningún método de ciclo de vida después de que se haya destruido la actividad.

OnRestart

Se llama a OnRestart después de detener la actividad, antes de que se vuelva a iniciar. Un buen ejemplo de esto sería cuando el usuario presiona el botón inicio mientras se encuentra en una actividad de la aplicación. Cuando esto sucede OnPause y, a continuación OnStop , se llama a los métodos y la actividad se mueve a segundo plano, pero no se destruye. Si el usuario restaurara la aplicación mediante el administrador de tareas o una aplicación similar, Android llamará al OnRestart método de la actividad.

No hay directrices generales para qué tipo de lógica se debe implementar en OnRestart. Esto se debe OnStart a que siempre se invoca independientemente de si se crea o se reinicia la actividad, por lo que los recursos necesarios para la actividad se deben inicializar en , en OnStartlugar de OnRestart.

El siguiente método de ciclo de vida al que se llama después OnRestart será OnStart.

Atrás frente a Inicio

Muchos dispositivos Android tienen dos botones distintos: un botón "Atrás" y un botón "Inicio". Se puede ver un ejemplo de esto en la siguiente captura de pantalla de Android 4.0.3:

Botones Atrás y Inicio

Hay una diferencia sutil entre los dos botones, aunque parecen tener el mismo efecto de colocar una aplicación en segundo plano. Cuando un usuario hace clic en el botón Atrás, le indica a Android que ha terminado con la actividad. Android destruirá la actividad. Por el contrario, cuando el usuario hace clic en el botón Inicio, la actividad se coloca simplemente en segundo plano: Android no eliminará la actividad.

Administración del estado a lo largo del ciclo de vida

Cuando se detiene o destruye una actividad, el sistema ofrece la oportunidad de guardar el estado de la actividad para su rehidratación posterior. Este estado guardado se conoce como estado de instancia. Android proporciona tres opciones para almacenar el estado de la instancia durante el ciclo de vida de la actividad:

  1. Almacenar valores primitivos en un Dictionary conocido como paquete que Android usará para guardar el estado.

  2. Crear una clase personalizada que contenga valores complejos, como mapas de bits. Android usará esta clase personalizada para guardar el estado.

  3. Eludir el ciclo de vida del cambio de configuración y asumir la responsabilidad completa de mantener el estado en la actividad.

En esta guía se tratan las dos primeras opciones.

Estado de agrupación

La opción principal para guardar el estado de la instancia es usar un objeto de diccionario de clave-valor conocido como bundle. Recuerde que, cuando se crea una actividad, el OnCreate método se pasa a un conjunto como parámetro, este lote se puede usar para restaurar el estado de la instancia. No se recomienda usar una agrupación para datos más complejos que no se serializarán de forma rápida o sencilla en pares clave-valor (como mapas de bits); en su lugar, se debe usar para valores simples como cadenas.

Una actividad proporciona métodos para ayudar a guardar y recuperar el estado de la instancia en el paquete:

  • OnSaveInstanceState : se invoca por Android cuando se destruye la actividad. Las actividades pueden implementar este método si necesitan conservar cualquier elemento de estado de clave-valor.

  • OnRestoreInstanceState : se llama una vez finalizado el método y proporciona otra oportunidad para que una actividad restaure su estado una vez completada la OnCreate inicialización.

En el diagrama siguiente se muestra cómo se usan estos métodos:

Diagrama de flujo de estados de agrupación

OnSaveInstanceState

Se llamará a OnSaveInstanceState cuando se detenga la actividad. Recibirá un parámetro de agrupación en el que la actividad puede almacenar su estado. Cuando un dispositivo experimenta un cambio de configuración, una actividad puede usar el Bundle objeto que se pasa para conservar el estado actividad invalidando OnSaveInstanceState. Por ejemplo, considere el siguiente código:

int c;

protected override void OnCreate (Bundle bundle)
{
  base.OnCreate (bundle);

  this.SetContentView (Resource.Layout.SimpleStateView);

  var output = this.FindViewById<TextView> (Resource.Id.outputText);

  if (bundle != null) {
    c = bundle.GetInt ("counter", -1);
  } else {
    c = -1;
  }

  output.Text = c.ToString ();

  var incrementCounter = this.FindViewById<Button> (Resource.Id.incrementCounter);

  incrementCounter.Click += (s,e) => {
    output.Text = (++c).ToString();
  };
}

El código anterior incrementa un entero denominado c cuando se hace clic en un botón denominado incrementCounter , que muestra el resultado en un TextView denominado output. Cuando se produce un cambio de configuración ( por ejemplo, cuando se gira el dispositivo), el código anterior perdería el valor de c porque bundle sería null, como se muestra en la ilustración siguiente:

La presentación no muestra el valor anterior

Para conservar el valor de c en este ejemplo, la actividad puede invalidar OnSaveInstanceState, guardando el valor en la agrupación, como se muestra a continuación:

protected override void OnSaveInstanceState (Bundle outState)
{
  outState.PutInt ("counter", c);
  base.OnSaveInstanceState (outState);
}

Ahora, cuando el dispositivo se gira a una nueva orientación, el entero se guarda en la agrupación y se recupera con la línea :

c = bundle.GetInt ("counter", -1);

Nota:

Es importante llamar siempre a la implementación base de OnSaveInstanceState para que también se pueda guardar el estado de la jerarquía de vistas.

Estado de vista

La invalidación OnSaveInstanceState es un mecanismo adecuado para guardar datos transitorios en una actividad en los cambios de orientación, como el contador del ejemplo anterior. Sin embargo, la implementación predeterminada de OnSaveInstanceState se encargará de guardar los datos transitorios en la interfaz de usuario para cada vista, siempre y cuando cada vista tenga asignado un identificador. Por ejemplo, supongamos que una aplicación tiene un EditText elemento definido en XML de la siguiente manera:

<EditText android:id="@+id/myText"
  android:layout_width="fill_parent"
  android:layout_height="wrap_content"/>

Dado que el EditText control tiene id asignado, cuando el usuario escribe algunos datos y gira el dispositivo, los datos se siguen mostrando, como se muestra a continuación:

Los datos se conservan en modo horizontal

OnRestoreInstanceState

Se llamará a OnRestoreInstanceState después OnStartde . Proporciona una actividad la oportunidad de restaurar cualquier estado que se guardó anteriormente en una agrupación durante el anterior OnSaveInstanceState. Esta es la misma agrupación que se proporciona a OnCreate, sin embargo.

En el código siguiente se muestra cómo se puede restaurar el estado en OnRestoreInstanceState:

protected override void OnRestoreInstanceState(Bundle savedState)
{
    base.OnRestoreInstanceState(savedState);
    var myString = savedState.GetString("myString");
    var myBool = savedState.GetBoolean("myBool");
}

Este método existe para proporcionar cierta flexibilidad en torno a cuándo se debe restaurar el estado. A veces es más adecuado esperar hasta que se realizan todas las inicializaciones antes de restaurar el estado de la instancia. Además, una subclase de una actividad existente solo puede querer restaurar determinados valores a partir del estado de la instancia. En muchos casos, no es necesario invalidar OnRestoreInstanceState, ya que la mayoría de las actividades pueden restaurar el estado mediante la agrupación proporcionada a OnCreate.

Para obtener un ejemplo de guardado de estado mediante , Bundleconsulte el Tutorial: Guardar el estado de la actividad.

Limitaciones de Bundle

Aunque OnSaveInstanceState facilita la guardado de datos transitorios, tiene algunas limitaciones:

  • No se llama en todos los casos. Por ejemplo, al presionar Inicio o Atrás para salir de una actividad, no OnSaveInstanceState se llamará a .

  • La agrupación que se pasa a OnSaveInstanceState no está diseñada para objetos grandes, como imágenes. En el caso de objetos grandes, es preferible guardar el objeto de OnRetainNonConfigurationInstance , como se describe a continuación.

  • Los datos guardados mediante el uso de la agrupación se serializan, lo que puede provocar retrasos.

El estado de agrupación es útil para datos simples que no usan mucha memoria, mientras que los datos de instancia que no son de configuración son útiles para datos más complejos o para los datos que son caros de recuperar, como desde una llamada de servicio web o una consulta de base de datos complicada. Los datos de instancia que no son de configuración se guardan en un objeto según sea necesario. En la sección siguiente se presenta OnRetainNonConfigurationInstance como una manera de conservar tipos de datos más complejos mediante cambios de configuración.

Conservación de datos complejos

Además de conservar los datos en la agrupación, Android también admite el almacenamiento de datos reemplazando OnRetainNonConfigurationInstance y devolviendo una instancia de que Java.Lang.Object contiene los datos que se van a conservar. Hay dos ventajas principales de usar OnRetainNonConfigurationInstance para guardar el estado:

  • El objeto devuelto de OnRetainNonConfigurationInstance funciona bien con tipos de datos más grandes y complejos porque la memoria conserva este objeto.

  • Se OnRetainNonConfigurationInstance llama al método a petición y solo cuando es necesario. Esto es más económico que usar una caché manual.

El uso OnRetainNonConfigurationInstance es adecuado para escenarios en los que resulta costoso recuperar los datos varias veces, como en las llamadas de servicio web. Por ejemplo, considere el código siguiente que busca en Twitter:

public class NonConfigInstanceActivity : ListActivity
{
  protected override void OnCreate (Bundle bundle)
  {
    base.OnCreate (bundle);
    SearchTwitter ("xamarin");
  }

  public void SearchTwitter (string text)
  {
    string searchUrl = String.Format("http://search.twitter.com/search.json?" + "q={0}&rpp=10&include_entities=false&" + "result_type=mixed", text);

    var httpReq = (HttpWebRequest)HttpWebRequest.Create (new Uri (searchUrl));
    httpReq.BeginGetResponse (new AsyncCallback (ResponseCallback), httpReq);
  }

  void ResponseCallback (IAsyncResult ar)
  {
    var httpReq = (HttpWebRequest)ar.AsyncState;

    using (var httpRes = (HttpWebResponse)httpReq.EndGetResponse (ar)) {
      ParseResults (httpRes);
    }
  }

  void ParseResults (HttpWebResponse httpRes)
  {
    var s = httpRes.GetResponseStream ();
    var j = (JsonObject)JsonObject.Load (s);

    var results = (from result in (JsonArray)j ["results"] let jResult = result as JsonObject select jResult ["text"].ToString ()).ToArray ();

    RunOnUiThread (() => {
      PopulateTweetList (results);
    });
  }

  void PopulateTweetList (string[] results)
  {
    ListAdapter = new ArrayAdapter<string> (this, Resource.Layout.ItemView, results);
  }
}

Este código recupera los resultados de la web con formato JSON, los analiza y, a continuación, presenta los resultados en una lista, como se muestra en la captura de pantalla siguiente:

Resultados mostrados en pantalla

Cuando se produce un cambio de configuración (por ejemplo, cuando se gira un dispositivo), el código repite el proceso. Para reutilizar los resultados recuperados originalmente y no provocar llamadas de red innecesarias y redundantes, podemos usar OnRetainNonconfigurationInstance para guardar los resultados, como se muestra a continuación:

public class NonConfigInstanceActivity : ListActivity
{
  TweetListWrapper _savedInstance;

  protected override void OnCreate (Bundle bundle)
  {
    base.OnCreate (bundle);

    var tweetsWrapper = LastNonConfigurationInstance as TweetListWrapper;

    if (tweetsWrapper != null) {
      PopulateTweetList (tweetsWrapper.Tweets);
    } else {
      SearchTwitter ("xamarin");
    }

    public override Java.Lang.Object OnRetainNonConfigurationInstance ()
    {
      base.OnRetainNonConfigurationInstance ();
      return _savedInstance;
    }

    ...

    void PopulateTweetList (string[] results)
    {
      ListAdapter = new ArrayAdapter<string> (this, Resource.Layout.ItemView, results);
      _savedInstance = new TweetListWrapper{Tweets=results};
    }
}

Ahora, cuando se gira el dispositivo, los resultados originales se recuperan de la LastNonConfiguartionInstance propiedad . En este ejemplo, los resultados constan de un string[] elemento que contiene tweets. Puesto OnRetainNonConfigurationInstance que requiere que se devuelva , Java.Lang.Object se string[] encapsula en una clase que subclase Java.Lang.Object, como se muestra a continuación:

class TweetListWrapper : Java.Lang.Object
{
  public string[] Tweets { get; set; }
}

Por ejemplo, al intentar usar como TextView objeto devuelto de OnRetainNonConfigurationInstance se filtrará la actividad, como se muestra en el código siguiente:

TextView _textView;

protected override void OnCreate (Bundle bundle)
{
  base.OnCreate (bundle);

  var tv = LastNonConfigurationInstance as TextViewWrapper;

  if(tv != null) {
    _textView = tv;
    var parent = _textView.Parent as FrameLayout;
    parent.RemoveView(_textView);
  } else {
    _textView = new TextView (this);
    _textView.Text = "This will leak.";
  }

  SetContentView (_textView);
}

public override Java.Lang.Object OnRetainNonConfigurationInstance ()
{
  base.OnRetainNonConfigurationInstance ();
  return _textView;
}

En esta sección, hemos aprendido a conservar datos de estado simples con Bundley a conservar tipos de datos más complejos con OnRetainNonConfigurationInstance.

Resumen

El ciclo de vida de la actividad de Android proporciona un marco eficaz para la administración del estado de las actividades dentro de una aplicación, pero puede resultar complicado comprender e implementar. En este capítulo se introdujeron los distintos estados en los que una actividad puede pasar durante su vigencia, así como los métodos de ciclo de vida asociados a esos estados. A continuación, se proporcionan instrucciones sobre qué tipo de lógica se debe realizar en cada uno de estos métodos.