¿Qué pasará con JavaME?

Hace mucho tiempo alguien me dijo que JavaME estaba muerto. En aquel momento, escuché, callé y pensé pues yo solo había hecho alguna aplicancioncilla de juguete en J2ME y no tenía un criterio formado sobre el tema.

Unos meses más tarde, recibí en el trabajo (o más bien, autoasumí) el encargo de hacer un prototipo de una aplicación móvil. Sería mi primera aplicación móvil "de verdad" y, como mi background sobre el tema estaba relacionado con JavaME, a pesar de lo que me habían dicho comencé el prototipado con J2ME.

La aplicación parecía en principio sencilla, con pocos elementos gráficos y comunicaciones mediante SMS. Todo iba bien, hasta que llegó el momento de hacer algunas pruebas muy simples y me encontré con el primer y gran problema: JavaME no permitía interceptar los SMS entrantes de la bandeja de entrada.

- ¿Que no puede? ¿Quién dijo eso? ¡JavaME sí puede interceptar SMS entrantes!

Es verdad, sí que puede; pero insisto: no puede interceptar los SMS entrantes de la bandeja de entrada, y eso es un gan problema pues la aplicación solo podría interceptar los SMS enviados a un "puerto" determinado por alguna aplicación que supiera a qué "puerto" enviar el SMS y esto descartaba J2ME pues la aplicación debía ser capaz de reaccionar a cualquier SMS, independientemente de quién, qué o por qué vía, lo había enviado.

(Esto de los "puertos" SMS es un tema polémico pues los desarrolladores de .NET, por poner un caso, cuando ven el término por primera vez, piensan que se trata de un error pues no existe nada parecido en Windows Mobile; pero así es en JavaME y si a alguien le suena raro, puede profundizar en los foros de Nokia, donde el tema de interceptar SMS con J2ME es un tópico recurrente.)

De modo que, debido al problema con la intercepción de SMS entrantes tuve que descartar JavaME para esta aplicación, desarrollándola entonces en Windows Mobile y migrándola recientemente a Android; cuyo proceso de migración -dicho sea de paso- dio pié al post anterior Aplicación en modo kiosko para Android.

Después de aquella experiencia se asumió el .NET Compact Framework como base para los desarrollos móviles hasta que ocurrió lo que ocurrió con Windows Mobile y comenzamos a desarrollar para Android, convirtiéndose así en nuestra plataforma de elección... hasta que volvieron a pedirme algo cuyo primer candidato era JavaME: una aplicación para el Nokia C5-00.
 
La aplicación también sería muy simple, con pocos elementos gráficos, y solo requería acceder a la información de posicionamiento del GPS y enviar SMS. Hasta aquí todo bien. Sin embargo, poco tiempo después de comenzar a trabajar en el diseño, llegó un requisito nuevo: la apliacación debía reaccionar ante determinados tipos de SMS... y hasta aquí llegó JavaME.


Evalué entonces Symbian WRT y PyS60, dejando a Qt como última opción. Lo de Python en el S60 no fue tan divertido ni bueno como esperaba, por lo que el desarrollo lo hice finalmente con el WRT que si bien satisfacía los requisitos del prototipo, no sería suficiente para el resto de requisitos del producto completo; así que, luego de una charla con parte de los implicados y consultarlo con expertos nos corroboraron lo que se venía venir: la solución debía asumirse con Qt.

De modo que, otra vez, JavaME tuvo que ceder ante otras tecnologías de desarrollo para móviles.

Toda esta historia (que ya se va haciendo larga) es para aclarar que, a pesar de mi intensión de usar JavaME he tenido que dejarlo de lado en más de un proyecto; por lo que, luego de la adquisición de Sun, por parte de Oracle, me he hecho la pregunta más de una vez: ¿Que pasará con JavaME?

El asunto es que si no fuera por Nokia y RIM que han basado una parte importante de sus productos en J2ME, probablemente aquella persona que me dijo que JavaME estaba muerto habría tenido razón. Ahora sé que no tenía razón... del todo: JavaME sigue siendo la plataforma de desarrollo más extendida para dispositivos móviles; pero está claro que cada vez pierde más terreno en los teléfonos móviles. Las dos grandes dominantes del mercado de smartphones -Android e iOS- no usan J2ME y, para colmo, dos de sus mejores aliados le están retirando parte de su apollo: Nokia ha orientado todos sus esfuerzos hacia Windows Phone 7 (.NET) y RIM ha comenzado a dar soporte para que puedan ejecutarse aplicaciones de Android en sus tablets.

Entonces... ¿Qué hará Oracle ahora? ¿Le dará el empujón que necesita JavaME para recuperar el terreno perdido?

El viernes que viene estaré en la charla Java ME Platform Evolution que impartirá en Madrid Renu Motwani, la Product Manager de JavaME en Oracle; así que espero que ahí pueda esclarecer mis dudas. Hasta entonces, sigo esperando con la ilusión de que Oracle despierte y vuelva a darnos el placer de escribir una vez y ejecutar en cualquier parte.

Aplicación en modo kiosko para Android

Hace un tiempo tuve que migrar una aplicación de Windows Mobile a Android. En sentido general el desarrollo en Android fue más simple y más rápido; pero cuando llegué al punto de duplicar el comportamiento del "modo kiosko", Android se tornó casi tan arisco como Windows Mobile. Aquí publico hoy la solución que apliqué para que sirva de base a otros desarrollos.

No es que hacer una aplicación que se ejecute en modo kiosko en Windows Mobile sea simple. De hecho lograr que la aplicación se mantuviera siempre en primer plano bloqueando los botones de hardware del teléfono fue toda una odisea que necesitó alguna chapucilla código particularizado para cubrir limitaciones (como que en los teléfonos Samsung se nos estaba vetado deshabilitar el botón de la cámara -según nos confirmaron desde Samsung- y, por tanto, cada vez que se pulsaba el botón de la cámara la aplicación perdía el foco).

Los teléfonos con Android, por suerte, tienen unas APIs más uniformes, pero no por esto el modo kiosko deja de ser un reto. Para comenzar, no encontré ningún lugar donde pusieran en claro qué hacer para que una interfaz se mantuviera en primer plano y a pantalla completa, independientemente de la interacción que tuviera el usuario con el dispositivo. Debido a que la información que encontré era incompleta y estaba dispersa, hoy pongo aquí el resumen de lo necesario para crear una aplicación que se ejecute en modo kiosko, acompañado del código fuente de un proyecto sobre el que se puede partir para hacer una aplicación que ya satisface estos requisitos.

Para comenzar, una aplicación en modo kiosko en Android debe:

1. Mostrarse a pantalla completa, de modo que el usuario no se salga de la aplicación accediendo a otras opciones que aparezcan en la zona de notificaciones, en la barra de título.
2. Bloquear los soft buttons y botones de hardware, de modo que el usuario no pueda salirse de la aplicacion presionando el botón back ni se interrumpa la aplicación por la presión de otros botones como el control del volumen.
3. Remplazar el home del dispositivo por la pantalla inicial de la aplicación, de modo que, al presionar el botón "home" (que lamentablemente no puede ser interceptado, como el resto de botones) en lugar de salir de la aplicación para mostrar la pantalla de inicio del teléfono, se muestre la aplicación y se pueda restablecer la interfaz al punto donde se estaba.

Debo puntualizar que esta solución no es La Solución para todas las aplicaciones que requieran ejecutarse en modo kiosko pues cada una puede requerir un mayor o menor grado de control. Sin embargo, la esencia de dicho control puede obtenerse haciendo que las actividades de nuestra aplicación extiendan la clase KioskModeActivity cuyo código es el siguiente:

package org.carlosbello.android.kioskmode;

import android.app.Activity;
import android.os.Bundle;
import android.view.KeyEvent;
import android.view.Window;
import android.view.WindowManager;

/**
 * Actividad de base para crear interfaces en modo kiosko.
 * @author Carlos Bello
 */
public class KioskModeActivity extends Activity {
    /** Indica si deberá desactivarse el uso del botón de retroceso. */
    protected boolean blockBackButton = false;
    
    /**
     * Establece la visualización a pantalla completa para evitar una salida 
     * accidental a través de la barra de título o cualquier otro elemento 
     * interactivo que no sea nuestra propia interfaz.
     */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        requestWindowFeature(Window.FEATURE_NO_TITLE);
        getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
                WindowManager.LayoutParams.FLAG_FULLSCREEN);
    }
    
    /**
     * Intercepta los eventos del teclado para evitar la interacción con 
     * cualquier elemento que no forme parte de nuestra interfaz, salvo la 
     * funcionalidad del botón de retroceso, si estuviera habilitado.
     */    
    @Override
    public boolean onKeyDown(int keyCode, KeyEvent event)  {
        return !blockBackButton && keyCode == KeyEvent.KEYCODE_BACK
            ? super.onKeyDown(keyCode, event)
            : true;
    }
}

Ahora, para evitar salirse de la aplicación, la actividad inicial deberá establecer blockBackButton a true y registrarse en el manifiesto del proyecto con la categoría HOME; de modo que si reiniciamos el terminal se abrirá nuestra aplicación primero que cualquier otra y al pulsar el botón home se mostrará siempre nuestra aplicación.

Claro que convertir nuestra aplicación en el home del sistema trae como consecuencia que si queremos salir de la aplicación, terminaremos entrando en ella nuevamente pues el home del sistema es nuestra propia aplicación. De hecho, ese es parte del objetivo: que si nos salimos por accidente de la aplicación, ésta se abra automáticamente. Este "inconveniente" puede sortearse buscando otra aplicación que pueda funcionar como home y abriéndola explícitamente.

Como el código para hacer esta búsqueda es algo más extenso, dejo en el siguiente enlace un proyecto de ejemplo de una aplicación que puede ejecutarse en en modo kiosko:
http://ejectodemo.googlecode.com/files/20120227_AndroidKioskMode.zip

Update: desde agosto de 2014 el código está disponible en GitHub:
https://github.com/carlosbello/efectodemo/tree/master/AndroidKioskMode

Atención: Debe tenerse en cuenta que si durante la ejecución de la aplicación se presiona el botón home y se marca la casilla de "Usar por defecto" se reescribirá la pantalla home del sistema y se necesitará eliminar los valores por defecto, almacenados para la aplicación AndroidKioskMode o desinstalarla para restablecer el home original.

Bueno, esto es todo. Agradeceré cualquier colaboración que mejore esta solución o plantee una solución diferente.

Mis primeras experiencias con Kanban: lecciones aprendidas

Hace varios meses comencé a usar Kanban en un proyecto doméstico. Contento con los resultados, decidí intentarlo en la oficina para experimentar en un entorno mas complejo. La cara de duda de algunos que me observaban cortar y garabatear un cartón para prepararlo como pizarra no se hizo esperar... y las dificultades para aplicar Kanban, tampoco.

El principio: motivado por la desmotivación

Trabajar en solitario tiene sus pros y sus contras. Las ventajas seguro que podrían ser enumeradas y disfrutadas por cualquiera pero... ¿cómo aminorar los inconvenientes si no tienes a tu lado a nadie que pueda ayudarte?

En la primavera del 2010 comencé a trabajar en un pequeño proyecto -en mi casa- que se suponía debía terminar en un par de meses; pero por gestionar mal el proyecto y permitir que los requisitos del sistema aumentaran descontroladamente el verano terminó y el proyecto no hacía más que crecer. Llegó el otoño y con la caída de las hojas se me cayeron a mí las ganas de trabajar en el desarrollo: los incentivos iniciales parecían escabullirse y la soledad del cuarto de estudio no ayudaba, así que mi dedicación y motivación estaban en los mínimos.

La gestión de los requisitos del sistema la estaba haciendo con Scrumpy, que es un software para gestionar al estilo Scrum; de modo que tenía una larga lista de historias de usuario sin hacer y unas estadísticas de velocidad y puntos de historias de usuario por sprint que solo podían estimar una entrega aún lejana. En otras palabras tenía justo lo que un desarrollador desmotivado necesita para que desee invertir el tiempo en leer en lugar de programar.

Y fue leyendo que reencontré a Kanban.

Necesitaba algo más visual que una lista ordenada de trabajo pendiente y unas estadísticas negativas. Necesitaba algo que me motivara, que me dijera: "Te falta por hacer esto; pero haz hecho todo esto... ¡Ya falta menos!" Así que al releer los principios de Kanban y la simplicidad del método me decidí a utilizarlo.

Busqué una pizarra, la preparé y coloqué en la columna de to-do un post-it por cada historia de usuario del sprint en curso; tomé una de tamaño S, la pasé a la columna in progress y me puse a programar.

La rápida aglomeración de las historias cortas terminadas en la columna done! fue el combustible que necesitaba para reemprender con ganas el proyecto. Entraba en el estudio desorientado y la pizarra me le ponía claro: "estás trabajando en esto (y solo en esto) que ves en in progress". Levantaba la vista del ordenador y ahí estaba la pizarra de Kanban mostrándome cuánto había hecho y, sobre todo... ¡cuán poco me faltaba!

Definitivamente Kanban me ayudó con aquél proyecto, lo terminé, la pizarra permanece ahí, esperando el siguiente proyecto para organizarme el trabajo y darme el ánimo que necesite. Sin embargo, la experiencia fue demasiado buena para dejarla en casa, así que decidí probar en el trabajo.

Llevando Kanban a la oficina

En el departamento de desarrollo tenemos una pared de cristal que hace la mayoría de las veces de pizarra colectiva pero, debido a su carácter comunitario tuve que improvisarme el tablero con un trozo de cartón. Así que entre risitas y chistes de "una cerveza y una ración de calamares para la mesa 1", monté mi pizarrita con los primeros post-it.

Las primeras impresiones fueron positivas: cada vez que venían a preguntarme cómo estaba de trabajo o en qué estado estaba un proyecto, con un par de explicaciones y una mirada rápida a la pizarra eran suficientes para que se formaran una idea rápida de lo que querían saber.

Mi pizarra Kanban en la oficina

Sin embargo los problemas comenzaron pronto, con la priorización de tareas, pues resulta que en la empresa suelo llevar más de un proyecto a la vez, de modo que el trabajo planificado respondía a 2 niveles de prioridades: prioridad entre proyectos y prioridad entre las tareas de cada proyecto. Esto obligaba a hacer una reorganización engorrosa que rápidamente pasó a ser una división imaginaria de la pizarra con una fila para cada proyecto, lo cual ya deformaba la visión global de la prioridad real de las tareas y cambiaba el alto de las "filas", con su consiguiente reorganización, cada vez que aumentaba una tarea en un proyecto.

El experimento perduró durante unas semanas, hasta que el número de proyectos en paralelo y la necesidad de compartir el tiempo de trabajo entre proyectos terminaron haciendo insostenible el mantenimiento de la pizarra.

De modo que la experiencia de Kanban en la oficina no dio los frutos que esperaba pero me sirvió para algo:

1. Corroborar que Kanban es una herramienta magnífica para visualizar rápidamente el estado de un proyecto (o una etapa del proyecto).
2. Concluir que una pizarra Kanban no es útil para llevar más de un proyecto a la vez.

¿Entonces es o no es útil Kanban en el desarrollo de software?

Bueno, la experiencia del proyecto doméstico sugiere que Kamban sí es útil para gestionar el trabajo en un proyecto con tareas estables, bien definidas y con prioridades poco cambiantes; por ejemplo, en un ciclo corto de desarrollo como los sprint de Scrum. Sin embargo, la experiencia en la oficina sugiere que Kanban no es útil si intentamos aplicarlo a varios proyectos a la vez o con tareas muy variables y con prioridades en constante cambio.

Todo esto, claro está, debido al carácter material de una pizarra Kanban física. Si tuviéramos los recursos para dedicar una pizarra electrónica y montar un sistema de e-Kanban, otro gallo cantaría.

Entonces... ¿es útil Kanban? Si, es útil; aunque todo depende de las características del proyecto y el entorno.

II Cumbre de Desarrolladores de Samsung: Bada y software para televisores

El pasado miércoles (23/11/2011) estuve en la II Cumbre de Desarrolladores de Samsung, donde se presentaron las últimas novedades en materia de aplicaciones para dispositivos móviles de esta compañía. Lo más sorprendente: los televisores entran en la competencia de las tiendas de aplicaciones. Fui al evento en busca de lo relacionado con el desarrollo para teléfonos móviles y, sobre todo, en Android; pero me encontré con un foro enfocado en Bada y Smart TV.

Bada

Durante la sección de la mañana casi todo rondó sobre el desarrollo de aplicaciones móviles pero, sobre todo, basándose en Bada. Resulta que, por lo que podía verse en la sala da exposiciones, Samsung parece estar decidido a impulsar con fuerza este sistema operativo haciendo la interfaz de sus teléfonos con Bada tan parecida a los de Android que cuesta notar la diferencia.


Quien haya manejado un teléfono con Android podrá desenvolverse con un Bada sin ningún problema: el sistema de menús es casi idéntico y la apariencia en general es tan parecida que cuando tomé el Samsung Wave III tuve que mirar en el menú los datos del software del teléfono para convencerme que no se trataba de un móvil con Android. De modo que, de cara al usuario, Samsung está intentando allanarles -y si es posible hacerles transparente- el caminio del cambio a los usuarios.

Wave y Galaxy, Bada y Android

En cuanto a los programadores, las conferencias fueron también la demostración de la intención de Samsung de hacer de Bada su principal plataforma. Si bien es cierto que desarrollar en C++ no ayuda a que los desarrolladores de Android se adapten con facilidad, los desarrolladores para iPhone podrían recibir con agrado esta plataforma pues la charla sobre migración de aplicaciones de iOS a Bada daba la impresión de que el modelo de desarrollo y la SDK habían sido concebidos con la intención de atraer a estos desarrolladores facilitándoles el cambio como a nadie.

Para finalizar y abrirle las puertas a todos, presentaron también la posibilidad de desarrollar con HTML5 + JavaScript con acceso a funcionalidades nativas del móvil.

Smart TV

Esta fue, para mí, la gran sorpresa: hacer de los televisores un dispositivo más para el despliegue de aplicaciones. Toda la sección vespertina se dedicó al tema del desarrollo de aplicaciones para Smart TV que no solo estará presente en los televisores de Samsung, sino también en sus reproductores de Blue-ray.

Smart Hub: el punto de acceso a las aplicaciones de Smart TV en Samsung

Ya no se trata de que los televisores tengan menús para navegar por ciertos contenidos multimedia locales y fuentes de entrada de vídeo, ni de las ofertas de televisión a la carta que ofrece cada proveedor de televisón; sino de un dispositivo más, conectado a Internet y con la posibilidad de instalar software de cualquier fabricante. Samsung ha llevado el concepto su de tienda de aplicaciones para teléfonos móviles a los televisores y reproductores de Blue-ray. Así que en breve estaremos viendo un número creciente de productos que los consumidores tendrán a su libre disposición. Para el usuario es una pantalla más: además del móvil, el tablet y el portátil, ahora podrán disfrutarse de las aplicaciones preferidas en el televisor, relajados en el sofá e interactuando a distancia con el propio mando del televisor, o con un móvil o un tablet conectados por Wifi.

Para el final de la jornada presentaron la SDK de Smart TV y los procesos del desarrollo, empaquetado y distribución de aplicaciones, que estarán implementadas en HTML5 + JavaScript. De modo que, poco a poco, ésta se irá abriendo camino como una plataforma más para la cuál habrá que desarrollar aplicaciones.

El padre de LISP, John McCarthy, ha muerto



Mi despedida a John McCarthy, escrita en LISP

Aunque muchos lo puedan considerar un lenguaje poco práctico para mi LISP significa mucho: mi primer éxito en un examen de premio en la Universidad, la base de mi tesis de maestría y, aunque parezca increíble, fuente de ingresos en el año 2009. Así que no puedo decir menos que: gracias, John McCarthy, descansa en paz.

Estuve en el Workshop de Desarrolladores de Aplicaciones Accesibles de Vodafone

Ayer (28 de septiembre del 2011) se efectuó en las instalaciones de Vodafone del Parque Empresarial La Moraleja un workshop sobre el desarrollo de aplicaciones móviles accesibles. Lo más interesante fue la presencia de usuarios con necesidades especiales para el uso de las aplicaciones móviles, que comentaron sus experiencias y expectativas para mejorar y facilitar el uso de estas aplicaciones. Para el final del evento resultó muy provechosa la sección de simulación de discapacidades visuales y motoras.

De la exposición de estos usuarios con limitaciones visuales, auditivas, motoras y cognitivas concluí que hay 2 necesidades que eran casi comunes a todos:

1. Aumentar el nivel de personalización de las aplicaciones.
2. Simplificar los procesos de captura de información.

Necesidades de accesibilidad

Aumentar el nivel de personalización de las aplicaciones

La personalización fue un reclamo común. Se plantó desde modificar el volumen, la intensidad o la duración de las señales acústicas, visuales y táctiles, hasta la reasignación de teclas:

• Las personas con limitaciones auditivas necesitan modificar las señales acústicas para aumentarles su volumen o remplazarlas por señales vibratorias; que se puedan asignar diferentes frecuencias y duraciones de las vibraciones o diferentes colores, intensidades y duraciones del Led de notificación a distintos eventos. Por ejemplo: asignar distintas vibraciones a distintos contactos de modo que, al recibir una llamada de uno de estos, se le pueda identificar, en función de las vibraciones producidas.
• Las personas con limitaciones motoras necesitan que una función asignada a una tecla pueda ser reasignada a otra que le sea más fácil de pulsar, o que pueda cambiarse el tamaño de los elementos de interacción (como un botón) para facilitar su pulsación.
• Las personas con limitaciones visuales necesitan un alto nivel de retroalimentación sonora y táctil por lo que aumentar la personalización de los elementos de interacción como notificaciones de éxito o fracaso, procesos en ejecución o esperas, mejora significativamente el uso de las aplicaciones.

Simplificar los procesos de captura de información

Una solicitud común también fue la elaboración de aplicaciones que disminuyan la interacción escrita y contribuyan a la eliminación del papel como soporte de información o, como mínimo, que faciliten la extracción de información de medios impresos:

• Las personas con dislexia y las personas con limitaciones auditivas que prefieren el lenguaje de señas se decantan por la interacción mediante lenguaje gráfico: iconos, imágenes, vídeos...
• Las personas con limitaciones motoras prefieren las interfaces táctiles a los teclados.
• Las personas con limitaciones visuales necesitan aplicaciones que incorporen lectores de códigos, reconocimiento óptico de caracteres y funcionalidades de realidad aumentada que les faciliten la captura de información de medios impresos u otras fuentes.

Experimentar discapacidades visuales y motoras

En la sección final del evento se repartieron entre el auditorio distintos artefactos para simular dificultades visuales y motoras. La experiencia fue algo chocante porque de repente uno puede descubrir cuán poco usables son algunos dispositivos o aplicaciones en las manos de personas con estas limitaciones. Los medios que probé fueron:

1. Gafas de pérdida de agudeza visual de nivel 1 y nivel 2.
2. Gafas de simulación de cataratas.
3. Gafas de simulación de visión en túnel.
4. Gafas de pérdida de visión central.
5. Guantes de simulación de artritis.

Las limitaciones que más me afectaron el uso del móvil fueron las 3 últimas: la visión en túnel me obligaba a mover el móvil para poder ver diferentes zonas del mismo, por lo que perdía la referencia de lo que estaba haciendo; la pérdida de visión central me obligaba a poner el móvil en un ángulo de la cara en el que era muy difícil ubicar espacialmente dónde tocar las teclas y con los guantes de artritis casi se me cae el móvil de la mano.

El concurso

Como parte del evento se anunció (aunque ya un poco tarde para los que no lo conocíamos porque vence el 15 de octubre del 2011) el concurso de desarrollo de aplicaciones móviles accesibles de la Fundación Vodafone (Vodafone Foundation Smart Accessibility Awards 2011) que, además de la reconfortante satisfacción de saberse hacedor de algo útil, ofrecerá 4 premios de 50.000 € cada uno.

Finalmente

Al margen de si hay tiempo o no para participar en este estimulante concurso, el workshop me resultó muy instructivo y motivante para tratar de contribuir a que los desarrollos en los que participe, como mínimo, intenten aprovechar las facilidades que traen los frameworks para hacer las aplicaciones más accesibles y, si es posible, incorporar esos pequeños cambios que significan tanto para los usuarios que se encuentran con dificultades para utilizar nuestros productos.

Mi primera aplicación en Android: lecciones aprendidas

La semana pasada terminé mi primera aplicación "seria" para Android y la sensación inicial ha sido muy buena: desarrollar para Android es bastante rápido, fácil y coherente. Aunque, claro está, lo de "rápido" solo llegó luego de familiarizame con el entorno de desarrollo y la filosofía de trabajo en Android porque al principio hacer cosas elementales resultaron auténticos martirios.

La aplicación era pequeña y se trataba de una migración forzada de un desarrollo que ya había hecho para Windows Mobile y que, debido a que ya es imposible encontrar móviles con Windows Mobile, hubo que hacer su equivalente para Android, de modo que esta fue mi primera aplicación para Android, al margen del clásico Hello World y el Been there, Done that! del Teach Yourself Android Application Development in 24 Hours.

Lecciones aprendidas

Pues bien, resulta que para Android se desarrolla con Java pero no tiene nada que ver con las aplicaciones hechas en JavaME ni JavaSE; así que la experiencia previa haciendo MIDlets o aplicaciones de escritorio con Java no me valió de mucho. De modo que casi partí de cero y como tuve mis tropiezos, en pro de evitar tenerlos otra vez, dejo aquí algunas recomendaciones para acortar el proceso de adaptación:

• Desarrolla la aplicación usando un dispositivo real.
• No intentes hacerlo todo con el diseñador porque no siempre se puede, de vez en cuando hay que editar el XML manualmente.
• Aunque la aplicación se vaya a ejecutar en una versión anterior de Android, es recomendable utilizar el diseñador de interfaces de las últimas versiones.
• Intenta sustituir los Web Services y SOAP por REST y JSON.

Ejecuta siempre la aplicación usando un dispositivo real.

Los primeros días perdí horas de espera porque el simulador del SDK de Android es desesperantemente lento, incluso más lento que el de Windows Mobile (que ya es mucho decir), y como al principio se invierte mucho tiempo en hacer y probar pequeños cambios, la espera ocupa un por ciento muy importante del tiempo de desarrollo. Cuando finalmente pude depurar la aplicación directamente en un móvil, concluí que el dinero que pueda costar un móvil con Android se recupera con creces en el tiempo invertido para hacer la aplicación.


No intentes hacerlo todo con el diseñador porque no siempre se puede, de vez en cuando hay que editar el XML manualmente.

Esto es un hecho que me costó asumir pero eso es lo que hay: el diseñador del plugin de Android para Eclipse (ADT) es imperfecto y terminaremos más rápido si modificamos manualmente algunas cosas directamente en el XML que si tratamos de hacer la misma tarea con el diseñador. Un caso típico de esto es reorganizar elementos dentro de la interfaz: es mucho más rápido irse al XML, cortarlo y pegarlo donde quieres, que tratar de hacerlo con el diseñador.

El mismo layout visto en el diseñador
para Android 3.0 y 2.1

Aunque la aplicación se vaya a ejecutar en una versión anterior de Android, es recomendable utilizar el diseñador de interfaces de las últimas versiones.

El motor del diseñador de versiones más nuevas se mejora continuamente pero los de versiones anteriores parecen que solo son mantenidos, de modo que una misma interfaz puede verse de forma muy dispar si usas una versión del diseñador u otra y, por regla general, se verá mejor en las últimas versiónes del diseñador que en una versión anterior.

Por ejemplo, un layout para una aplicación que se ejecutará en Android 2.1 se parece más al resultado obtenido en un móvil con 2.1 si se visualiza en el diseñador de la versión 3.0 que en el diseñador de la versión 2.1.

Intenta sustituir los Web Services y SOAP por REST y JSON

Al igual que en JavaME, en Android no hay herramientas que faciliten el trabajo con Web Services, de modo que implementar un proxy para consumir un Web Service puede ser una tarea bastante engorrosa. Sin embargo, si se tiene control sobre los servicios y pude implementarse una versión con la que se intercambien datos mediante JSON, vale la pena extender el servicio con esta funcionalidad porque el desarrollo en Android se simplificará muchísimo. Baste decir que ni en Teach Yourself Android Application Development in 24 Hours ni en Android Wireless Application Development dedican ni un solo apartado a SOAP y las comunicaciones con Servicios Web y, en su lugar, cada vez que se trata el tema de comunicarse con un servicio de datos siempre lo hacen con interfaces REST y aunque se toca el tema del parseado de XML devuelto por algún servicio me quedó bastante claro que si está en nuestras manos probablemente sea mucho más fácil adaptar los servicios para consumirlos por REST e intercambiar datos en JSON, que desarrollar un cliente en Android que consuma el Web Service con SOAP como medio de intercambio.

¿Y entonces qué?

Pues, al final y a pesar de los contratiempos por ser un novato, desarrollar para Android fue muy divertido. Aunque las herramientas de desarrollo aún tienen sus pequeños detalles de estabilidad están muy completas y me han dejado claro por qué Microsoft ha tenido que lanzar a coste cero una edición de Visual Studio para desarrollar para Windows Phone. Por otra parte, al margen de los IDEs, hay que decir que el SDK de Android está muy bien concebido con lo que hacer una aplicación multiidioma y que se adapte bien a dispositivos con distintas dimensiones es más simple y coherente que en JavaME o Windows Mobile.

¿Entonces?... ¡Bienvenido, Android!