The long tomorrow

Antes de nada: ¡hola de nuevo! Ha sido un parón largo y ligeramente dramático. Pero parece ser que vuelvo al tajo bloggero más pronto que tarde.

Llevo unas semanas trabajando en Java. Y en python. Y en PHP. Y levantando egroupware. Es obvio que ha sido una temporada movidita.

Pero me desvío, como siempre, del tema: teléfono móvil y libertad. Cada día los teléfonos son más multitarea: MP3, MP4, juegos, 3D, TV, Bluetooth, WAP, compras a través del teléfono, monedero, MMS, … ¡y también se puede hablar y enviar mensajitos de texto! Parece claro que todo este desarrollo no lo lleva a cabo únicamente el constructor del teléfono (Sony, Nokia, Motorola, …) parte ha de ser trabajo de terceros; desde el operador (Telefónica, Vodafone, Orange,…) hasta compañías mucho más pequeñas que desarrollarán software para modelos específicos ó para entornos operativos específicos.

En este momento cada operador dispone de su propio sistema operativo embebido y embarcado en cada teléfono. Cada modelo de terminal tiene sus propias características, hardware y procesador. Incluso en la misma familia de teléfonos existen diferencias. Esto nos lleva a la siguiente cuestión, ¿es económico/posible publicar software[1] independiente para un teléfono? Ahí el terreno se vuelve muy pantanoso.

En principio muchos de los fabricantes tratan de implementar una versión de la máquina virtual compatible con los estándares de Sun. De esta manera, un desarrollador independiente podría desarrollar soft en Java-móviles y luego publicarlo para descargas, ¿no? Pues sí, estamos de enhorabuena, porque efectivamente se puede desarrollar para teléfonos móviles. Sin embargo, si creíamos que se puede programar sin pasar por el aro, vamos daos.

En mi corta experiencia en móviles, estoy desarrollando un código que necesita tener acceso a Bluetooth y a cámara. El problema viene a la hora de acceder estos dos dispositivos. El modelo de seguridad que propone Sun entiende que es inseguro permitir que una aplicación Java conecte la cámara (o el Bluetooth, o se conecte a la web, o acceda a la agenda, … [2]) A causa de esto el usuario recibe dos inquietantes mensajes:

1. La aplicación no es segura desea instalarla –> esto turba mucho al usuario.
2. (cada vez que se quiere acceder a la cámara) Esta aplicación quiere abrir la cámara ¿qué te parece eso? –> esto incomoda mucho al usuario.

Como mínimo es incómodo para el usuario, ¿si? La única solución es firmar el instalador y eso significa contactar con Verisign o con Twateeeee o con quién tú quieras y pagar [3]. Como bien sabéis, Hasefroch lleva incorporando firmas a sus .exe desde hace algunos años. Así que te pones manos a la obra, primero la documentación, luego la blogosfera, luego la articulo-sfera, luego, … te encomiendas a los ángeles. Pero el teléfono sigue dándote el clásico: firma chunga, ¡pírate! Es descorazonador, es pesado, es frustrante.

Sin embargo continúas bregando y finalmente llegas a firmar un MIDlet válido. Casi parece cosa de magia, estás tocando el cielo con los dedos. Afortunadamente llega Sony-Ericsson para dar por el culo, ¿es que eres tú más listo que Sony que sabe lo que nos conviene?, lo dudo chico! Casi literalmente, thread tras thread de su foro de soporte a desarrolladores, Sony insiste: si quereis certificados válidos tendréis que pagar. ¡¡ WTF !! ¿soy un pequeño desarrollador y tengo que retratarme sólo para programar? ¡¡pero qué cojones!!

Este tipo de políticas me molestan, me ofenden, me hacen enfadar y permanecer fiel a mi viejo (pero minúsculo) teléfono ¿Para qué voy a actualizar mi máquina si no me dejan hacer nada con ella? En este punto no me queda mucho más que decir que ¡viva el IRC! ¡viva Jabber! y vivan las albóndigas de mi abuela! Pero que le den por saco a todo aquel que quiera levantar monopolios (sean portátiles o no)
–
[1] Entiéndase software como “software serio”, claro
[2] Es decir, las restricciones son, en muchos casos, razonables.
[3] Y a mi no me gusta pagar sólo por desarrollar, puestos a pagar, las ponemos sólo cuando toque.