Bitácora de Javier Cancela

El primer paso para relacionar conceptos es conocer los conceptos. Y en Android existen una serie de conceptos que suponen la piedra y el mortero de cualquier aplicación.

El archivo AndroidManifest.xml

Este archivo está presente en todas las aplicaciones Android. Su contenido especifica los componentes de la aplicación, así como la configuración global de la misma. Su descripción se muestra en esta página de la documentación.

En una aplicación habitual, dentro de este archivo habrá un elemento <application>, dentro del cuál habrá uno o varios elementos <activity>. Cada uno de estos elementos supone una interacción con el usuario (generalmente una ventana), y se corresponde con una clase que hereda de la clase Activity.

La clase Activity

Según la documentación de Google, una Activity es una cosa única con un objetivo determinado que el usuario puede hacer. Esta es una definición abstracta. Podemos concretar más la definición diciendo que una Activity (es decir, una clase de nuestra aplicación que hereda de la clase Activity) se presenta al usuario como una ventana. Esta clase crea una ventana que muestra una interfaz de usuario, la cual está definida a su vez en una instancia de otra clase, la clase View.

Cuando se ejecuta una aplicación Android lo primero que se muestra al usuario es la ventana definida por la actividad que esté marcada en el AndroidManifest.xml como principal. Las actividades se gestionan como una pila, así que desde una actividad se puede llamar a otra, y cuando esta finaliza se retorna a la actividad inicial.

Una actividad puede estar ejecutándose, en pausa o detenida. Simplificando, está en ejecución cuando es visible e interacciona con el usuario, está en pausa cuando es visible pero otra ventana, transparente o que no ocupe toda la pantalla, tiene el foco, y está detenida cuando no es visible. En todos estos casos la clase mantiene su información.

En la documentación encontramos un gráfico que ilustra el ciclo de vida de una actividad:

Aunque no es necesario entender de momento todos los detalles de este gráfico, en él se ven los estados por los que puede pasar una actividad (los óvalos coloreados) y los eventos que se disparan en dichos estados (los rectángulos grises):

• Cuando se crea una actividad, se invoca el evento onCreate(). Este evento sólo se invoca la primera vez que se llama a una actividad, o bien cuando se llama después de que el sistema haya tenido que eliminarla por falta de recursos (más sobre esto en próximos artículos).
• onStart() es el evento invocado cuando cada vez que la actividad se muestra al usuario. Es decir, la primera vez que se muestra, y las veces que en las que vuelve a aparecer tras haber estado oculta. En este último caso, se invoca onStop() al desaparecer y onRestart() inmediatamente antes de reaparecer.
• onFreeze() y onPause() son llamadas secuencialmente cuando otra actividad va a pasar en encargarse de la interacción con el usuario. Tras onPause() la actividad permanece en un estado de espera en el que puede ocurrir que la aplicación sea destruida, por lo que estos eventos se usan para consolidar la información que no queremos que se pierda. Si la actividad no se destruye volverá al primer plano con el evento onResume().

La idea importante con la que quedarse es que una actividad que esté pausada o detenida (tras onPause() u onStop()) puede ser destruida por el sistema si previo aviso, por lo que deberemos encargarnos de guardar antes la información necesaria (durante onFreeze() y onPause()). Los detalles lo veremos en una próxima entrada.

Diego y Alberto participan esta semana en la conferencia Where2.0. También estarán el fin de semana en el WhereCamp que organiza Google en sus instalaciones.

Lo cuenta Diego en el blog de Ipoki: Nos vamos a Silicon Valley!

Una de las partes menos agradecidas de la programación en JavaME es el diseño de la interfaz de usuario. El paquete javax.microedition.lcdui de MIDP está orientado a la creacion de unas interfaces de usuario muy básicas, que se adecuan bien a las capacidades de los móviles de hace unos años pero que ahora mismo suponen una limitación para la potencia de cualquier dispositivo actual.

Como alternativa, Sun ha liberado una librería llamada LWUIT (Lightweight UI Toolkit), basada en Swing. Esta librería propociona un nuevo conjunto de componentes visuales, y ofrece la posibilidad de incorporar animaciones, temas y transiciones en nuestros programas JavaME.

En java.net podemos encontrar un tutorial para ir viendo el funcionamiento de esta API.

Vía: Lightweight UI Toolkit (LWUIT) for Java ME

Lo cuenta Andrés en Finalistas en Telematics Awards 2008.

Siempre resulta motivador compartir nominación con T-Mobile o Microsoft.

Una pequeña paradoja que se produce a la hora de aprender cualquier habilidad técnica, como un lenguaje de programación, es que para los más novatos en la materia la dificultad está no tanto en encontrar documentación completa, correcta o incluso bien redactada, sino en encontrar material lo suficientemente básico como para no perderse desde el inicio en los pequeños detalles que no se explican por parecer obvios.

Empezar a programar, o hacerlo en un sistema desconocido, supone siempre una curva de aprendizaje inicialmente muy empinada, durante la cual la tarea más importante es lo que se suele denominar “asimilar conceptos”: aprender las nociones básicas y entender cómo estas se relacionan entre sí. Aprender algo es sobre todo ver cómo un concepto nuevo se relaciona con otros conceptos ya conocidos, y establecer estas relaciones es la parte más elusiva del proceso.

A cualquier programador con un poco de experiencia le resulta difícil ver (o recordar) qué red de conceptos básicos tuvo que tejer en sus inicios para aprender los fundamentos de un lenguaje o entorno, y por ese motivo en ocasiones los programadores veteranos encuentran difícil instruir a los más inexpertos.

Dejar constancia de los problemas encontrados, las dudas resueltas y los errores cometidos en el proceso de aprendizaje resulta útil no sólo para consolidar lo aprendido sino también para mostrar a otros el trayecto recorrido, de forma que puedan evitar caminos sin salida o vueltas innecesarias. Aprender de los errores propios es útil, pero aprender de los ajenos es menos doloroso.

Sirva todo esto de justificación para una serie de artículos en los que, con la torpeza propia del novato, iré contando el proceso de desarrollo del plugin de Ipoki para Android, cuya primera y básica versión ya está casi acabada.

He movido el blog a un nuevo dominio: http://javiercancela.com, albergado directamente en WordPress.com. El feed de feedburner se mantiene (feed.feedburner.com/bitacoramovil), pero http://blogs.ipoki.com/feed/ pasa a http://javiercancela.com/feed/.

La idea es escribir aquí todo el contenido no relacionado directamente con Ipoki (aunque en cierto modo todo lo que escribo aquí sobre programación móvil viene motivado por Ipoki), y utilizar los blogs oficiales de Ipoki (http://blogs.ipoki.com y http://blogs.ipoki.com/es/) para el contenido específico de Ipoki.

No soy usuario de NetBeans, la principal alternativa a Eclipse para programar con Java ME, pero para quien sí lo sea aquí está la nueva versión: NetBeans IDE 6.1 Download.

Por lo poco que he visto, la principal novedad es el soporte SVG mejorado.

Vía: NetBeans Mobility 6.1 (final) is now available

Tras un par de semanas sin conexión por culpa de una mudanza, dos entradas de Morten Hjerde me dan la excusa para un pequeño apunte con el que volver al blog.

En Mobile screen size trends y More on mobile screen size trends hace un resumen de los tamaños de pantalla estándar en los dispositivos actuales y los tamaños propuestos por los fabricantes en sus dispositivos de última generación.

Resultan muy ilustrativos los gráficos que muestran el tamaños en píxeles y la proporción entre dimensiones por un lado, y el tamaño en pulgadas por el otro:

Conclusiones: se impone un modelo de pantalla adaptado a la visualización de vídeo, que resulta también adecuado para navegar por páginas no optimizadas para móviles. Así, el problema del diseño se desplaza al dispositivo de entrada: teclados virtuales frente a teclados físicos incrustados de alguna forma en el dispositivo; pantallas táctiles con interfaces de usuario adaptadas a las necesidades de la navegación móvil.

Veremos que soluciones proponen los dispositivos de gama alta que aparezcan en los próximos meses, como los primeros Android o las BlackBerry de la serie 9000.

Symbian ha publicado un documento (Native and Java ME Development on Symbian OS [PDF]) que compara las aplicaciones Java ME con las aplicaciones nativas en los sistemas operativos Symbian. El artículo analiza el rendimiento de ambos tipos de apliciones y las características relativas al desarrollo: sencillez, APIs soportadas, seguridad, portabilidad, herramientas… También habla de las peculiaridades de la versión de Java ME de Symbian, del rendimiento en los juegos y de la economía de ambos tipos de aplicaciones.

El documento es interesante porque no supone un intento de demostrar la superioridad de las aplicaciones nativas de Symbian sobre las aplicaciones Java ME (como pensé en un principio) sino en un verdadero análisis de las ventajas de unas frente a otras. Las conclusiones no son excesivamente interesantes por ya conocidas (las aplicaciones nativas compensan cuando el rendimiento es crítico o es necesario acceder a algunas características de bajo nivel), pero los detalles de la comparativa constituyen una lectura de los más interesante para los desarrolladores móviles.

Vía: Mobile Phone Development

Programar con Android está resultando una tarea agradable. Un sistema nuevo, diseñado desde cero, debe dar solución a los problemas que, por motivos históricos, están presentes en otros sistemas más veteranos. En algunos aspectos Android apunta en la buena dirección, como en el diseño de la interfaz de usuario, que está resuelto con elegancia. En otros, como el rendimiento o la fragmentación de dispositivos, habrá que esperar a que el sistema exista en algún lugar más que el emulador. También hay defectos, pero el sistema todavía está en beta, sufriendo modificaciones, así que de momento seremos condescendientes.

Lo cierto es que al principio la introducción de nuevos términos resulta un poco confusa, sobre todo después de la familiaridad que produce un lenguaje y un entorno de programación conocidos. Conceptos como Activity o Intent pueden ser un poco elusivos al principio. Uno de los problemas es que, pese a la abundante documentación, no hay suficientes ejemplos que den una visión global de cómo funcionan los mecanismos internos de una aplicación, al menos para los que tenemos dificultades con los conceptos abstractos y necesitamos ver las cosas en código. Pero una vez visto algo de código (como el que se puede encontrar en anddev.org) las cosas comienzan a encajar y aparece ante nosotros un framework francamente interesante.

Todavía falta algo de tiempo para ver los primeras sistemas reales en el mercado, pero mientras tanto veremos en próximas entradas cómo resultan los primeros pasos desarrollando para el emulador. Si comercialmente Android resulta un éxito, será tiempo bien invertido. Si no, al menos resultará divertido. Más que con otros sistemas, por lo menos.