Bitácora de Javier Cancela

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.

Hablaba en mi anterior entrada (La difícil posición de Symbian) de lo abierto de la plataforma de Google. Adjudicaba ese adjetivo tanto por la libertad que da el sistema a los desarrolladores como por la promesa de liberar el sistema con licencia Open Source. Sin embargo, en los seis meses transcurridos desde la presentación de Android sólo se ha liberado el código fuente del kernel (Android Linux Kernel Tree), lo que ha llevado a mucha gente a preguntarse en los grupos de Google sobre el por qué de tanto retraso.

A través de un artículo de CNET (Google’s Android work far from finished) llego a un hilo de discusión de uno de estos grupos ( Android source isn’t available ?????????) donde un desarrollador de Android da algunas explicaciones. Confirma que casi todo el código fuente de la plataforma será liberado: el propio de Google con licencia Apache 2.0, el resto con la licencia original (GPL, LGP, BSD…). Esto incluya la mayor parte de las aplicaciones del móvil (aunque no GMail, por ejemplo). Las partes del sistema que se mantendrán cerradas serán algunas relacionadas con los drivers de dispositivo, a causa de problemas con la propiedad intelectual. Eso sí, no da fechas, pero deja caer que será después de que aparezcan los primeros dispositivos físicos.

Como se menciona en el artículo de CNET, Google se enfrenta a un doble desafío. Por una parte lanzar una plataforma lo suficientemente abierta como para que todo el mundo pueda hacer lo que considere útil, interesante o lucrativo (y la licencia Apache está para permitir a terceros comercializar software derivado de Android). Por otra, evitar la fragmentación que tan difícil hace las cosas a otras plataformas móviles. La clave estará en la Open Handheld Alliance, compuesta por Google y sus socios, que deberá velar porque la evolución de la plataforma sea a la vez rápida y estable.