Manos a la obra - Anatomía de una aplicación Android

Documento original: Anatomy of an Android Application

Anatomía de una aplicación Android

[Título original: Anatomy of an Android Application]

Las aplicaciones Android están constituidas a partir de la combinación de los siguientes bloques:

Activity

IntentReceiver

Service

ContentProvider

NOTA: Una aplicación no requiere utilizar todos estos componentes.

Una vez que has seleccionado los componentes que utilizarás en tu aplicación, es necesario que los listes en un archivo llamado: "AndroidManifest.xml". Este es un archivo XML en el que declaras los componentes de tu aplicación, sus capacidades y sus requerimientos.

Actividad

[Título original: Activity]

Una "actividad" es el bloque más usado en las aplicaciones "Android". Generalmente, una "actividad" es una pantalla individual en tu aplicación. Cada "actividad" se implementa como una clase que hereda de "Activity", lo que hará que tu clase despliegue una UI compuesta de "View"s y resonda a eventos. Lo común es que una aplicación consista de múltiples pantallas. Por ejemplo, una aplicación de mensajería podría usar una pantalla para mostrar el listado de contactos y en una segunda pantalla para escribir el mensaje al contacto seleccionado; y otras pantallas para ver cambiar la configuración. Cada una de estas pantallas debe ser implementada como una "Activity". La navegación entre las pantallas se hace iniciando una nueva "Activity". En algunos casos, una "Activity" podría devolver un valor a la "Activity" anterior, por ejemplo la "Actividad#1" podría permitir seleccionar una foto y esta foto sería devuelta a la "Activity" que hizo el llamado a "Actividad#1".

Cuando una pantalla es abierta, la previa es puesta en pausa y agregada al "History Stack". Posteriormente, el usuario puede navegar hacia previas pantallas invocando las pantallas almacenadas en el "History Stack". Las pantallas también pueden ser removidas del "History Stack" cuando resulta inapropiado su almacenamiento. Android mantiene un "History Stack" por cada una de las aplicaciones que son activadas desde la "Home Screen".

Intentos y filtros de intentos

[Título original: Intent and Intent Filters]

Android usa una clase especial llamada "Intent" para moverse de una pantalla a otra. Un "Intent" describe lo que una aplicación desea hacer. Las dos partes más importantes de la estructura de datos de un "Intent" son la acción y los datos sobre los cuales se actuará. Los valores típicos para la acción son "MAIN", "VIEW", "PICK", "EDIT", etc. Los datos son expresados como una URI. Por ejemplo, para ver la información de contacto de una persona podría ser necesario crear un "Intent" con la acción "VIEW" y los datos definidos como una URI que representa a esa persona.

Una clase relacionada con "Intent" es "IntentFilter". Si bien un "Intent" es una solicitud para realizar algo, un "IntentFilter" es una descripción de lo que intenta hacer una "Activity" (o de lo que intenta recibir). Una "Activity" que es capaz de desplegar la información de contacto de una persona podría declarar que sabe cómo tratar la acción "VIEW" cuando es aplicada a los datos que representan a la persona. Una "Activity" declara sus "IntentFilter"s en el archivo "AndroidManifest.xml".

La navegación de pantalla a pantalla es ejecutada a través de la resolución de intentos. Para navegar hacia adelante, una "Activity" llama "startActivity(myIntent)". Entonces, el sistema examina todos los "IntentFilter"s que existen para las aplicaciones instaladas y toma aquellas "Activity" cuyos "IntentFilter" mejor se acercan a "myIntent". La nueva "Activity" es informada del "Intent", lo que causa que sea activada. El proceso de resolución de "Intent" ocurre en tiempo de ejecución cuando "startActivity" es llamado, lo cual tiene dos beneficios claves:

Una "Activity" puede reutilizar funcionalidades de otras componentes con sólo hacer un una solicitud en la forma de "Intent".

Una "Activity" puede ser reemplazada en cualquier momento por una nueva "Activity" que tenga un "IntentFilter" equivalente.

Recibidor de intento

[Título original: Intent Receiver]

Tú puedes utilizar un "IntentReceiver" cuando quieras programar tu aplicación para que se ejecute como respuesta a un evento. Por ejemplo, cuando recibes una llamada, cuando la red de datos esta disponible o cuando es media noche. Los "IntentReceiver"s no despliegan UI, sin embargo ellos podrían utilizar el "NotificationManager" para avisar al usuario que algo interesante está pasando. Los "IntentReceiver"s son registrados en el archivo "AndroidManifest.xml", pero también pueden ser registrados programáticamente con el uso de "Context.registerReceiver()". Tu aplicación no requiere estar corriendo para que sus "IntentReceiver"s puedan ser llamados. Si tu aplicación no estuviera corriendo, el sistema la puede activar cuando uno de sus "IntentReceiver"s sea gatillado. Las aplicaciones también pueden transmitir sus propios "Intent"s a otras aplicaciones a través de "Context.broadcastIntent()".

Servicios

[Título original: Service]

Un "Service" es una aplicación que se mantiene activada por un largo tiempo y no despliega una UI. Un ejemplo es un programa que reproduce archivos mp3 desde una lista de música, mientras el usuario realiza otras actividades. En este caso, el programa podría iniciar un servicio con "Context.startService()" y de esa forma reproducir la música sin necesidad de usar la pantalla. El sistema mantendrá el servicio de reproducción de música corriendo hasta que finalice. Si quieres aprender más sobre la prioridad que es dada a los servicios por el sistema, lee "Ciclo de vida de una aplicación Android". Es posible conectarse a un "Service" (y activarlo si no estuviera corriendo) haciendo uso del método "Context.bindService()". Una vez que la aplicación está conectada al servicio, la comunicación entre tu aplicación y el servicio se realiza a través de la interfaz que el "servicio" expone. Para nuestro ejemplo del reproductor mp3, está interfaz podría permitir hacer pausa o saltar a una nueva canción.

Proveedor de contenidos

[Título original: Content Provider]

Las aplicaciones puedes almacenar sus datos en archivos, una base de datos "SQLite" o cualquier otro mecanismo. Sin embargo, un "Content Provider" es de utilidad cuando los datos de tu aplicación deben ser compartidos con otras aplicaciones. Un "Content Provider" es una clase que implementa un conjunto estándar de métodos para que otras aplicaciones almacenen o recuperen el tipo de datos que el "Content Provider" manipula.