Anatomía de una Aplicación Android.

Toda aplicación Android esta constituida por 4 bloques, no necesariamente deben estar todos en la misma. Estos bloques son:

• -       Actividad (Activity).
• -       Receptor de Intenciones (IntentReceiver).
• -       Servicios (Services).
• -       Proveedores de contenido (ContentProvider).

Como no son obligatorios, los que usemos deben estar definidos 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 (Activity).

Una actividad es el bloque más usado en las aplicaciones Android. Generalmente, una actividad es una pantalla individual en la aplicación. Cada actividad se implementa como una clase que hereda de Activity, lo que hará que tu clase despliegue una UI compuesta de Views y responda 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.

Receptor de Intenciones (IntentReceiver).

Antes de poder explicar que es el receptor de intenciones o IntentReceiver debemos conocer que son intenciones.

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.

Por lo tanto, 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 está 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 disparado. Las aplicaciones también pueden transmitir sus propios Intents a otras aplicaciones a través de Context.broadcastIntent().

Servicios (Services).

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.

Proveedores de contenido (ContentProvider).

Las aplicaciones puedes almacenar sus datos en archivos, una base de datos SQLite o cualquier otro mecanismo. Sin embargo, un ContentProvider es de utilidad cuando los datos de tu aplicación deben ser compartidos con otras aplicaciones. Un ContentProvider 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 ContentProvider manipula.