Bitácora de Javier Cancela

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.

CNET publicó ayer una entrevista con el CEO de Symbian titulada Symbian CEO pitches middle ground between iPhone, Android (algo así como ‘El CEO de Symbian se posiciona en terreno intermedio entre iPhone y Android’). Es la primera entrevista que leo del principal ejecutivo de Symbian, llamado Nigel Clifford, y si algo me ha llamado la atención es cierta falta de convicción en algunas de las declaraciones, como si no tuviese una estrategia clara con la que afrontar los retos que se le vienen encima.

Symbian es en la actualidad, y desde hace ya unos años, el líder de ventas en su sector. El único mercado en el que Symbian es irrelevante es el norteamericano, dominado por RIM, Microsoft y el Mac OS del iPhone. El señor Clifford achaca esta situación a las características del mercado USA, en el que la estrategia de las operadoras ha sido apostar por dispositivos de gama baja para minimizar el coste de las subscripciones. Sin embargo, no veo cómo eso explica el retraso de Symbian frente a los demás sistemas operativos de smartphones.

La parte más interesante de la entrevista está en las preguntas sobre el iPhone y Android. Las respuestas del CEO de Symbian pretender dar a entender que:

• su sistema, al contrario que el de Apple,”…deja experimentar a la gente, proporciona SDKs y APIs fáciles de usar”
• ellos, al contrario que Google, quieren “hacer dinero con esto. [...] Tenemos una plataforma con una audiencia entendida, realmente lucrativa que va a pagar si les das una buena aplicación”

La única ventaja de Symbian es su posición dominante en el mercado. A partir de ahí, el iPhone posee un factor cool que ni Nokia ni sus socios van a poder igualar, con un entorno de desarrollo no creo que sea más restrictivo que el de Symbian. Y si hablamos de hacer dinero, el punto de distribución único al que obliga Apple propociona una gran oportunidad a la “larga cola” de desarrolladores que no pueden permitirse una distribución propia efectiva. En cuanto a Android, con un entorno de desarrollo muy flexible y la plataforma más abierta del mercado, se postula como la alternativa más prometedora para la audiencia entendida e interesada en buenas aplicaciones.

Me gustó sin embargo la frase con la que resumió la diferencia entre los PCs y los smartphones: dadas las restricciones de estos últimos, “la necesidad de hacer las cosas de forma muy elegante es un imperativo”.

Un lector del blog me ha escrito un correo a una de las cuentas de Ipoki y me ha hecho pensar en un par de cosas.

Primero, en que no tenía formulario de contacto. El plugin cformsII para WordPress se ha encargado de arreglarlo.

Segundo, en lo difícil que resulta decidir cuándo un móvil es “antiguo”. El correo hablaba de la dificultad de trabajar con números en punto flotante⁽¹⁾ en móviles con CLDC 1.0, ya que no hay soporte nativo. Estos móviles no tienen hardware dedicado a trabajar con punto flotante y las emulaciones por software son excesivamente lentas. El caso es que, pese a ser móviles antiguos (creo el último de Nokia con CLDC 1.0 es el 3230 y es del 2004), todavía existe un número importante de ellos en uso.

Así que la pregunta es: ¿cuándo compensa tener en cuenta estos móviles en el desarrollo? Mi respuesta: nunca. No debemos ser tímidos a la hora de descartar dispositivos por su antigüedad, ya que el número de potenciales usuarios perdidos disminuye con el tiempo, y a mucha velocidad. Preocuparnos de cómo hacer que algo funcione en un dispositivo de hace tres años consumirá recursos que estarán mejor empleados en una versión para el iPhone, o para S60 3rd Ed. FP2, o para Android. Si es posible que funcione en mi viejo N70 con algunos cambios menores, estupendo. Pero los dispositivos más recientes proporcionan formas cada vez más cómodas y eficaces de hacer las cosas, y generalmente no vale la pena tomarse el trabajo de pensar cómo hacer las mismas cosas para teléfonos de una generación anterior. Hablo por supuesto de desarrolladores amateurs, o de autónomos o pequeñas empresas. Las empresas grandes (o veteranas) tienen herramientas, recursos y metodologías para sacar el último juego Java para un montón de modelos distintos y rentabilizar el desarrollo. Pero no es mi caso, e imagino que tampoco el da la mayoría de lectores de este blog.

⁽¹⁾ Realmente en español lo correcto es “coma flotante”, pero no puedo evitar que me suene raro. Históricamente el punto es utilizado sobre todo en el mundo anglosajón, con la coma siendo la norma en Europa y Sudamérica, entre otros sitios. Imagino que la influencia de Internet acabará decantando la balanza a favor del punto.