Bitácora de Javier Cancela

Como hemos mencionado en alguna ocasión, los emuladores son una herramienta imprescindible para el desarrollo de aplicaciones móviles pero no garantizan el correcto funcionamiento de la aplicación en los dispositivos reales. Dada la gran variedad de modelos existentes en el mercado es imposible que un desarrollador freelance o una pequeña empresa pueda disponer de todos los que le interesan. Para facilitar la vida a sus desarrolladores Nokia ha comenzado a alquilar algunos (de momento pocos) de sus modelos al precio de 25€ por tres semanas.
Más información: Device Loaner Program.
Vía Mobile Phone Development.

¿Qué entorno de desarrollo es el más aconsejable para desarrollar aplicaciones J2ME? Partamos de la suposición, bastante razonable, de que queremos que se ejecute en la mayor variedad de teléfonos móviles posible. Como veíamos en la primera parte de este artículo, J2ME no puede garantizar que un mismo código se ejecute correctamente en todos los dispositivos aunque estos implementen las mismas especificaciones, por lo que puede ser necesario desarrollar varias versiones de nuestra aplicación.

Las marcas líderes en la comercialización de dispositivos móviles con soporte J2ME varían según el mercado específico al que nos dirijamos, pero casi en cualquier lista nos vamos a encontrar a Nokia, Samsung, Motorola, Sony Ericsson y RIM (los fabricantes de BlackBerry). Dejando de lado las BlackBerry, a las que dedicaré un artículo posterior, una buena idea es montar un entorno de desarrollo que nos permita utilizar las SDKs y los emuladores de estas marcas.

¿Y qué IDE utilizaremos para este desarrollo? Esta vez nos lo han puesto fácil: Nokia, Motorola y Sony Ericsson facilitan herramientas basadas en Eclipse para el desarrollo específico sobre sus plataformas (no he encontrado nada sobre Samsung, su portal de desarrollo es con diferencia el peor de los tres). Armados con estas herramientas, las SDKs correspondientes y la documentación y ejemplos que en ellas se encuentran ya podemos empezar a programar.

Yo personalmente comienzo siempre con Nokia, usando actualmente Eclipse con el plugin EclipseME y la SDK adecuada (por ejemplo, la de S60 3rd Ed. FP2). Para Nokia mucha gente usa NetBeans con el Mobility Pack; también es una opción perfectamente válida (hasta hace no mucho Nokia tenía una herramienta llamada Carbide.j, basada en Eclipse; en la actualidad está discontinuada). Una vez que tengo código que funcione, lo voy probando en los emuladores de otras plataformas y en los móviles que tenga a mano. Si da problemas, lo paso al entorno de desarrollo de la plataforma conflictiva y lo pruebo con sus SDKs modificando aquello que pueda fallar.

Si no queréis andar buscando por las páginas de cada fabricante, aquí dejo unos enlaces:
- Eclipse
- EclipseME
- SDKs de Nokia
- MOTODEV Studio (entorno de desarrollo de Motorola basado en Eclipse)
- SDKs de Motorola
- Sony Ericsson - Herramientas y Doc
- SDK de Samsung

Entradas relacionadas:

Introducción al desarrollo de aplicaciones para teléfonos móviles: Symbian
Introducción al desarrollo de aplicaciones para teléfonos móviles: Windows Mobile
Introducción al desarrollo de aplicaciones para teléfonos móviles: J2ME (I)
Introducción al desarrollo de aplicaciones para teléfonos móviles: BlackBerry

Revisando entradas viejas de blogs pendientes por leer (que se te acumulen entradas durante meses es síntoma de que estás suscrito a más blogs de los que puedes seguir) me he encontrado esta referencia a una serie de pequeños libros editados por Symbian que cubren aspectos básicos del desarrollo para este SO. Los enlaces que aparecen en la entrada anterior ya no son correctos, así que aquí están corregidos:
Essential Symbian OS booklets
Using Symbian OS booklets
Essential UI booklets

No había reparado en él la última vez que visité esa página, pero uno de ellos está traducido al español:
Primeros pasos

Mencionaba en el anterior artículo que Sun había liberado el código fuente de J2ME convirtiéndolo en un proyecto Open Source. Lo cierto es que Sun tiene un proyecto en desarrollo llamado JavaFX que incluye un sistema operativo para dispositivos móviles, JavaFX Mobile.

Los dispositivos para los que se diseñó J2ME evolucionan a gran velocidad; un televisor de hoy en día puede llevar en su interior la misma capacidad de proceso que un ordenador personal de hace no demasiados años, y Sun quiere aprovechar eso con un sistema operativo que incluye la especificación J2SE casi entera. De todos modos es proyecto de futuro: tendrá que pasar bastante tiempo hasta que veamos dispositivos JavaFX en el mercado.

Todo esto no significa que J2ME quede obsoleto, simplemente que Sun cede la responsabilidad sobre su desarrollo a los integrantes del proyecto phoneME.

Más información en este artículo de CNET.

El nombre real de J2ME es ‘Java Platform, Micro Edition’, aunque J2ME sigue siendo el término más habitual.

J2ME es un subconjunto de Java orientado a dispositivos con recursos limitados, es decir, a un hardware en el que características como la memoria o la velocidad del procesador son muy inferiores a las de un ordenador convencional. Por ejemplo, un teléfono móvil. Desde el año pasado J2ME es Open Source, y el proyecto que se encarga de mantenerlo y desarrollarlo se llama phoneME.

Al igual que ocurre con el J2SE, la principal virtud de J2ME es su habilidad para ejecutarse en distintas plataformas: casi cualquier móvil de hoy en día incorpora soporte Java (las excepciones más significativas son el iPhone y los móviles con Windows Mobile). Sin embargo, no todos los dispositivos tienen el mismo soporte de J2ME. Veamos por qué.

J2ME se divide en configuraciones (configurations), perfiles (profiles) y APIs opcionales. Una configuración define un tipo de dispositivo en función de las características de su hardware: sus limitaciones, sus capacidades… y le asigna una máquina virtual y un conjunto de APIs adecuados a ese hardware. En la actualidad existen dos configuraciones: CDC (Connected Device Configuration), utilizada sobre todo en sistemas de telemetría, automoción o domótica, y CLDC (Connected Limited Device Configuration) que es una versión más limitada y que es la que nos interesa por estar presente en la mayoría de los móviles.

Dentro de una configuración, un perfil nos define ciertas características concretas, como la interfaz de usuario. Existen tres perfiles para la configuración CLDC: MIDP (Mobile Information Device Profile), que es la usada en los teléfonos móviles y por tanto la que nos interesa, IMP (Information Module Profile) que es una versión de la anterior sin interfaz de usuario, y DoJa, destinado a un tipo de móviles japoneses.

Finalmente, cada dispositivo móvil puede incluir soporte para distintas APIs opcionales. Por ejemplo, un dispositivo con Bluetooth puede disponer de la Bluetooth API (JSR 82), o un móvil de gama media/alta quizás venga preparado para leer y procesar información geolocalizada con la Location API (JSR 179). Como estas capacidades varían de dispositivo en dispositivo, hay que acudir a las especificaciones de cada uno para ver qué APIs soportan. Por ejemplo, aquí podéis comprobar los modelos Nokia, aquí los Motorola o aquí los Sony Ericsson. Sun también proporciona una lista de dispositivos de distintos fabricantes.

Ocurre que cada fabricante realiza las implementaciones de las APIs J2ME de sus móviles. Aunque para ello se basan en una implementación de referencia de Sun, en la práctica se pueden encontrar diferencias significativas en el comportamiento de distintos dispositivos para una misma función, fallando en unos móviles lo que funciona en otros. En ocasiones, esto supone la necesidad de desarrollar más de una versión de la misma aplicación.

Recapitulando, para programar móviles usaremos la configuración CLDC con el perfil MIDP. La última versión de CLDC es la 1.1, y la última de MIDP es la 2.0; estos son las versiones que incorporan los móviles recientes, para modelos más antiguos podemos encontrarnos con CLDC 1.0, que por ejemplo no soporta operaciones en punto flotante, y MIDP 1.0, que no da acceso a funciones de sonido o pantalla completa.

Entradas relacionadas:

Introducción al desarrollo de aplicaciones para teléfonos móviles: Symbian
Introducción al desarrollo de aplicaciones para teléfonos móviles: Windows Mobile
Introducción al desarrollo de aplicaciones para teléfonos móviles: J2ME (y II)
Introducción al desarrollo de aplicaciones para teléfonos móviles: BlackBerry

La empresa de publicidad móvil AdMob acaba de publicar un informe con datos sobre anuncios consultados, desagregados por país y modelo de móvil.

Llama la atención el número de anuncios servidos en cada país, pues el tercero en su ranking es Sudáfrica, por encima del Reino Unido, que es además el único país de Europa occidental que aparece en el informe. Imagino que esto será debido a que los clientes del AdMob son páginas destinadas al ámbito local de cada país, y el informe refleja la distribución geográfica de sus clientes.

El principal interés del informe está en los datos sobre modelos de móviles, que nos dan ciertas pistas sobre los terminales preferidos por la gente que navega con el móvil. En Estados Unidos, en contra de lo que yo hubiese supuesto, Motorola se impone a RIM, con el ya veterano RAZR V3 encabezando la lista. En la India, el dominio de Nokia es absoluto, con los modestos y antiguos 6030 y 6600 dominando la clasificación. Es el mercado británico el que muestra un resultado menos sorprendentes; aparte del chino ZTE F866, que figura en segundo lugar, la lista está encabezada por modelos Sony Ericsson de tercera generación.

No estoy seguro de si se pueden sacar conclusiones de estos datos. El número de anuncios servidos (85 millones en el menor de los casos) parece significativo, y el porcentaje de modelos no clasificados (un 11% del total) no es excesivo. De todos modos, sin conocer otros datos relevantes como las páginas que originaron las peticiones o los operadores desde los que se realizaron, no se puede dar mucha trascendencia a estos resultados.

Vía MobileCrunch.

Tres notas de prensa de Nokia: unas charlas sobre el futuro de la tecnología móvil, el anuncio de un proyecto conjunto con Reuters, y la más relevante para este blog, el anuncio de un nuevo sistema de búsqueda para MOSH.
¿Y qué es MOSH? Pues es un portal de Nokia que permite que los usuarios suban y descarguen fotos, vídeos, aplicaciones, documentos, juegos… etiquetando todo con tags y creando comunidades en torno a intereses comunes. Es decir, la web 2.0 condensada en un solo lugar, pero en versión móvil. De hecho tienen el sitio convencional en un dominio .com y el sitio móvil en un dominio .mobi. Todavía le quedan cosas por pulir, pero habrá que tener un ojo en el sitio.

Vía allaboutsymbian

Un blog interesante sobre rumores relacionados con Google: Ga Ga Gooogle.
En él hay unos cuantos posts interesantes. Por ejemplo, este sobre la Ley de la Movilidad. Extraigo (y traduzco) una cita.

Nuestra estrategia está basada en tres cosas. La primera es que los dispositivos móviles son muy personales. La gente los lleva consigo allí adonde va. Y a diferencia del PC de casa, la gente no comparte sus teléfonos móviles.
La segunda gran categoría en la que nos centramos es la de los servicios basados en la localización (location based services, LBS). La gente lleva sus móviles a todos lados, y generalmente busca información en el contexto de una ubicación.
[Y tercero] es importante asegurarse de que nuestras aplicaciones funcionan en cualquier lugar del mundo.

- Deep Nishar, Director de Product Management, Google

La entrevista de la que está extraída la cita tiene casi un año, pero aún así resulta igualmente interesante. En los próximos días hablaré más de los últimos movimientos de Google en relación a los servicios móviles.

Windows Mobile es el sistema operativo de Microsoft destinado a dispositivos móviles. La evolución de Windows Mobile, que se puede encontrar en la Wikipedia, refleja la evolución de los dispositivos de bolsillo durante los últimos años. Básicamente se originó en una versión del kernel de Windows para sistemas embebidos que fue creciendo hasta ser un sistema operativo para ordenadores de bolsillo (Pocket PCs) y smartphones.

Un Pocket PC es una PDA con sistema operativo Windows PocketPC o Mobile (según la versión). Como quiera que ya casi todas las PDAs incorporan teléfono móvil el concepto de PDA o PocketPC sin móvil probablemente desaparecerá pronto.
El término smartphone nunca tuvo una definición clara. La definición que da la Wikipedia (“…es un teléfono móvil que ofrece capacidades avanzadas más allá de un típico teléfono móvil, frecuentemente con funcionalidad similar a la de un ordenador personal.”) es lo suficientemente amplia como para resultar inútil, lo cual es apropiado para un término que hoy en día ya no tiene sentido: casi cualquier móvil en el mercado incorpora al menos una máquina virtual de Java que permite que sea programado. Con motivo de la aparición de la última versión de Windows Mobile, WM6, Microsoft redefinió estos términos para darles un poco de coherencia con las distintas modalidades de WM.

Para desarrollar aplicaciones para Windows Mobile 6 necesitamos bajarnos una de las SDKs disponibles: la Standard para Smartphones, o la Professional para Pocket PCs (normales o Phone Edition). Si no os habéis leído el enlace anterior, un SmartPhone para Microsoft es como un Pocket PC Phone Edition, pero más pequeño y sin Office Mobile.

Para instalar la SDK necesitaremos lo que se indica en la sección de requisitos de la página de descargas, donde puede sorprender este punto:

Microsoft Visual Studio 2005, Standard Edition or above (Express Editions are not supported).

Es decir, si quieres instalar la SDK cómprate el Visual Studio (las ediciones Express que dice que no son soportadas son las versiones gratuitas de Visual C# o VB.NET). Es un poco sorprendente que Microsoft no proporcione ninguna forma gratuita de que un aficionado realice desarrollos para Windows Mobile (salvo que piensen que con la cantidad de versiones pirata de Visual Studio que circulan por ahí esta restricción no es relevante).

Una vez todo instalado tenemos lo necesario para realizar aplicaciones para WM6. Se pueden desarrollar dos tipos de aplicaciones para Windows Mobile: con código nativo o con código administrado (managed code). Llamamos código nativo al código C++ que utiliza directamente la API de Windows Mobile, y código administrado al que utiliza las clases del .NET Compact Framework con C# o VB.Net. (Windows Mobile es la única plataforma móvil importante que no soporta J2ME; hablaremos de J2ME en un futuro artículo).
¿Las diferencias entre ambas? El código nativo es más rápido y ocupa menos, además de proporcionar acceso a algunas características del hardware que son inaccesibles desde el Compact Framework. Sin embargo, en la mayor parte de los casos desarrollar código administrado es la mejor opción. El tamaño del ejecutable es cada vez menos importante, y si la velocidad es un factor crítico siempre se puede optar por programar en código nativo las partes de la aplicación que supongan un cuello de botella. Por lo demás, el desarrollo en .NET resulta mucho más fácil y cómodo (al menos para los que no son especialistas en C++ y la API de Windows).

Como resumen, podemos decir que el desarrollo de aplicaciones para Windows Mobile presenta como inconvenientes la falta de alternativas al Visual Studio y el consiguiente desembolso económico necesario para adquirir una licencia. Por otra parte, el lado positivo se encuentra tanto en la calidad de las herramientas disponibles (el propio Visual Studio, los emuladores, la SDK y su documentación…) como en la activa comunidad de desarrolladores existente y agrupada en torno al portal de desarrollo de Microsoft, la MSDN.

Entradas relacionadas:

Introducción al desarrollo de aplicaciones para teléfonos móviles: Symbian
Introducción al desarrollo de aplicaciones para teléfonos móviles: J2ME (I)
Introducción al desarrollo de aplicaciones para teléfonos móviles: J2ME (y II)
Introducción al desarrollo de aplicaciones para teléfonos móviles: BlackBerry

La nota de prensa de Steve Jobs sobre la SDK del iPhone decía textualmente:

“Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. While this makes such a phone less than “totally open,” we believe it is a step in the right direction.”

Que traducido viene a decir:

“Nokia, por ejemplo, no permite que se cargue ninguna aplicación en algunos de sus teléfonos más recientes salvo que tengan una firma digital que se pueda rastrear hasta un desarrollador conocido. Aunque esto convierte a un teléfono así en algo menos que ‘totalmente abierto’, creemos que es un paso en la dirección correcta”.

¿Cómo funciona exactamente esta restricción de Nokia?

Todo parte de una iniciativa de Symbian (por lo tanto no sólo de Nokia) llamada Symbian Signed. A partir de la versión 9 de Symbian OS se introduce este mecanismo que permite obligar a que una aplicación esté digitalmente firmada antes de instalarla. Para firmar una aplicación necesitamos:

- Un Publisher ID proporcionado (por un precio) por algún distribuidor autorizado (Verisign, Trust Center…) y que utilizaremos para firmar las aplicaciones.

- Enviar la aplicación a una Test House que, también por un precio, verificará que la aplicación cumple con los criterios de Symbian Signed.

- Para aplicaciones gratuitas Symbian proporciona la opción de firmar la aplicación con un Publisher independiente, que también se encargaría de comprobar que pasa todos los criterios de Symbian Signed.

¿Es necesario firmar cualquier aplicación?

Symbian Signed no es obligatorio en versiones de Symbian anteriores a v9.x (aunque puede utilizarse en ellas), ni se utiliza en aplicaciones J2ME (Sun tiene su propio mecanismo de firma).

Para aplicaciones C++ (o AppForge MobileVB) destinadas a S60 3rd Edtion o UIQ 3.x es necesario examinar qué APIs vamos a usar para ver cómo necesitamos firmar el ejecutable.

Symbian Signed divide parte de las APIs de Symbian en grupos llamados Capacidades (Capabilities) en base a su funcionalidad y al riesgo que conlleva su uso. Aproximadamente el 60% de Symbian queda fuera de estos grupos y es de libre acceso. Symbian Signed no obliga a firmar una aplicación que sólo haga uso de la parte no restringida de las APIs. Sin embargo, la implementación final de cada móvil puede hacerlo. En la práctica, los móviles UIQ 3.x aceptan instalaciones sin firma, pero los S60 3rd Ed. obligan a que el ejecutable tenga al menos un tipo de firma llamada autofirmado (selfsigned), aunque para esta firma sólo es necesario usar una aplicación disponible en la SDK, no necesitamos Publisher ID ni realizar ningún pago.

Las Capabilities de las que hablábamos son 20. Podemos ver aquí que funciones incluyen cada una, y en la última página de este pdf vemos cómo se distribuyen. Siete de ellas sólo las podremos usar si pedimos una licencia específica al fabricante o a Symbian; de las otras trece, algunas las podremos utilizar con el selfsigned, mientras que otras requerirán que la aplicación esté Symbian Signed (utiliando por tanto el Publisher ID). Para saber a qué atenerse lo mejor es consultar la documentación de la SDK que estemos usando.

Existe un certificado especial para desarrolladores que se puede solicitar para el proceso de desarrllo; es gratuito si sólo queremos hacer pruebas con las 13 capabilities menos restringidas y en un solo móvil (la firma se asocia al IMEI), y tiene un coste si necesitamos usar más IMEIs o las siete Capabilities más restringidas. Este pdf muestra cómo funciona este tipo de firma.

Precisamente ayer mismo Symbian anunciaba algunos cambios sobre los tipos de certificados de Symbian Signed, que afectan fundamentalmente al número de IMEIs utilizables y al precio.

Más información:

Faq de Symbian Signed
Faq en Symbian
Foro de desarrolladores sobre Symbian Signed

[Update 19/10/2007: añadida la referencia a la firma de aplicaciones gratuitas]