Skip to content

Most visited

Recently visited

navigation

Actividades

Una Activity es un componente de la aplicación que contiene una pantalla con la que los usuarios pueden interactuar para realizar una acción, como marcar un número telefónico, tomar una foto, enviar un correo electrónico o ver un mapa. A cada actividad se le asigna una ventana en la que se puede dibujar su interfaz de usuario. La ventana generalmente abarca toda la pantalla, pero en ocasiones puede ser más pequeña que esta y quedar "flotando" encima de otras ventanas.

Una aplicación generalmente consiste en múltiples actividades vinculadas de forma flexible entre sí. Normalmente, una actividad en una aplicación se especifica como la actividad "principal" que se presenta al usuario cuando este inicia la aplicación por primera vez. Cada actividad puede a su vez iniciar otra actividad para poder realizar diferentes acciones. Cada vez que se inicia una actividad nueva, se detiene la actividad anterior, pero el sistema conserva la actividad en una pila (la "pila de actividades"). Cuando se inicia una actividad nueva, se la incluye en la pila de actividades y capta el foco del usuario. La pila de actividades cumple con el mecanismo de pila "el último en entrar es el primero en salir", por lo que, cuando el usuario termina de interactuar con la actividad actual y presiona el botón Atrás, se quita de la pila (y se destruye) y se reanuda la actividad anterior. (La pila de actividades se explica más detalladamente en el documento Tareas y pila de actividades).

Cuando se detiene una actividad porque se inicia otra, se notifica el cambio de estado a través de los métodos callback del ciclo de vida de la actividad. Existen diferentes métodos callback que podría recibir una actividad como consecuencia de un cambio de estado (ya sea que el sistema la esté creando, deteniendo, reanudando o destruyendo) y cada callback te da la oportunidad de realizar una tarea específica que resulta adecuada para ese cambio de estado. Por ejemplo, cuando se detiene una actividad, esta debería liberar los objetos grandes, como una conexión de red o a la base de datos. Cuando se reanuda la actividad, puedes volver a adquirir los recursos necesarios y reanudar las acciones que se interrumpieron. Todas estas transiciones de estado forman parte del ciclo de vida de la actividad.

El resto de este documento aborda los conceptos básicos con respecto a cómo crear y utilizar una actividad, incluido un artículo completo sobre cómo funciona el ciclo de vida de la actividad, de modo que puedas administrar correctamente la transición entre diferentes estados de la misma.

Crear una actividad

Para crear una actividad, debes crear una subclase de Activity (o una subclase existente de ella). En tu subclase debes implementar métodos callback a los que el sistema invoca cuando la actividad alterna entre diferentes estados de su ciclo de vida, como cuando se crea, se detiene, se reanuda o se destruye. Los dos métodos callback más importantes son los siguientes:

onCreate()
Debes implementar este método. El sistema realiza esta llamada cuando crea tu actividad. En tu implementación, debes inicializar los componentes fundamentales de tu actividad. No te olvides de que este es el momento en el que debes llamar a setContentView() para definir el diseño de la interfaz de usuario de la actividad.
onPause()
El sistema llama a este método como el primer indicador de que el usuario está abandonando tu actividad (aunque no siempre significa que la actividad se esté destruyendo). Generalmente este es el momento en el que debes confirmar los cambios que deban conservarse más allá de la sesión de usuario actual (porque es posible que el usuario no vuelva).

Existen muchos otros métodos callback del ciclo de vida que deberías usar para proporcionar una experiencia de usuario fluida entre actividades y abordar interrupciones inesperadas que provocan la detención e incluso la destrucción de tu actividad. Todos los métodos callback del ciclo de vida se discuten más adelante, en la sección acerca de Cómo administrar el ciclo de vida de la actividad.

Implementar una interfaz de usuario

La interfaz de usuario para una actividad se proporciona mediante una jerarquía de vistas; objetos derivados de la clase View. Cada vista controla un espacio rectangular específico dentro de la ventana de la actividad y pueden responder a la interacción del usuario. Por ejemplo, una vista podría ser un botón que inicie una acción cuando el usuario lo toca.

Android ofrece varias vistas listas que puedes usar para diseñar y organizar tu presentación. Los “widgets” son vistas que proporcionan elementos visuales (e interactivos) para la pantalla, como un botón, un campo de texto, una casilla de verificación o una imagen. Los “diseños” son vistas derivadas de ViewGroup que proporcionan un modelo de diseño único para sus vistas secundarias, como un diseño lineal, un diseño de cuadrículas o un diseño relativo. También puedes convertir en subclases las clases View y ViewGroup (o subclases ya existentes) para crear tus propios widgets y diseños y aplicarlos en el diseño de tu actividad.

La forma más común de definir un diseño mediante el uso de vistas es con un archivo de diseño XML guardado en los recursos de tu aplicación. De esta manera, puedes mantener el diseño de tu interfaz de usuario separado del código fuente que define el comportamiento de la actividad. Puedes configurar el diseño como la IU para tu actividad con setContentView(), pasando la ID de recurso para el diseño. También puedes crear nuevas View en el código de tu actividad y una jerarquía de vistas insertando nuevas View en un ViewGroup, y luego usar ese diseño pasando la raíz ViewGroup a setContentView().

Para obtener información acerca de cómo crear una interfaz de usuario, consulta la documentación Interfaz de usuario.

Declarar la actividad en el manifiesto

Debes declarar tu actividad en el archivo de manifiesto para que pueda estar accesible para el sistema. Para declarar tu actividad, abre el archivo de manifiesto y agrega un elemento <activity> como campo secundario del elemento <application>. Por ejemplo:

<manifest ... >
  <application ... >
      <activity android:name=".ExampleActivity" />
      ...
  </application ... >
  ...
</manifest >

Existen muchos otros atributos que puedes incluir en este elemento para definir propiedades, como la etiqueta para la actividad, un ícono para la actividad o un tema para diseñar la IU de la actividad. El atributo android:name es el único obligatorio; especifica el nombre de clase de actividad. Una vez que publicas tu aplicación, no debes cambiar este nombre porque si lo haces podrías anular funcionalidades, como accesos directos de la aplicación (lee la publicación del blog, Cosas que no pueden cambiar).

Consulta la referencia del elemento <activity> para obtener más información acerca de cómo declarar tu actividad en el manifiesto.

Usar filtros de intents

Un elemento <activity> también puede especificar varios filtros de intents a través del elemento <intent-filter> para declarar la forma en que otros componentes de la aplicación pueden activarlo.

Cuando creas una aplicación nueva con las herramientas del Android SDK, la actividad auxiliar que se crea automáticamente incluye un filtro de intents que declara que la actividad responde a la acción “principal” y se debe colocar en la categoría “lanzador”. El filtro de intents se ve de esta manera:

<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

El elemento <action> especifica que este es el punto de entrada “principal” a la aplicación. El elemento <category> especifica que esta actividad debe aparecer en el lanzador de aplicaciones del sistema (para que los usuarios puedan iniciar esta actividad).

Si quieres que tu aplicación sea independiente y no permitir que otras aplicaciones activen sus actividades, entonces no necesitas ningún otro filtro de intents. Una sola actividad debe tener la acción "principal" y la categoría "lanzador", como en el ejemplo anterior. Las actividades que no quieres que estén disponibles para otras aplicaciones no deben tener filtros de intents, y puedes iniciarlas tú mismo usando intents explícitas (como las que se discuten en la siguiente sección).

Pero si quieres que tu actividad responda a intents implícitas que provienen de otras aplicaciones (y de la tuya), debes definir filtros de intents adicionales para tu actividad. Para cada tipo de intent a la que desees responder debes agregar un <intent-filter> que incluya un elemento <action> y, opcionalmente, un elemento <category> o <data>. Estos elementos especifican el tipo de intent a la que tu actividad puede responder.

Para obtener más información acerca de cómo tus actividades pueden responder a intents, lee el documento Intents y filtros de intents .

Cómo iniciar una actividad

Puedes iniciar otra actividad al llamar a startActivity(), y pasarle una Intent que describa la actividad que quieres iniciar. La intent especifica la actividad exacta que quieres iniciar o describe el tipo de acción que quieres realizar (y el sistema selecciona la actividad adecuada para ti, que incluso puede ser de otra aplicación). Una intent también puede contener pequeñas cantidades de datos que utilizará la actividad que se inicie.

Cuando trabajes en tu propia aplicación, con frecuencia necesitarás iniciar una actividad conocida. Puedes hacerlo al crear una intent que defina de forma explícita la actividad que quieres iniciar, y para eso deberás usar el nombre de clase. Por ejemplo, aquí se muestra la forma en que una actividad inicia otra llamada SignInActivity:

Intent intent = new Intent(this, SignInActivity.class);
startActivity(intent);

Sin embargo, tu aplicación también podría querer realizar alguna acción, como enviar un correo electrónico, un mensaje de texto o actualizar el estado con datos de tu actividad. En este caso, tu aplicación podría no tener sus propias actividades para realizar esas acciones, por lo que, en su lugar, puedes aprovechar las actividades que proporcionan otras aplicaciones en el dispositivo y que pueden realizar las acciones por ti. Aquí es cuando las intents pasan a ser muy valiosas, ya que puedes crear una intent que describa una acción que quieres realizar y el sistema iniciará la actividad adecuada desde otra aplicación. Si hubieran varias actividades que pudiesen ejecutar la intent, el usuario podrá seleccionar la que quiera usar. Por ejemplo, si quieres permitirle al usuario enviar un mensaje de correo electrónico, puedes crear la siguiente intent:

Intent intent = new Intent(Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_EMAIL, recipientArray);
startActivity(intent);

El EXTRA_EMAIL extra agregado a la intent es un conjunto de strings de direcciones de correo electrónico a las que se debe enviar el correo electrónico. Cuando una aplicación de correo electrónico responde a esta intent, lee el conjunto de strings proporcionado en el extra y las coloca en el campo “Para” del formulario de composición de correo electrónico. En esta situación, se inicia la actividad de la aplicación de correo electrónico y cuando el usuario termina, se reanuda tu actividad.

Iniciar una actividad para obtener un resultado

Algunas veces, querrás recibir un resultado a partir de la actividad que inicias. En ese caso, inicia la actividad llamando a startActivityForResult() (en lugar de startActivity()). Para luego recibir el resultado de la siguiente actividad, implementa el método callback onActivityResult(). Cuando finaliza la siguiente actividad, muestra un resultado en una Intent a tu método onActivityResult().

Por ejemplo, quizá quieras que el usuario seleccione uno de sus contactos para que tu actividad pueda hacer algo con la información de ese contacto. Aquí te mostramos cómo puedes crear esa intent y manipular el resultado:

private void pickContact() {
    // Create an intent to "pick" a contact, as defined by the content provider URI
    Intent intent = new Intent(Intent.ACTION_PICK, Contacts.CONTENT_URI);
    startActivityForResult(intent, PICK_CONTACT_REQUEST);
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    // If the request went well (OK) and the request was PICK_CONTACT_REQUEST
    if (resultCode == Activity.RESULT_OK && requestCode == PICK_CONTACT_REQUEST) {
        // Perform a query to the contact's content provider for the contact's name
        Cursor cursor = getContentResolver().query(data.getData(),
        new String[] {Contacts.DISPLAY_NAME}, null, null, null);
        if (cursor.moveToFirst()) { // True if the cursor is not empty
            int columnIndex = cursor.getColumnIndex(Contacts.DISPLAY_NAME);
            String name = cursor.getString(columnIndex);
            // Do something with the selected contact's name...
        }
    }
}

En este ejemplo se muestra la lógica básica que debes usar en tu método onActivityResult() para manipular el resultado de una actividad. La primera condición verifica si la solicitud tuvo éxito (si lo tuvo, el resultCode será RESULT_OK) y si se conoce la solicitud a la cual responde ese resultado (en este caso, el requestCode coincide con el segundo parámetro enviado con startActivityForResult(). A partir de este punto, el código manipula el resultado de la actividad consultando los datos mostrados en una Intent (el parámetro data).

Lo que sucede es que un ContentResolver realiza una consulta a un proveedor de contenido, el que devuelve un Cursor que permite leer los datos consultados. Para obtener más información, lee el documento Proveedores de contenido.

Para obtener más información acerca de cómo usar intents, lee el documento Intents y filtros de intents.

Cerrar una actividad

Puedes cerrar una actividad llamando a su método finish(). También puedes cerrar una actividad que hayas iniciado anteriormente llamando a finishActivity().

Nota: En la mayoría de los casos, no debes finalizar explícitamente una actividad con estos métodos. Tal como se discute en la siguiente sección acerca del ciclo de vida de la actividad, el sistema Android se encarga de administrar el ciclo de vida de una actividad por ti, por lo que no necesitas finalizar tus propias actividades. Llamar a estos métodos podría afectar de forma negativa la experiencia de usuario esperada y solo deben usarse cuando no quieres que el usuario vuelva a esta instancia de la actividad de forma terminante.

Administración del ciclo de vida de la actividad

Administrar el ciclo de vida de tus actividades mediante la implementación de métodos callbacks es fundamental para desarrollar una aplicación potente y flexible. El ciclo de vida de una actividad se ve directamente afectado por su asociación con otras actividades, con sus tareas y con la pila de actividades.

Una actividad puede existir básicamente en tres estados:

Reanudada
La actividad se encuentra en el primer plano de la pantalla y tiene la atención del usuario. (A veces, este estado también se denomina "en ejecución").
Pausada
Otra actividad se encuentra en el primer plano y tiene la atención del usuario, pero esta todavía está visible. Es decir, otra actividad está visible por encima de esta y esa actividad es parcialmente transparente o no cubre toda la pantalla. Una actividad pausada está completamente "viva" (el objeto Activity se conserva en la memoria, mantiene toda la información de estado y miembro y continúa anexado al administrador de ventanas), pero el sistema puede eliminarla en situaciones en que la memoria sea extremadamente baja.
Detenida
La actividad está completamente opacada por otra actividad (ahora la actividad se encuentra en "segundo plano"). Una actividad detenida también permanece "viva" (el objeto Activity se conserva en memoria, mantiene toda la información de estado y miembro, pero no está anexado al administrador de ventanas). Sin embargo, ya no está visible para el usuario y el sistema puede eliminarla cuando necesite memoria en alguna otra parte.

Si se pausa o se detiene una actividad, el sistema puede excluirla de la memoria al solicitarle que se cierre (llamando a su método finish()), o simplemente eliminando su proceso. Cuando se vuelve a abrir la actividad (después de haber sido eliminada o destruida), es necesario crearla nuevamente.

Implementación de callbacks del ciclo de vida

Cuando una actividad entra y sale de los diferentes estados que se describieron más arriba, esto se notifica a través de diferentes métodos callback. Todos los métodos callback son enlaces que puedes invalidar para realizar las tareas correspondientes cuando cambia el estado de la actividad. La siguiente actividad estructural incluye todos los métodos fundamentales del ciclo de vida:

public class ExampleActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // The activity is being created.
    }
    @Override
    protected void onStart() {
        super.onStart();
        // The activity is about to become visible.
    }
    @Override
    protected void onResume() {
        super.onResume();
        // The activity has become visible (it is now "resumed").
    }
    @Override
    protected void onPause() {
        super.onPause();
        // Another activity is taking focus (this activity is about to be "paused").
    }
    @Override
    protected void onStop() {
        super.onStop();
        // The activity is no longer visible (it is now "stopped")
    }
    @Override
    protected void onDestroy() {
        super.onDestroy();
        // The activity is about to be destroyed.
    }
}

Nota: La implementación que realices de estos métodos del ciclo de vida siempre deben llamar la implementación de la superclase antes de realizar cualquier otra tarea, como se muestra en los ejemplos anteriores.

En conjunto, estos métodos definen el ciclo de vida completo de una actividad. Al implementar estos métodos, puedes monitorear tres bucles anidados en el ciclo de vida de la actividad:

La figura 1 ilustra esos bucles y el camino que debe tomar una actividad entre estados. Los rectángulos representan los métodos callback que puedes implementar para realizar operaciones cuando la actividad cambie de estado.

Figura 1: Ciclo de vida de la actividad.

Los mismos métodos callback del ciclo de vida se indican en la tabla 1, que describe cada uno de los métodos callback en más detalle y ubica a cada uno dentro del ciclo de vida total de la actividad, incluido si el sistema puede eliminar la actividad después de que se completa el método callback.

Tabla 1: Resumen de los métodos de callback del ciclo de vida de una actividad.

Método Descripción ¿Se puede eliminar después? A continuación
onCreate() Recibe una llamada cuando se crea la actividad por primera vez. Aquí es donde debes realizar todas las configuraciones estáticas normales: crear vistas, enlazar datos con listas, etc. A este método se le pasa un objeto agrupado que contiene el estado anterior de la actividad, si se hubiera capturado ese estado (lee Guardar el estado de una actividad más adelante).

Siempre seguido por onStart().

No onStart()
     onRestart() Recibe una llamada después de que se detiene la actividad, junto antes de que vuelva a iniciarse.

Siempre seguido por onStart().

No onStart()
onStart() Recibe una llamada justo antes de que la actividad se vuelva visible para el usuario.

Seguido por onResume() si la actividad pasa a primer plano, o por onStop() si se oculta.

No onResume()
o
onStop()
     onResume() Recibe una llamada justo antes de que la actividad comience a interactuar con el usuario. En este momento la actividad se encuentra en la parte superior de la pila de actividades, y recibe las entradas del usuario.

Siempre seguido por onPause().

No onPause()
onPause() Recibe una llamada cuando el sistema está a punto de reanudar otra actividad. Este método generalmente se usa para confirmar los cambios sin guardar como datos persistentes, para detener animaciones y otras tareas que podrían estar consumiendo CPU, etc. Lo que sea que haga, debe hacerlo muy rápido porque la siguiente actividad no se reanudará hasta que el método regrese.

Seguido por onResume() si la actividad vuelve al primer plano, o por onStop() si se vuelve invisible para el usuario.

onResume()
o
onStop()
onStop() Recibe una llamada cuando la actividad ya no es visible para el usuario. Esto puede ocurrir porque se la destruyó o porque se reanudó otra actividad (ya sea una actividad existente o una nueva) y la está cubriendo.

Seguido por onRestart() si la actividad vuelve a interactuar con el usuario, o por onDestroy() si la actividad desaparece.

onRestart()
o
onDestroy()
onDestroy() Recibe una llamada antes de que se destruya la actividad. Esta es la última llamada que recibirá la actividad. Se lo puede llamar porque la actividad está finalizando (alguien llamó a finish() para esa actividad), o porque el sistema destruye temporalmente esa instancia de la actividad para ahorrar espacio. Puedes diferenciar estos dos escenarios con el método isFinishing(). nada

La columna llamada "¿Se puede eliminar después?" indica si el sistema puede eliminar el proceso que aloja a la actividad en cualquier momento después de que el método regresa, sin ejecutar otra línea del código de la actividad. En tres métodos se indica “sí”: (onPause(), onStop() y onDestroy()). Debido a que onPause() es el primero de los tres, una vez que se crea la actividad, onPause() es el último método al que se llamará para que se pueda finalizar el proceso; si el sistema debe recuperar memoria en una emergencia, es posible que no se llame a onStop() ni a onDestroy(). Por lo tanto, debes usar onPause() para escribir datos persistentes fundamentales (como ediciones realizadas por el usuario) para almacenar. Sin embargo, debes seleccionar bien la información que quieres conservar durante onPause(), ya que cualquier procedimiento de bloqueo en este método bloqueará la transición a la siguiente actividad y hará que la experiencia del usuario sea más lenta.

Los métodos en los que se indica "No" en la columna ¿Se puede eliminar después? protegen el proceso que aloja la actividad para que no pueda ser eliminada desde el momento en que se los llama. De esta manera, la actividad es "eliminable" desde el momento en que onPause() regresa hasta el momento en que se llama a onResume(). No volverá a ser "eliminable" hasta que se llame nuevamente a onPause() y regrese.

Nota: Una actividad que técnicamente no sea "eliminable" de acuerdo con su definición en la tabla 1, aún podrá ser eliminada por el sistema, pero esto solo ocurriría en situaciones extremas en las que no haya otros recursos. Cuándo se podría eliminar una actividad se discute en más detalle en el documento Procesos y subprocesos.

Cómo guardar el estado de una actividad

La introducción a Administrar el ciclo de vida de una actividad menciona brevemente que cuando se pausa o se detiene una actividad, se conserva el estado de la actividad. Esto ocurre porque el objeto Activity aún se encuentra en la memoria cuando la actividad se pausa o se detiene; toda la información de sus miembros y el estado actual aún está con vida. Por lo tanto, los cambios que realice el usuario en la actividad se conservan de modo que cuando la actividad regrese a primer plano (cuando se "reanude"), esos cambios todavía estén ahí.

Sin embargo, cuando el sistema destruye una actividad para recuperar memoria, el objeto Activity también se destruye, por lo cual el sistema no puede simplemente reanudarla con su estado intacto. En su lugar, si el usuario retrocede en su navegación hasta esa actividad, el sistema debe volver a crear el objeto Activity. Aún así, el usuario no sabe que el sistema destruyó la actividad y la volvió a crear y, por lo tanto, probablemente espere que la actividad se encuentre tal como estaba. En esa situación, puedes garantizar que se conserve la información importante acerca del estado de la actividad mediante la implementación de un método de callback adicional que te permita guardar información acerca del estado de tu actividad: onSaveInstanceState().

Antes de que la actividad sea vulnerable a la destrucción, el sistema llama a onSaveInstanceState(). El sistema pasa a este método un Bundle en el que puedes guardar información del estado de la actividad como pares nombre-valor mediante métodos como putString() y putInt(). Luego, si el sistema finaliza el proceso de tu aplicación y el usuario regresa a la actividad, el sistema vuelve a crear la actividad y pasa el Bundle a onCreate() y a onRestoreInstanceState(). Al usar cualquiera de estos métodos, puedes extraer el estado guardado de Bundle y restaurar el estado de la actividad. Si no hay información de estado para restaurar, el Bundle que recibes es null (como sucede cuando se crea la actividad por primera vez).

Figura 2: Dos maneras en las cuales una actividad recupera el foco para el usuario con su estado intacto: la actividad se destruye, luego vuelve a crearse y debe restaurar el estado guardado anteriormente, o se detiene y luego se reanuda, y su estado permanece intacto.

Nota: No se garantizan llamadas a onSaveInstanceState() antes de destruir tu actividad, ya que hay casos en los cuales no será necesario guardar el estado (como cuando el usuario sale de tu actividad con el botón Atrás, porque cierra la actividad explícitamente). Si el sistema llama a onSaveInstanceState(), lo hace antes de llamar a onStop() y posiblemente antes de llamar a onPause().

No obstante, incluso si no haces nada y no implementas onSaveInstanceState(), parte del estado de la actividad se restaura mediante la implementación predeterminada de onSaveInstanceState() por parte de la clase Activity. Específicamente, la implementación predeterminada llama al método onSaveInstanceState() correspondiente para cada View del diseño, el cual permite que cada vista proporcione información acerca de sí misma que debe guardarse. Prácticamente todos los widgets del framework de Android implementan este método según les convenga, de modo que los cambios visibles en la IU se guardan automáticamente y se restauran cuando se vuelve a crear la actividad. Por ejemplo, el widget EditText guarda el texto ingresado por el usuario y el widget CheckBox guarda si se comprobó o no. Lo único que debes hacer es proporcionar un ID único (con el atributo android:id ) para cada widget cuyo estado desees guardar. Si un widget no tiene una ID, el sistema no puede guardar su estado.

Si bien la implementación predeterminada de onSaveInstanceState() guarda información útil acerca de la IU de tu actividad, probablemente necesites sobrescribirla para guardar información adicional. Por ejemplo, podría ser necesario que guardes valores de miembro que cambiaron durante la vida útil de la actividad (que podrían correlacionarse con valores restaurados en la IU, pero los miembros que poseen esos valores de la IU no se restauran, de forma predeterminada).

Debido a que la implementación predeterminada de onSaveInstanceState() ayuda a guardar el estado de la IU, si sobrescribes el método para guardar información de estado adicional siempre debes llamar la implementación de onSaveInstanceState() por parte de la superclase antes de realizar cualquier tarea. De la misma manera, también debes llamar a la implementación de onRestoreInstanceState() por parte de la superclase si la sobrescribes, de modo que la implementación predeterminada pueda restaurar estados de las vistas.

Nota: Dado que no se garantiza la llamada a onSaveInstanceState(), debes usarlo solo para registrar el estado transitorio de la actividad (el estado de la IU); nunca debes usarlo para almacenar datos persistentes. En su lugar, debes usar onPause() para guardar datos persistentes (como datos que deben guardarse en una base de datos) cuando el usuario abandona la actividad.

Una buena manera de probar la capacidad de tu aplicación de restaurar su estado es simplemente girar el dispositivo para que cambie la orientación de la pantalla. Cuando cambia la orientación de la pantalla, el sistema destruye y vuelve a crear la actividad para poder aplicar recursos alternativos que podrían estar disponibles para la nueva configuración de pantalla. Solo por este motivo, es muy importante que tu actividad restaure por completo su estado cuando se vuelva a crear, ya que los usuarios generalmente giran la pantalla cuando usan aplicaciones.

Manejar cambios de configuración

Algunas configuraciones de dispositivos pueden cambiar durante el tiempo de ejecución (como la orientación de la pantalla, la disponibilidad del teclado y el idioma). Cuando se produce un cambio como este, Android vuelve a crear la actividad en ejecución (el sistema llama a onDestroy() y, de inmediato, llama a onCreate()). Este comportamiento fue diseñado para ayudar a tu aplicación a adaptarse a las nuevas configuraciones al recargar automáticamente la aplicación con recursos alternativos que tú proporcionaste (como diferentes diseños para las diferentes orientaciones y tamaños de pantalla).

Si diseñas tu actividad correctamente para que sea capaz de afrontar un reinicio como consecuencia de un cambio en la orientación de la pantalla y restaure el estado de la actividad como se describió antes, tu aplicación será más resistente a otros eventos inesperados en el ciclo de vida de la actividad.

La mejor manera de manejar un reinicio como ese es guardar y restaurar el estado de tu actividad usando onSaveInstanceState() y onRestoreInstanceState() (o onCreate()), como en la sección anterior.

Para obtener más información acerca de los cambios de configuración que ocurren durante el tiempo de ejecución y cómo puedes manejarlos, lee la guía Manejo de cambios en tiempo de ejecución.

Coordinar actividades

Cuando una actividad inicia otra, ambas experimentan transiciones en el ciclo de vida. La primera actividad se pausa y se detiene (aunque no se detendrá si aún está visible en segundo plano) mientras se crea la otra actividad. Si esas actividades comparten datos guardados en el disco o en alguna otra parte, es importante que entiendas que la primera actividad no se detiene completamente antes de que se cree la segunda, sino que el proceso de inicio de una segunda actividad se superpone con el proceso de detención de la primera.

El orden de los callbacks del ciclo de vida está bien definido, especialmente cuando las dos actividades están en el mismo proceso y una inicia la otra. Aquí te mostramos el orden de las operaciones que ocurren cuando la actividad A inicia la actividad B:

  1. Se ejecuta el método onPause() de la actividad A.
  2. Los métodos onCreate(), onStart() y onResume() de la actividad B se ejecutan en secuencia. (Ahora la actividad B tiene la atención del usuario).
  3. Por lo tanto, si la actividad A deja de verse en pantalla, se ejecuta su método onStop().

Esta secuencia predecible de callbacks del ciclo de vida te permite administrar la transición de información de una actividad a otra. Por ejemplo, si debes realizar operaciones de escritura en una base de datos cuando la primera actividad se detiene para que la siguiente pueda leerla, debes realizar operaciones de escribir en la base de datos durante onPause() en lugar de hacerlo durante onStop().

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.