Construyendo aplicaciones: android 101

Muy buenas, comencemos a jugar con "mi primera aplicación android". Para saber si estás preparado para la batalla deberás preguntarte a ti mismo las siguientes cuestiones:

1. ¿Conoces Java?
2. ¿Has desarrollado (digo bien, sí, desarrollado, no programado) aplicaciones con Java?
3. ¿Lo has hecho sin utilizar un framework que te permitiera abstraerte de los Listeners?

Si la respuesta a las tres preguntas es sí, estarás en disposición de meter mano a android sin muchos problemas (siempre habrá algunos ... porque si no, ¿dónde estaría la diversión?)

Si no es así tendremos que encontrar soluciones:

1. Si conoces cualquier programa orientado a objetos me sirves ... si no siempres puedes mirarte esto.
2. Si no has desarrollado aplicaciones en Java ... bueno, también me sirves, pero mírate también por encima lo de antes, que nunca viene mal recordar.
3. Si no has desarrollado aplicaciones con las tediosas referencias en los constructores entre los objetos ni las asociaciones a los Event Listener y pensabas que te ibas a librar,..., bueno, tienes dos opciones, bien dejas de leer, bien asumes tu error y aprietas el culo.

Con todas estas preguntas no estoy diciendo que android sea java [android.equals(Java)==false, más como dice plusminus], android incorpora un numero considerable de librerías que permiten que el desarrollo sea muy similar a Java (eso sí, las han implementado ellos, por lo que encontraremos curiosidades como métodos de java.lang.Class que no están implementados, como getCanonicalName) y la compilación la realiza un compilador Java abierto y modificado para que en lugar de bytecode .class los cree .dex.
Eso só, no hace uso de la JVM para la ejecución, sino de la Dalvik Virtual Machine [dalvik.equals(JVM) == false].

Dicha máquina virtual es la alternativa de google para desvincularse de Sun en la medida de lo posible, y
así complicarnos la vida al resto de los mortales acostumbrados a las ventajas (e inconvenientes) de Java.
DVM depende del kernal 2.6 de linux, utilizándolo como capa de abstración sobre el hardware y haciendo uso de sus servicios de sistema para la admistración de memoria, procesos, pila de protocolos de red entre otros.

Así cada aplicación android es equivalente a un proceso Linux. Eso sí, en este caso es la propia máquina virtual la que elige cuándo se inicia el proceso y cundo debe ser finalizado y liberada su memoria.

No quiero empezar a desmenuzar ahora los componentes de una aplicación, pero en el próximo post leed con atención los IntentReceiver (una especie de receptores de eventos), que lanzan hebras en paralelo al proceso en cada recepción de Intent. Cuando una aplicación incluya uno o más de estas clases su proceso será creado nada más arrancar el dispositivo móvil, ya que debe permanecer a la escucha de eventos (Intents en android).


Bueno, y como lo pone en la página, aquí dejo una clasificación de los procesos que pueden existir en función de la importancia que le asigna la máquina virtual, pero que vamos, os lo podeis saltar perfectamente, porque ahora os vais a quedar igual.

• Proceso de primer plano: es un proceso que incluye una clase que hereda de Activity (un componente de las aplicaciones que veremos en el próximo post) en la pantalla y con la que el usuario está interactúando (su método "onResume()" ha sido llamado) o una clase que hereda de IntentReceiver está ejecutándose (su método "onReceiveIntent()" se está ejecutando). Estos procesos sólo serán eliminados cómo último recurso, si es que la memoria está tan baja que ni siquiera estos procesos pueden continuar corriendo. Si esta fuera la situación, el dispositivo probablemente alcanzó un "memory paging state" y esta acción es necesaria para mantener la interface del usuario con capacidad para responder al usuario.
• Proceso visible: es un proceso que incluye una Actividad (Activity) visible en la pantalla, pero no en primer plano (su método "onPause()" ha sido llamado). Este tipo de proceso es considerado extremadamente importante y no será eliminado a menos sea extrictamente necesario para mantener a todos los procesos de primer plano corriendo.
• Proceso de servicio: es un proceso que incluye iuna clase que hereda de Service, que ha sido iniciado (que no inicializado, qeu esa palabra no existe en castellano por mucho que insistamos) con el método "startService()". Estos procesos no son directamente visibles al usuario, pero el sistema siempre tratará de mantener esos procesos corriendo a menos que los niveles de memoria comiencen a comprometer el funcionamiento de los procesos de primer plano, sean visibles o no.
• Proceso de fondo: es un proceso que incluye al menos una Actividad que no es visible al usuario (su método "onStop()" ha sido llamado). El sistema puede eliminar estos procesos en cualquier momento para reclamar la memoria que estén usando para entregársela a cualquiera de los tres tipos de procesos anteriormente descritos. Generalmente, hay muchos de estos procesos corriendo, por lo tanto el sistema mantiene una lista LRU para asegurar que el último proceso visto por el usuario sea el último en ser eliminado en caso que se requiera memoria.
• Proceso vacío: es un proceso que no hospeda a ningún componente de aplicación activo. La única razón para mantener ese proceso es tener un "cache" que permita mejorar el tiempo de activación en la próxima oportunidad que un componente de su aplicación requiera correr. Como consecuencia de esto, el sistema con frecuencia va a eliminar estos procesos para mantener el balance entre los recursos de cache utilizados por estos procesos con los utilizados por los "cache" del kernel del sistema.

Fuentes:
Application life cycle
Traducción de la documentación en línea de android
Android Developer Book