+34.net - El blog de las tecnologías móviles

Hace un par de semanas escribía sobre la nueva especificación Java MSA para móviles, y a raiz de la entrada que publiqué, recibimos algunos comentarios muy interesantes de David Contreras, que es un profesional que se dedica al desarrollo de aplicaciones para el entorno móvil. Me parecieron tan interesantes sus comentarios que no quería dejar pasar la oportunidad de compartirlos con todos vosotros (con su autorización, por supuesto). Os recomiendo que lo leáis entero.

“Tanto MSA como (previsiblemente) MIDP 3.0 siguen el mismo modelo de comportamiento que llevamos viendo desde 1999: Sale MIDP 1.0, que no es sino un conjunto de JSRs que cualquier móvil debe entender para poder llamarse “compatible” con el estándar o especificación MIDP 1.0, vale, perfecto.

Sun sigue trabajando tras este hito, y desarrolla nuevos JSrs, como el JSR 82 (Bluetooth). Perfecto, entonces un fabricante se decide a implementarlo en sus terminales (o más correctamente implementa versiones de la maquina virtual de Java más modernas, que recnocen ese nuevo API). Problema: Fragmentación de mercado: Ahora un desarrollador tiene que decidir para qué grupo de terminales desarrolla su aplicación: MIDP 1.0 a “secas” o MIDP 1.0 + JSR 82.

La solución normalmente si quieres hacer aplicaciones para “la masa” pasa por quedarte con el mínimo común múltiplo de características que cumplen todos los terminales, lo cual se traduce en aplicaciones bastante pobres: mal asunto.

Pasan los años, y se van desarrollando continuamente nuevos JSR, que algunos fabricantes implementan y otros no, hasta que el mercado está tan fragmentado que esto es una locura.

Solución: Establecemos un nuevo “Punto de partida” o “Puesta a cero” o “Borron y cuenta nueva” llamado MIDP 2.0, que no es sino aglutinar todas las JSR incluidas en MIDP 1.0 con un lavado de cara, Y las nuevas JSR que han ido saliendo desde entonces.

Fantástico, ahora si quieres puedes “descartar” todo lo anterior a MIDP 2.0 y programar con cero fragmentación…hasta que a los chicos de Sun les de por sacar una nueva JSR, por ejemplo la que permite generar gráficos vectoriales….bufff….

Y así hasta el infinito. El problema de MSA y MIDP 3.0 es que siguen este mismo modelo, con lo que la fragmentación, que es el principal problema de todo desarrollador, no se elimina.

La única solución a todo esto es una propuesta que puede leerse en www.j2me.org sobre carga dinámica de APIs en la máquina virtual. ¿Esto que es lo que es?

Imaginemos que tenemos un flamante móvil MIDP 3.0 “a secas” y nos pasan una aplicación MIDP 3.0 que además hace uso de un API que nuestra máquina virtual no reconoce: no hay problema, nuestro teléfono en ese momento conecta a internet, y actualiza la máquina virtual para que pueda reconocer esa nueva aplicación. ¡Fantástico! nos acabamos de pulir en un segurndo el 60% del coste de cualquier proyecto Java ME, y el 80% de los quebraderos de cabeza de cualquier programador que se mueva en este mundillo. Además de poder hacer “de base” siempre las mejores aplicaciones, con todos los extras que queramos, sin tener que limitarnos a ese “minimo comun multiplo” de características a las que hacía referencia.

Problema: Muchas JSR son dependientes del hardware, por lo que siempre habrá cierta fragmentación (imaginemos un API de gestión del GPS de nuestro móvil) pero desde luego esto siempre supondrá un problema mucho menor de lo que la fragmetación de software supone ahora.”

Gracias David por tu aportación a nuestro blog.