Componentes de una aplicación Android

Las aplicaciones Android se construyen mediante bloques esenciales de componentes, cada uno de los cuales existe como una entidad propia y desempeña un papel específico; cada elemento es una pieza única que ayuda a definir el comportamiento general de la aplicación. Es importante mencionar que algunos de estos elementos son el punto de entrada para que los usuarios interactúen con la aplicación y en muchos casos veremos que unos elementos dependen de otros.

Hay cuatro tipos de componentes en una aplicación Android. Cada uno de ellos tiene un propósito y un ciclo de vida distinto que define cómo se crea y se destruye el componente.

Activities (actividades). Es el bloque encargado de construir la interfaz de usuario. Puedes pensar en una actividad como el análogo de una ventana en una aplicación de escritorio. En las actividades recae la responsabilidad de presentar los elementos visuales y reaccionar a las acciones del usuario.

Si bien podemos pensar en actividades que no posean una interfaz de usuario, regularmente el código en estos casos se empaqueta en forma de content providers (proveedores de contenido) y services (servicios) que detallaremos en un momento.

Toda actividad se inicia como respuesta a un Intent.

Intents (intenciones). Son los mensajes del sistema que se encuentran corriendo en el interior del dispositivo. Se encargan de notificar a las aplicaciones de varios eventos: cambios de estado en el hardware (ej. cuando se inserta unaSD al teléfono), notificaciones de datos entrantes (ej. cuando llega un SMS) y eventos en las aplicaciones (ej. cuando una actividad es lanzada desde el menú principal).

Así como podemos crear actividades que respondan a las intenciones, podemos crear también intenciones que lancen actividades o usarlas para detonar eventos ante algunas situaciones específicas (ej. que el teléfono nos notifique por medio de un mensaje cuando nuestra localización esté a 10 mts del punto de destino). Es importante mencionar que el sistema es el que elige entre las actividades disponibles en el teléfono y dará respuesta a la intención con la actividad más adecuada.

Content providers (proveedores de contenido). Este elemento ofrece un conjunto de datos almacenados en el dispositivo para que se puedan accesar y compartir por varias aplicaciones. Nosotros podemos guardar datos en archivos del sistema, en una base de datos en SQLite, en la web o en cualquier otro lugar de almacenamiento persistente a la que la aplicación pueda tener acceso. A través del proveedor de contenido, otras aplicaciones pueden consultar o incluso modificar los datos (solamente si el proveedor de contenidos de esa aplicación lo permite).

El modelo de desarrollo en Android nos invita a los desarrolladores a pensar siempre en hacer los datos de nuestras aplicaciones disponibles para otras aplicaciones. De manera que cuando creamos un proveedor de contenido, podemos tener un control completo de nuestros datos y definir la forma en que éstos serán accesados.

Un ejemplo sencillo de esto es el proveedor de contenido que tiene Android para gestionar la información de contactos (agenda) del teléfono. Cualquier aplicación con los permisos adecuados puede realizar una consulta a través de un proveedor de contenido comoContactsContract.Data para leer y escribir información sobre una persona en particular.

Services (servicios). Las actividades, las intenciones y los proveedores de contenido explicados arriba son de corta duración y pueden ser detenidos en cualquier momento. Por el contrario, los servicios están diseñados para seguir corriendo, y si es necesario, de manera independiente de cualquier actividad. El ejemplo más simple para aterrizar este concepto es el del reproductor de música, que es un servicio que puede mantenerse corriendo mientras mandamos un SMS o realizamos alguna otra función en nuestro teléfono.

Dependiendo de la fuente consultada o el autor, podrán encontrar también un elemento llamado Broadcast receivers (receptores de radiodifusión). Este componente responde a las notificaciones de difusión de todo el sistema como por ejemplo que la pantalla se ha apagado, que la batería del teléfono está por terminarse o que una fotografía ha sido tomada. Las aplicaciones también pueden lanzar este tipo de notificaciones, un ejemplo de ello es el aviso de que alguna información ha terminado de descargarse en el dispositivo y se encuentran disponibles para su utilización.

Aunque los broadcaster receivers no muestran una interfaz de usuario, pueden crear notificaciones en la barra de estado del teléfono para avisarle al usuario cuando un evento de este tipo se genera. Podemos pensar en estos elementos como el medio por el cual otros componentes pueden ser iniciados en respuesta a algún evento. Cabe mencionar que cada una de las emisiones de los broadcaster receivers se representa como una intención.

Un aspecto único y útil del diseño del sistema operativo Android es que cualquier aplicación puede hacer uso de otro componente de otra aplicación.  Supongamos que la aplicación requiere que el usuario tome una fotografía con la cámara del teléfono; es probable que exista otra aplicación que haga exactamente eso, por lo que resultará más fácil reutilizar esa función que programar una específica en nuestra aplicación. Para ello no es necesario incluir o vincular el código de la aplicación de la cámara, simplemente hará falta iniciar la actividad que se encargue de capturar la foto. Una vez hecho, la foto estará disponible para usarla en la aplicación “principal”. Para el usuario parecerá que la cámara de su teléfono es una parte de la aplicación.

Debido a que el sistema Android ejecuta cada una de las aplicaciones en un proceso separado con permisos de archivos que pueden restringir el acceso a otras aplicaciones, las aplicaciones no pueden activar de forma directa un componente de otra aplicación. El único que puede hacer esto es el sistema operativo en sí. Por lo tanto, para activar un elemento de otra aplicación, debemos pasarle un mensaje al sistema dónde se especifique qué elemento es el que necesitamos correr. De esta manera el sistema activará el componente y podremos manipularlo según sea nuestra necesidad.

Todos los elementos expuestos en este post son objetos y su comportamiento está definido en su correspondiente clase base convirtiendo a cada elemento en una subclase del elemento original. Esto lo hacemos por medio de la herencia, una característica básica de Java y de los lenguajes orientados a objetos, y que nos evitará tener que volver a implementar aspectos comunes en todos los objetos del mismo tipo, y poder al mismo tiempo, personalizar su comportamiento tanto como lo necesite nuestra aplicación por medio de la sobre escritura de los métodos de la clase padre.

Espero que este post te haya sido de utilidad, es un tema que hemos repetido varias veces, pero siempre es útil tener a mano esta información.