4.2. Interfaz de una aplicación

Cuando pensamos en una aplicación, lo primero que imaginamos es su aspecto. Diseñamos su comportamiento y lo estructuramos en diferentes pantallas, de modo que el usuario irá pasando de una pantalla a otra para obtener su funcionalidad.

En Android, cada pantalla que mostremos en el terminal, puede representarse como una actividad diferente y el usuario irá de una pantalla (actividad) a otra cuando vaya tocando sobre las diferentes opciones que aparezcan. En otras palabras: Las actividades son la parte que los usuarios verán de nuestra aplicación.

Esta es una de las características esenciales de la programación en Android. A diferencia de lo que ocurre en otros entornos de programación, donde la ejecución es lineal, en Android tenemos que pensar en acciones o eventos que modifican el estado de la aplicación. Así, en lugar de establecer en qué estado concreto se encuentra una actividad, nos centraremos en las acciones a realizar cada vez que la actividad cambie de estado.

En este sentido, las técnicas de programación que emplearemos están más relacionadas con los applets o los servlets de Java, que con otras técnicas de programación más tradicionales.

Cada vez que se inicia una actividad, el sistema operativo emplea una cantidad considerable de recursos. Para empezar, se necesita crear un nuevo proceso, a continuación, asignar memoria a los diferentes objetos que deben aparecer en la interfaz gráfica y, por último, se representará en la pantalla. Lógicamente, todo este trabajo no puede desecharse sólo porque el usuario cambie de pantalla. Para evitarlo, se diseñó el Administrador de Actividades, un componente del sistema operativo diseñado para gestionar las diferentes actividades de las aplicaciones que se ejecuten en Android.

Esta es una característica que debemos tener en cuenta cuando diseñemos un programa, porque lo habitual en otras plataformas es que sea la aplicación la que decida cuando se crean y se destruyen sus propios procesos, mientras que en Android, la aplicación creará sus actividades, pero será el sistema operativo quien decida cuándo terminan (y se liberan sus recursos).

Quizás se entienda mejor esta idea poniendo un ejemplo: Imagina que utilizas tu dispositivo Android para establecer una alarma que te avise a una determinada hora en unos días concretos de la semana. El proceso que seguiremos para fijar dicha alarma se ilustra en la siguiente imagen:

Como puedes ver, en la tarea pueden verse implicadas hasta seis pantallas diferentes (sin incluir la pantalla del menú de aplicaciones del propio sistema operativo). Aunque no sepamos cómo está programado internamente el programa, podemos suponer que están implicadas, al menos, seis actividades diferentes.

No parece razonable que, cuando el usuario toque sobre el elemento que le permite fijar la hora, el sistema operativo emplee sus recursos para crear la actividad que nos permita establecer ese dato y que, cuando lo guarde, todos los recursos se liberen. Esto implicaría que, si el usuario cambia inmediatamente de opinión y quiere volver a cambiar la hora, el sistema tendría que volver a dedicar el mismo esfuerzo para crear de nuevo la misma actividad.

Si el sistema permite que la actividad siga existiendo durante un tiempo, podría volver a ella repetidamente, de una forma sencilla y sin emplear recursos complementarios. De esta forma, mejorará la velocidad de la interfaz y, por lo tanto, también la experiencia general del usuario.

Otro motivo a favor de este planteamiento es que la inicialización de la actividad consume un tiempo de computación considerable, que afecta directamente al consumo de batería del dispositivo. De esta forma, si se inicializaran las actividades de forma repetida e innecesaria, se vería afectada, directamente, la duración de la batería.

Por supuesto, si el sistema dispone de poca memoria, podría no poder permitirse el destinarla a guardar actividades que se encuentren inactivas y, en ese caso, podría optar por liberar sus recursos. Esta misma decisión puede tomarse con actividades que llevan mucho tiempo en memoria y no han vuelto a ser requeridas.

El sistema también puede decidir si una actividad perdura o es eliminada en función de lo importante que pueda ser ésta para el usuario. Al fin y al cabo, probablemente sea más importante para el usuario que suene la alarma en el momento adecuado, que seguir navegando por Internet o jugando un determinado juego

En definitiva, el sistema ordenará los procesos según su importancia relativa con respecto a los demás y el estado en el que se encuentran.

En cualquier caso, el Administrador de Actividades es el componente del sistema operativo que toma todas estas decisiones.