¡¡Bienvenidos a Ipoki!!

Habitualmente se considera la instrucción instanceof como una forma muy poco óptima de comprobar si una clase pertenece un objeto. Sin embargo, en el portal de BlackBerry aconsejan utilizar instanceof en vez de esperar a capturar una ClassCastException (lo cual es lógico, ya que la excepción debería ser siempre más costosa), debido a ciertas optimizaciones que se realizan cuando se hace el cast justo después de la comprobación:

if(x instanceof String) {
(String)x.whatever();
} else {
// something else
}

Estas optimizaciones deberían evitarnos tener que buscar métodos alternativos, como llamadas a métodos virtuales. Son optimizaciones comunes en las JVM de J2SE, pero que no sé si se da en otras implementaciones de J2ME.

Programación orientada a objetos

Sin entrar en debates académicos sobre las ventajas e inconvenientes de la programación orientada a objetos, hay que ser consciente de que algunas de las técnicas de este paradigma son especialmente costosas para la máquina. Aunque programemos en Java, que es un lenguaje de clases y objetos, es conveniente ponerse a pensar de una forma más estructurada, buscando ahorrar recursos a costa de incurrir en algunas cosas que nos enseñaron a evitar cuando aprendimos POO. En concreto:

- Conviene minimizar el número de clases. Ya no se trata de tener una clase para cada entidad que hayamos detectado en el análisis. Sólo queremos las clases indispensables para dar un poco de sentido al código, aunque los métodos que contengan no guarden mucha relación entre sí. Este es el punto más controvertido, ya que podemos limitarnos a meter todo el código en una clase. Sin embargo no se trata de renunciar por completo al mecanismo de clases, tan solo de ser consciente de que estas tienen un coste importante.

- Como norma general, nada de getters y setters. La encapsulación está bien para los PCs, no para los disposivitos móviles. Unas variables miembro con ámbito protected o public funcionarán mejor. El principal motivo para usar getters y setter es proporcionar una interfaz pública estable que nos permita cambiar la implementación interna en el futuro. Salvo que queramos diseñar una librería pública o trabajemos en un proyecto realmente muy grande, no los necesitamos.

- Nada de crear interfaces. Están muy bien para llevar a cabo una librería extensible, pero como en el punto anterior, es muy probable que no las necesitemos. Y en cuanto a su uso, cuantos menos interfaces implemente nuestra aplicación, mejor. El ejemplo típico es la interfaz CommandListener: en vez de implementarla en cada pantalla, es más efectivo implementarla en una sola clase controladora.

- Nada de clases abstractas. Ver punto anterior.

Lógicamente ninguna de estas recomendaciones se puede tomar como dogma, pero son útiles para recordar que nuestra mentalidad de programador debe cambiar cuando nos enfrentemos a dispositivos móviles.

Entradas relacionadas:
Consejos para programadores J2ME (y BlackBerry) – 1
Consejos para programadores J2ME (y BlackBerry) – 2

Tanto Netbeans como EclipseME soportan directivas de preprocesado, que resultan extremadamente útiles para proyectos dirigidos a más de una plataforma, de forma que no nos volvamos locos con esos pequeños cambios que hacen que nuestro código funcione en una plataforma concreta. Instrucciones del estilo

//#ifdef PLATAFORMA1
// Código específico de la Plataforma1
//#endif

nos ayudan a organizar nuestro código. Este artículo incide sobre este asunto.

Optimización de divisiones

La idea es: cada vez que quieras dividir por un múltiplo de dos, haz un desplazamiento a la derecha.

int i = j / 4; // lento
int i = j >> 2; // rápido

Para enteros positivos, lo único que hay que tener en cuenta es que esta división nos redondea hacia abajo (ya que perdemos los bits de la derecha). Entiendo que detrás de esta optimización existen dos circunstancias: algunos procesadores no incluyen hardware específico para divisiones, y en cualquier caso a la máquina virtual de java le resulta más simple desplazar que dividir.

Gestión de memoria (Garbage collection)

Este es un asunto espinoso. Veamos algunos hechos sobre J2ME y el recolector de basura:

- No existe ninguna obligación por parte de la JVM de liberar recursos tras una llamada a System.gc(). La máquina virtual puede ignorarnos o esperar a una liberación que tuviese planeada. Incluso es posible que la máquina virtual no tenga Garbage Collector.

- Habitualmente el Garbage Collector se ejecuta en su propio thread, lo que ralentizará la ejecución de nuestra aplicación en el momento más inesperado.

- La única condición que existe para que un objeto sea elegible por el Garbage Collector, y por tanto el único control que tenemos sobre el mismo, es que no exista ningún thread vivo que pueda tener acceso al objeto; es decir, o bien todos los threads que tienen referencias al objeto han finalizado, o bien han establecido sus referencias a null.

Conclusión: lo importante en la gestión de memoria no es llamar a System.gc() continuamente, sino reducir al mínimo las referencias que tenemos de cada objeto y asegurarnos de ponerlas a null o finalizar el thread tan pronto como sea posible.

Más información: J2ME Wiki – Memory Management

Entradas relacionadas:
Consejos para programadores J2ME (y BlackBerry) – 1

- Como mencionábamos en una entrada anterior, Symbian Signed ya está disponible.

- Una página curiosa que permite probar versiones flash de distintos dispositivos móviles.

- Después de Android, una nueva especificación para una plataforma móvil Linux, de parte del Linux Phone Standards (LiPS) Forum. Una comparación entre LiPS y Android (por parte de LiPS), aquí [pdf].

- Y hablando de Android, ya tenemos comunidad de desarrolladores. Se llama Go to Android, y está en inglés pero montada por dos españoles. Vía Xataka Móvil.

- Desde Nokia Labs nos presentan Nokia PC Phone, aplicación desde la que podremos hablar, enviar SMSs y gestionar los contactos de nuestro móvil. Es decir, necesitas el móvil para hacerlo, pero al menos puedes utilizar el teclado del pc y unos altavoces y micrófono que te gusten más.

- Y finalmente, Simon Judge nos avanza algunas novedades de Carbide.C++ 1.3, que se encuentra en estado de beta privada.

Bucles eficientes

El desarrollo para dispositivos móviles viene marcado por la preocupación extrema (extrema para un programador acostumbrado a PCs y Macs) por el ahorro de recursos. Pese a que ahorrar recursos nunca es malo, en otras plataformas existen factores que suelen tener más peso, como la claridad o economía del código; en los dispositivos móviles estos factores siempre van detrás del consumo de recursos. Un ejemplo:

for(int i = 0; i < vector.size(); i++) {
...
}

Este código nos permite ver en una sola línea que vamos a iterar sobre todos los elementos del objeto vector. Sin embargo no es óptimo en términos de rendimiento:

int vectorSize = vector.size();
for(int i = 0; i < vectorSize; i++) {
...
}

Invocar un método de un objeto en cada iteración del bucle para obtener siempre el mismo resultado es ineficiente, pero con una simple línea más de código nos ahorramos un montón de instrucciones de procesador. De hecho, dado el poco esfuerzo que requiere yo diría que es también una buena práctica para otras plataformas menos limitadas.

En el caso de no importar el orden de iteración, una optimización adicional se consigue con:

for(int i = vector.size() - 1; i == 0; i--) {
...
}

Como la asignación inicial sólo se realiza una vez nos ahorramos una variable local en la pila; y además la comparación se realiza con el valor 0, que es la comparación que más rápidamente se realiza.

En el artículo de la web de BlackBerry que mencioné al principio se sugiere como optimización el cambio del post-incremento de i (i++) por un pre-incremento (++i) por ser este último más rápido. Yo dudo de que esto sea cierto en este caso. El asunto es un tanto complejo, pero no he encontrado ningún razonamiento que sustente esa afirmación, y he encontrado este artículo: Eye on performance: Micro performance benchmarking que parece respaldar lo contrario. Quizás el origen de esta creencia está en C++, donde debido a la forma en la que se sobrecarga el operador ++, el pre-incremento y el post-incremento aplicados a objetos sí presenta diferentes rendimientos.

Entradas relacionadas:
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

En las dos hojas que componen el documento se habla de:

• wwigo, una aplicación para usar un móvil como webcam, se muestran los nuevos teléfonos Nokia de Octubre y Noviembre
• de una predicción sobre el aumento de la cobertura 3G en China de aquí al 2011
• de los resultados de Symbian en el tercer cuatrimestre del 2007
• de las fortalezas (9) y debilidades (14) de Linux como sistema operativo móvil (me encantan estos análisis pretendidamente objetivos sobre la competencia)
• del nuevo servicio OVI de Nokia
• de los canales de venta de teléfonos móviles Symbian en Europa
• o de por qué las previsiones de mercado de Windows Mobile en India no son tan brillantes como Microsoft pretende

Por diversidad de contenidos no va a ser…

Centrándonos en los resultados del tercer cuatrimestre para Symbian, el folleto nos da algunos datos esquemáticos:

Es decir, cada vez (es una comparativa con el tercer cuatrimestre del 2006) venden más smartphones, y cada vez tienen más modelos y más aplicaciones comerciales disponibles. También tienen nuevas tecnologías anunciadas.

Más interesante es la gráfica que nos muestra la evolución en el número de dispositivos (smartphones) vendidos por sistema operativo desde el primer trimestre del 2005:

Vemos en la gráfica que el principal competidor de Symbian es Linux. Para los que se sorprendan de que Linux tenga una presencia tan fuerte en este sector, aquí tiene una lista con dispositivos móviles que llevan sistema operativo Linux (las lista es de finales del 2006, así que no incluye los dispositivos más modernos). El problema de Linux es que, así como es fácil saber qué smartphones llevan Symbian, Windows Mobile o RIM, los fabricantes que usan Linux en sus dispositivos no hacen mucha gala de ello. O quizás sí, pero donde realmente los venden, que es en China y Japón, como veremos más adelante.

Vemos también que los siguientes competidores, los dispositivos Windows Mobile y las BlackBerry, tiene un pequeño porcentaje del pastel, y se aprecia la brusca irrupción del iPhone en los últimos dos cuatrimestres, pese a estar disponible sólo en Estados Unidos. Podemos apreciar mejor el impacto del iPhone en la siguiente gráfica:

EMEA significa Europa, Oriente Medio y África, y ROW significa resto del mundo (Rest Of World). Como podemos ver, el mercado norteamericano es totalmente distinto a cualquier otro. Es el único sitio donde Symbian no sólo no es mayoritario, sino que es casi irrelevante. Además, podemos observar como el líder, RIM, está a punto de dejar de serlo a manos del MacOS del iPhone, que aparentemente ya ha relegado a Microsoft al tercer puesto. El color azul celeste (Access) corresponde a los dispositivos PalmOS.

Los otros dos datos que yo destacaría de esa gráfica: el dominio absoluto de Symbian fuera de Asia (donde aún así es el sistema mayoritario) y Norteamérica, y la abundante cuota de mercado de Linux en China y Japón, que contrasta con su presencia anecdótica en Europa y Estados Unidos.

Como siempre, esta información hay que considerarla con un punto de escepticismo, ya que está divulgada por una de las partes interesadas (que cita como fuente a la empresa Canalys), y aunque eso no quiere decir que sea falsa sí nos hace sospechar que pueda ser parcial.

En cuanto a Sun, presenta la versión 2.5.2 del Sun Java Wireless Toolkit, que incorpora suporte mejorado para entornos multiusuario y una nueva release para Linux usando las librerías glibc 2.3.

Vía:

Jacek Wojciechowski’s Forum Nokia Blog: Good news for Java ME developers… NetBeans Mobility 6.0, WTK 2.5.2

Una vez finalizado, el wiki se abrirá para que todo el mundo pueda ayudar añadiendo material y corrigiendo errores.

Vía:
Mobile Phone Development: UIQ 3: The Complete Guide

Sobre las formas que tiene Google de averiguar la localización del móvil, un ingeniero de Vodafone UK apunta que en el Reino Unido es la propia Vodafone quien proporciona a Google la información sobre la celda en la que se encuentra el usuario, así como una distancia aproximada y una orientación con respecto a la celda. La ventaja que poseen las operadoras es que saben no sólo en qué celda se encuentra el móvil, sino qué otras celdas están cerca, y en el caso de las antenas direccionales conocen la dirección aproximada respecto a la antena (esta información se indica esquemáticamente en un foro de yahoo que exige registro).

Así, para los teléfonos Vodafone UK se utilizaría una versión de Google Maps Mobile que enviaría la información necesaria para identificar en qué red funciona y localizar al dispositivo dentro de esa red (quizás todas las versiones de GMM lo hagan y sólo se aproveche cuando se pueda), y se enviaría esa información a Google para que la convirtiese en una ubicación en el mapa.

Decía también que Google tenía una base de datos con ubicaciones de las celdas de telefonía móvil propia con datos conseguidos de distintas fuentes. Lo que no sabía es que esa información es pública en algunos países. Podemos consultar algunos de ellos (no España, ni ningún país hispanohablante) en el Mobile Manufacterers Forum.

Vía:
Mobile Phone Development: Google MyLocation: How Does it Work?

Adobe Flash Lite 3 Developer Edition sólo está certificado para el Nokia N95, por lo que Adobe no garantiza su funcionamiento en otros dispositivos S60 3rd Ed., pero es de suponer que cuenta con que los desarrolladores vayan probando los distintos dispositivos y proporcionando información sobre su funcionamiento. El producto final irá integrado de serie con diversos modelos que aparecerán a lo largo del 2008.

Adobe Flash Lite 3.0 está basado en Macromedia Flash Player 7.0, con soporte parcial de algunas características y soporte adicional de características específicas para móviles. Para programar se utiliza una versión de ActionScript llamada (previsiblemente) Flash Lite 3.0 ActionScript. Se puede encontrar información técnica en inglés en la página de recursos de Flash Lite de Adobe.

En la actualidad el soporte para las versiones 1.x y 2.x de Flash Lite es irregular, siendo muy habitual en Japón y bastante menos habitual en Europa. Se puede consultar una lista de dispositivos compatibles y operadores que lo proporcionan aquí: Flash-Enabled Mobile Devices.

Flash es una de las opciones para desarrollar software para móviles sin tener que preocuparse de los miles de dispositivos distintos existentes en el mercado. Es una idea similar a Java ME, aunque en al estar su versión para ordenadores de sobremesa tan asociada a la web es fácil pensar en Flash sólo como un plugin para navegadores. Veremos si Adobe consigue aumentar el número de dispositivos con Flash Lite preinstalado a la vez que evitar los problemas de incompatibilidad habituales en Java ME.

Vía:
Alessandro Pace’s Forum Nokia Blog: Flash Lite 3 Developer Edition is now available for download from Adobe Labs