Hackaton en BlackBerry Jam Session Madrid

El sábado 15 estuve en el hackathon que organizó RIM en Madrid para cerrar el tour de los BlackBerry Jam Sessions 2012 por España. Fue una jornada intensa al final de la cual nuestro equipo logró terminar la aplicación y ponerla a funcionar en un BlackBerry 10 Dev Alfa.

Nuestro equipo, en el hackathon del BlackBerry Jam Session en Madrid

El equipo

Teniendo en cuenta que el margen de tiempo para desarrollar la aplicación era de 10 horas, habría sido más simple que cada uno intentara hacer algo sencillo de forma individual o en parejas; pero decidimos ir en equipo e intentar hacer un sistema entre todos, a pesar de la complejidad añadida. De modo que nos apuntamos cinco personas: cuatro para el desarrollo y una para el diseño.

Debido a que el grupo era muy heterogéneo, con diferentes grados de experiencia en el desarrollo móvil, terminamos repartiéndonos las áreas de trabajo y entonces, dentro de estas, cada uno asumiría a su ritmo las tareas que más cómodas le resultaran.

La planificación

El martes, por la noche, dedicamos una hora a decidir qué producto haríamos, la tecnología de desarrollo, el sistema de control de código fuente, nomenclatura para los identificadores y el sistema de trabajo. Luego de analizarlo, acordamos que usaríamos Java con el Runtime de Android, como plataforma de desarrollo y SVN, como sistema de control de código fuente.

Al terminar, concertamos un experimento para el jueves en el que haríamos uso de las herramientas, creando un proyecto simple que se hospedaría en el hosting de SVN, al que cada uno debería integrarle un layout  vacío, con su respectiva activy, de modo que todos verificáramos que nuestros entornos estaban preparados para trabajar en equipo.

El jueves, entre las distintas versiones del SDK, las distintas versiones de Eclipse y las distintas formas de trabajar con el SVN, lo que parecía que iba a ser corto, terminó siendo una jornada nocturna de varias horas, porque comenzamos a descubrir varios detalles que, de no haberlos tratado ese día, nos habrían arruinado el hackathon. No obstante, al final del ensayo, terminamos todos con nuestros entornos a punto para el maratón de programación del sábado.

El hackathon

El sábado nos reunimos en las instalaciones de garAJE y a las 10, luego de una pequeña introducción de 30 minutos, ya estábamos comenzando nuestro producto.

Lo primero fue crear un proyecto nuevo de Android, con las 6 activities y los layouts que llevaría la aplicación para partir de una base común de estructura y nombres. Luego, creamos un proyecto en Google Code y subimos el proyecto de Android. Acto seguido, coordinamos con qué se pondría a trabajar cada cuál y nos pusimos con ello.

La jornada fue intensa. No paramos hasta que llegó la hora de las pizzas; no obstante, la pausa fue corta: comer, beber y volver al trabajo. Y no es que 10 horas sean mucho, pero si era mucho el estrés de saber que en esas 10 horas debías empezar y terminar un proyecto en el que debían coordinarse 5 personas que antes de esa semana no habían trabajado nunca juntas.

Durante el desarrollo utilizamos móviles con Android para depurar la aplicación, pero para las 7 PM ya había llegado la hora de reempaquetar y firmar la aplicación para probarla en el BlackBerry 10 Dev Alfa que me habían obsequiado en un evento anterior de BlackBerry. Un rato antes habían pasado por las mesas, ofreciendo RedBulls y, entre la cafeína y la tensión de saberse cerca de la hora límite, esa última hora fue la más absorbente de todas: no veía a nadie, no escuchaba a nadie, salvo al equipo apurando los últimos minutos, frenético, intercambiando orientaciones y reclamos.

A última hora el plugin de BlackBerry para Eclipse no se instaló, fallando el proceso de instalación en la versión del Eclipse incluida en el ADT-bundle. No obstante, pudimos firmar y empaquetar gracias a la versión online de la herramienta; y cuando faltaban un par de minutos para nuestro turno de exposición del proyecto, hicimos el deploy del .bar con el instalador reempaquetado, gracias al plugin de Chrome PlayBook App Manager. Unos segundos después, nos llamaban al frente, para exponer nuestro proyecto.

Después de la exposición y responder a las preguntas, todo pareció volver a la normalidad: otra vez se escuchaban las voces de los demás equipos y el lugar pareció llenarse de personas.

¡Habíamos terminado el software y lo habíamos echado a andar en un dispositivo con BlackBerry 10!

Qué nos quedó

Splash screen de TrafficBB

Luego de la paliza del hackathon, nos quedó la experiencia y la satisfacción de lograr lo que fuimos buscando: trabajo en equipo capaz de generar software funcional, en muy poco tiempo.

Por supuesto, también nos quedó el software, un producto muy sencillo pero que consideramos útil y que, por tanto, publicaremos en las tiendas de aplicaciones de BlackBerry y Google, luego de testearlo en profundidad y pulir los detalles que aparezcan, por supuesto.

El producto (TrafficBB) es una aplicación para el aprendizaje de las señales de tránsito con una colección de las señales oficiales, según la Dirección General de Tráfico, y un área de auto evaluación con preguntas de selección múltiple para poner a prueba nuestros conocimientos.

De modo que, además de la experiencia nos ha quedado nuestra primera aplicación para el nuevo sistema operativo de RIM: el BlackBerry 10.

¿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.