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.

BlackBerry 10 Jam World Tour - Enterprise Edition en Madrid

La semana pasada estuve en el evento de presentación de BlackBerry 10 en Madrid, donde presentaron el nuevo sistema operativo de RIM, se habló de oportunidades, estrategias, tecnologías de desarrollo y, como no... ¡Donde me obsequiaron un dispositivo BlackBerry 10 Dev Alpha!

BB10 Dev Alpha

La conferencia

El BlackBerry 10 Jam World Tour – Enterprise Edition de Madrid se efectuó en la planta 42 del Torre Espacios. Fue mi primera vez en un rascacielos, así que cuando me dí cuenta que hasta las azafatas eran de habla inglesa ya había sobrepasado mi umbral  de asombro y el no oficial pero omnipresente idioma de la charla no hizo más que reafirmarme que el inglés no es una opción, sino una realidad inevitable.

Una buena parte de la charla se concentró en mostrar las características que distinguen a BlackBerry y las ventajas que ofrece para construir e integrar soluciones empresariales y, por la tarde, pasamos de la palabra a la acción en una sesión práctica.

Lo más interesante en herramientas de desarrollo: HTML5 y Android para BlackBerry

La sesión práctica comenzó cuando todos en la sala nos pusimos manos a la obra para poner a punto el Cascades como entorno de desarrollo para C++ y una máquina virtual de BlackBerry 10 en VMWare. Labor que resultó algo lenta y, en mi opinión, un poco complicada; sobre todo la parte de la máquina virtual en VMWare.

Sin embargo cuando pasamos al WebWorks para las implementaciones con HTML5 y JavaScript, se hizo la luz: el proceso fue extremadamente simple y rápido. Tanto así que, luego de instalar el SDK, solo hizo falta instalarle un plugin (llamado Ripple) al Chrome... y listo: ya estaba montado el entorno de simulación y pruebas.

¿Podría se más simple? Parecería que no, pero sí: en RIM no solo están intentando captar a la ingente masa de desarrolladores que ya controlan las tecnologías Web, sino que también intentan captar a los desarrolladores de Android, de modo que han puesto muy fácil el proceso para comenzar a desarrollar para BlackBerry 10. Tan fácil, que, simplementente, no hay que hacer casi nada: quien haya hecho una aplicación para Android, podrá reempaquetar el apk con el instalador para generar un paquete válido para BlackBerry, sin necesidad de reescribir nada. De modo que BlackBerry 10 cuenta con el potencial generado por miles y miles de aplicaciones que ya existen para Android y podrían sean reempaquetadas y subidas a la tienda de aplicaciones de BB, el AppWord.

El dispositivo BlackBerry 10 dev Alpha

Actualizando el BBM en el BlackBerry 10 dev Alpha

Al final del evento a un grupo de desarrolladores nos obsequiaron con un prototipo del nuevo BB 10 que será lanzado a principios del año que viene. Este estupendo "regalo" me confirmó que RIM está haciendo todo lo posible para llamar la atención de la comunidad de desarrolladores pues, como ellos mismos hicieron notar en la charla, un móvil o un tablet no tiene posibilidades de éxito si no cuenta con una buena cantidad de aplicaciones disponibles. De modo que además del aumento de opciones mediante la diversificación de las tecnologías disponibles para programar, RIM está estimulando a los programadores con la organización de Hackatons y obsequios como éste que, sin duda, nos da un empujón a los que queremos comenzar a hacer aplicaciones móviles para esta plataforma.

Luego de utilizar un poco el terminal, se le toma rápidamente aprecio a la impresionante calidad de la pantalla (lamentablemente mi amateur foto no le hace honor) y a la velocidad del sistema en general. No obstante, hay que adaptarse a unos conceptos de navegación  distintos a lo que estamos acostumbrados pues no hay ningún botón, salvo el de encendido, de modo que el tradicional botón de inicio que tienen los otros sistemas para ir a la pantalla principal, de inicio o el "home" del sistema, aquí no existe pues ha sido remplazado por un gesto.

Pero no entraré en más detalle porque la descripción del nuevo sistema operativo de BlackBerry es motivo suficiente para todo un post.

III Cumbre de Desarrolladores de Samsung: Android, Smart Devices y Tizen

Hace unas semanas (el 16/10/2012) estuve en la III Cumbre de Desarrolladores de Samsumg, en la que, como ya es habitual, se presentaron los productos y tecnologías en las que Samsung está apostando. Android afianzó su posición como plataforma de base, quedando Bada relegado al olvido que, aunque ocupó una buena parte de la cumbre anterior, este año no recibió ni una sola mención y, en su lugar, hizo su aparición Tizen.

Aunque se tocaron más temas, aquí comentaré lo que para mí resultó más interesante de la cumbre: la presentación de la Galaxy Camera, el paso evolutivo del SmartTV hacia Smart Interaction, el stylus con su SDK y la anunciada presentación de Tizen.

Las cámaras fotográficas como nueva plataforma de desarrollo

Este año el ecosistema de multiscreen de Samsung, formado por 4 plataformas -smartphones, tablets, televisores y portátiles- creció con la inclusión de la pantalla táctil de 4.77 pulgadas de la Galaxy Camera. Una cámara de 16 megapíxeles que dejó de ser un dispositivo pasivo para convertirse en una smartcamera completamente interactiva; para lo cual la dotaron de un Android 4.1 corriendo en un procesador de cuatro núcleos a 1.4 GHz, con 1 GB de RAM y conectividad 3G y WiFi. Esto, dicho así, parece más un smartphone que una cámara; pero ya que ningún smartphone tiene un zoom óptico de 21x, ni control manual de todos los parámetros de la óptica de la cámara, esta mezcla no puede catalogarse como otra cosa que una cámara.

Pantalla, cuerpo y objetivo de la Galaxy Camera

Esta fusión abre un mundo de oportunidades para el consumidor, comenzando por la edición de fotografías y vídeos en la propia cámara, o el almacenamiento en la nube de las capturas que ya no necesitarán esperar a ser descargadas en el ordenador para liberar la memoria SD.

Por otra parte, contar con Android en la cámara la convierte en una plataforma más para desarrollar aplicaciones; en la que también Samsung ofrecerá  APIs específicas para el desarrollo de aplicaciones que saquen partido al dispositivo, como funciones para el seguimiento de objetos en movimiento o la sincronización de imágenes; pero eso..., aún está por llegar.

Del SmartTV al Smart Interaction

Este año Samsing volvió a sorprender, presentando el nuevo concepto de televisión inteligente, dotada de lo que llamaron Smart Interaction.

Demostración del uso de Smart Interaction

En una presentación muy entretenida y dinámica, ilustraron la evolución de la televisión tradicional en Samsung hasta llegar a la interacción inteligente donde ahora la tele, además de ejecutar aplicaciones, incorpora nuevas formas más naturales de interacción, al tradicional mando a distancia. Para lograrlo, Smat Interaction comienza por incorporar una cámara y un micrófono aun televisor con SmartTV, de modo que es posible controlar el televisor mediante comandos de voz; hacer gestos con la mano para señalar, seleccionar y arrastrar objetos en la pantalla; y utilizar el reconocimiento facial para desbloquear funciones o recordar configuraciones o partidas pendientes en aplicaciones y juegos.

Además de la demo que incluyó una vídeo-llamada por Skype combinando el control por voz y gestual, en la sala de exposiciones había televisores disponibles para interactuar con ellos y, cosa "rara", el que tenía una versión de Angry Birds para SmartTV no paraba de tener a alguien "evaluando" el producto.

Galaxy Note y S-Pen SDK

Junto al Smart Interaction, esta fue una de las partes más interesantes porque presentaron la nueva versión 2.2 del SDK para la interacción con el stylus en los dispositivos de la familia Note. Algunas de las aportaciones o mejoras vinculadas a los recientemente lanzados smartphone y tablet -Galaxy Note II y tablet Galaxy Note 10.1- fueron:

1. Reconocimiento de la extracción y guardado del stylus.
2. Mejoras en el reconocimiento de movimientos (hovering) y pulsaciones del botón del stylus sin tocar la pantalla hasta una distancia de 1 cm.
3. Aumento de la sensibilidad del stylus, llegando al reconocimiento de 1024 niveles de presión.
4. Aplicaciones del stylus en la identificación biométrica de una persona mediante su firma, gracias al reconocimiento de la forma, el ritmo y la presión durante el trazo.

Algo a notar es que, ciertamente, el dispositivo y las APIs han mejorado pues la experiencia de uso del Galaxy Note II supera con creces a la de su predecesor. Si en el 2011 el Galaxy Note prometía, aún tenía cierto retardo en la aparición del trazo, cuando se utilizaba para dibujar. Sin embargo, las nuevas APIs y el hardware más potente del Note II ofrecen una experiencia muy natural en la toma de notas manuscritas y en el dibujo.

Tizen: mucho ruido y pocas nueces

Después de esperar ilusionado que llegara el momento de Tizen, sufrí una decepción. Al ver que Bada ya no figuraba en el programa de la conferencia y que desde el principio se estuvo mencionando el nombre del nuevo sistema operativo móvil, esperaba escuchar una declaración de intensiones sólida respecto a esta "promesa" de sistema multiplataforma declarado abierto por partida triple: open Web, open source y open governance.

Sin embargo, al ser precisados por algunos asistentes, desde Samsung hicieron hincapié en que aún no hay fechas para una versión estable de la SDK y que no tienen un roadmap definido. De modo que por ahora no recomendaban migrar ninguna aplicación y sugirieron, de momento, solo explorar el sistema y las SDK, pero nada más.

Efecto demo en la charla de AllShare Framework

Para terminar, una nota que le da razón de ser a este blog. Resultó ser que en la presentación de la SDK para compartir contenidos y conectar los distintos dispositivos de Samsung (AllShare Framework), hubo imprecisiones que llegaron a frustrar la presentación. Cuando en la demo intentaron controlar desde el móvil una aplicación que se ejecutaba en el televisor, las continuas demoras y fallos hicieron que, luego de unos minutos que parecieron infinitos, se continuara con la presentación sin mostrar la interacción deseada.

Como comentó alguien en un tweet: hasta los grandes sufren el efecto demo.

OpenLayers Cookbook

Portada del libro
OpenLayers Cookbook

Hace algún tiempo puse en la lista de proyectos pendientes, migrar una aplicación Web con cartografía basada en las APIs de Google Maps a las APIs de OpenLayers. De modo que estaba leyendo el libro "OpenLayers 2.10 Beginner's Guide", cuando calló en mis manos "OpenLayers Cookbook".

OpenLayers Cookbook. 60 recipes to create GIS web applications with the open source JavaScript library

Como su nombre lo indica, este libro hace una recopilación de 60 recetas que podrían ser de utilidad en la creación de Sistemas de Información Geográfica (SIG), mediante una de las bibliotecas de JavaScript más completas para estos fines: OpenLayers.

Aunque el libro tiene un enfoque esencialmente práctico, no es necesario tener conocimientos previos de OpenLayers pues los conceptos y funcionalidades son introducidos progresivamente con cada receta: el libro comienza ilustrando los conceptos básicos de cartografía Web mediante la resolución de problemas sencillos y termina con temas mucho más complejos, como la creación de componentes personalizados. De modo que no importa si sabes mucho o poco de OpenLayers: si sabes poco, aprenderás leyendo cada capítulo, ordenadamente; y si sabes mucho, el libro te servirá como una colección de soluciones a problemas prácticos y concretos en el día a día de la creación de sistemas con cartografía Web.

HTML, CSS, JavaScript y algo más

Lamentablemente, los Sistemas de Información Geográfica implican demasiados elementos como para crear soluciones triviales. Por eso, aunque la lectura y comprensión de las 60 fórmulas solo requiere el conocimiento de HTML, CSS y JavaScript; la puesta en práctica y prueba de las recetas también requiere entender -aunque a un nivel muy básico- algo de Apache, PHP y el uso de widgets de Dojo, si se quiere implementar las soluciones tal cual se dan en el libro. No obstante, es relativamente simple modificar las recetas para eliminar la dependencia de Dojo y, si se conocen otros servidores Web (como IIS o Tomcat) y otras tecnologías para el desarrollo del backend (como ASP.NET o JSP), es también bastante fácil adaptar las soluciones dadas para que funcionen con estas otras herramientas.

Entonces...

El enfoque práctico del libro lo hace atractivo, instructivo y útil; cuya lectura da frutos desde las primeras páginas porque desde el principio nos hace sentir capaces de resolver problemas concretos. Así que, si tienes poco o ningún conocimiento de OpenLayers y necesitas empezar a utilizarlo, o ya estás utilizando OpenLayers y necesitas acelerar tus resultados, o simplemente estás aburrido de los libros y tutoriales cargados de tecnicismos y quieres algo más práctico... entonces... este libro es para ti.

Estuve en el meetup de MadQA "Mitos del Testing Exploratorio"

MadQA en Meetup.com

Ayer (18 de octubre del 2012) estuve en la charla sobre testing exploratorio organizada por el grupo MadQA, e impartida por Jose Aracil, de Globe Testing. Aunque llegué algo tarde por tener que pasar primero por el fisio, llegué a tiempo para quedar convencido de que vale la pena invertir una parte del tiempo libre en estos meetups.

Si tuviera que quedarme con una sola cosa de la charla, guardaría la metáfora del turista, donde se compara al testing exploratorio con el proceso que sigue un turista que decide visitar una ciudad "por su cuenta" y que, a pesar de no contar con una guía detallada, al final de su visita conocerá la ciudad, sabrá qué lugares evitar, cuáles repetir y por dónde comenzar a explorar nuevas partes en el futuro.

Si bien la charla fue provechosa, con una pequeña demo del uso de Microsoft Test Manager 2012, el networking post-charla fue muy productivo pues tuve el placer de compartir con testers "de verdad": gente que se dedica exclusivamente al testing y que se nota que sabe un montón de la materia.

¡Cuánto nos falta en las pequeñas y medianas empresas para asumir con seriedad esta parte olvidada del proceso de desarrollo del software!

Google pierde terreno en el campo de los mapas. ¿Estas preparado para el cambio?

Desde hace algún tiempo hemos asistido con pasividad al comienzo de una guerra en el mundo de los mapas. Hasta ahora, Google había sido el permanente ganador de estas silenciosas batallas; pero las cosas han comenzado a cambiar.

Para mí como consumidor, todo comenzó en el 2009 con el Nokia 5230 y su excelente servicio gratuito de mapas para móviles Ovi Maps; pero como desarrollador, no fue hasta el 2011 que comencé a sentir la necesidad de encontrar el alguna alternativa a las APIs de Google Maps.

Servicio de actualización de mapas
de TomTom (clic para ampliar)

Hasta el 2009 había un ganador bastante claro en el mundo de la cartografía móvil con su popular aplicación en los GPS para coches: el TomTom, una combinación de GPS empotrado en un dispositivo de uso único con un software de navegación asistida por ordenador que no era (ni es) un producto tan barato como quisiéramos. Aún hoy, además de pagar por el dispositivo, debe pagarse una suscripción anual por la actualización de los mapas que, por ejemplo, los de España y Portugal rondan los 55 €.

Sin embargo, en el 2009 Nokia lanzó su teléfono 5230 con un servicio gratuito de cartografía y navegación incluidos, por el precio de un teléfono móvil de gama media-baja y actualizaciones gratuitas independientemente de la cantidad de ciudades o países que descargaras al móvil. De modo que, rápidamente el 5230 pasó a venderse casi más como GPS para coches que como un móvil y ahí comenzó la batalla en el mundo móvil. Tres años más tarde, aún ningún competidor (dígase iOS, BlackBerry o Android) tiene la opción de descargar gratuitamente los mapas al móvil y usarlos offline, sin necesitar una conexión de datos a Internet para su uso. (Lamentablemente esta ventaja no ha sido suficiente para mantener a Nokia a flote; pero ese es otro tema.)

Por su parte, casi desde el comienzo, Google Maps dominó los servicios de mapas en la Web, innovando, adicionando funcionalidades y haciéndole la vida fácil a los desarrolladores de aplicaciones Web que queríamos incluir información cartográfica en nuestros sitios. Sus competidores (entre otros Yahoo Maps y Virtual Earth, actualmente Bing Maps) también hicieron su parte y publicaron APIs para desarrolladores tan fáciles de usar como las de Google; pero éste les llevaba ventaja y después de aprender una tecnología, cambiar a otra da cierta pereza -salvo que haya una muy buena justificación-, así que la mayoría no vimos la necesidad de pensar en el cambio..., hasta el 2011.

En el 2011 Google hizo unos cambios en su política de uso de las APIs de mapas que restringió significativamente el volumen del uso gratuito de sus mapas. Para la mayoría de los sitios Web con poco tráfico, el cambio no les afectó; pero los grandes consumidores de los servicios de Google (tanto en la Web como en los móviles) sí vieron un cambio muy importante y decidieron actuar. El caso más famoso y sonado fue el de Apple que, en junio del 2012, hizo saber que dejarían de usar los servicios de Google para pasarse a un servicio de cartografía propio. No obstante, ya otros grandes habían hecho su elección, como Facebook, que varios meses antes se decantaba por los mapas de Microsoft para sus aplicaciones cartográficas; y otros, como Flicker, se han sumado recientemente al "movimiento alternativo" escogiendo a Nokia como su proveedor para la geolocalización de sus fotos, además de su ya existente vínculo con OpenStreetMaps, proveedor éste que, dicho sea de paso, promete tanto que Microsoft lo ha incorporado como una capa más en su servicio de mapas Web y Apple ya lo estaba usando en algunos de sus productos, antes de decidirse a abandonar del todo el uso de Google Maps.

Microsoft Bing Maps, Nokia Maps, OpenStreenMaps y Google Maps (clic para ampliar)

Al ver esta avalancha, Google reestructuró otra vez su política de precios, haciendo un recorte significativo; pero el mal ya estaba hecho: su señorío absoluto en los mapas Webs ha comenzado a declinar y ahora los desarrolladores tenemos que lidiar con las APIs de, por lo menos, 4 proveedores diferentes: Google, Microsoft, Nokia y OpenStreetMaps.  

¿Como cubrir este abanico de proveedores? ¿Deberíamos decantarnos por un solo proveedor y asumir los riesgos de cambios futuros en su política de uso?

Probablemente, no haya una solución universal y absoluta; pero por suerte existe una solución aproximada: OpenLayers. Esta biblioteca se está postulando como la opción número uno para desarrollar una aplicación de mapas en la Web con la posibilidad de utilizar todos estos proveedores de cartografía, sin necesidad de conocer las particularidades de la implementación de cada uno.

Entonces, ya va siendo hora de que venzamos la inercia, asumamos estos cambios en la cartografía Web y nos pongamos manos a la obra. Mi recomendación: usar OpenLayers en el próximo proyecto, aunque sea combinado con Google Maps y así ir introduciendo las nuevas tendencias, sin abandonar del todo lo que conocemos y nos es familiar.

Aplicación en modo kiosko para Android: lo que no se puede hacer

Generalmente solemos hablar de lo que se puede hacer y cómo se hace; pero para evitar quebraderos de cabeza a veces es bueno saber qué es lo que no se puede hacer y así no perdemos el tiempo intentándolo. Debido a que ya he pasado por eso (intentar infructuosamente hacer ciertas cosas con Android) pongo aquí algunas cosas que he verificado que no es posible hacer o que no son recomendables hacer.

Nota: Antes de comenzar debo aclarar que lo que aquí se comenta está relacionado con el desarrollo de aplicaciones usando la SDK de Android que serán ejecutadas en un dispositivo con su ROM original, sin rootear. Ninguna conclusión de las siguientes deberá aplicarse al desarrollo con otras plataformas como la NDK, Mono Droid o cualquier otro medio utilizado para desarrollar aplicaciones para Android, ni para el caso de la ejecución de aplicaciones en un entorno con privilengios de súper usuario.

Las cosas que intenté hacer y ahora describo, estaban relacionadas con el desarrollo de una aplicación en modo kiosko (ver post anterior Aplicación en modo kiosko para Android). Una aplicación en modo kiosko, por definición, debería limitar toda la interacción del usuario con el dispositivo a los elementos que se quieran y definan en la aplicación. En nuestro caso, se suponía que todos los botones del hardware estarían bloqueados, incluso el botón para bloquear o apagar el móvil. Sin embargo, aquí nos encontramos con la primera limitación en Android: 

No es posible inhabilitar o desactivar el comportamiento del botón de encendido del móvil. 

Si bien es cierto que podemos interceptar algunos eventos relacionados con dicho botón, no hay nada que hacer al respecto salvo procesamientos al margen del proceso iniciado (apagado de la pantalla, reinicio o apagado del terminal). De modo que si queremos que una aplicación en modo kiosko en Android no sea interrumpida por la pulsación del botón de encendido, tendremos que inhabilitar físicamente dicho botón, lo cual es "poco" factible en la mayoría de los casos.


No obstante, supongamos que logramos inhabilitar el botón de encendido, digamos, porque empotramos un teléfono o un tablet con Android en una carcasa que limita su utilización a la interfaz táctil. Nos encontramos entonces con la necesidad de poder reiniciar o apagar el dispositivo, ya sea mediante algún elemento en la interfaz o de manera remota, reaccionando a un SMS, un código recibido por NFC, un patrón leído a través de la cámara o la estrategia que mejor nos convenga. 


Para reiniciar y apagar el dipositivo disponemos de los métodos reboot() y goToSleep(). Sin embargo, a pesar de que parece que podemos reiniciar y apagar el dispositivo con dichos métodos, la ejecución de los mismos requiere del permiso android.permission.DEVICE_POWER que, aunque no lo dice en la documentación de la SDK, está restringido a las aplicaciones que se ejecutan con permisos del sistema y, por tanto, nuestra aplicación no podrá apagar ni reiniciar el dispositivo ejecutándose como una aplicación corriente. De modo que:

No es posible reiniciar o apagar el móvil, por programación.

Finalmente, el último problema está relacionado con la intercepción de llamadas entrantes. En nuestra aplicación, deberíamos interceptar las llamadas entrantes y colgarlas para no interrumpir el funcionamiento de la aplicación. Sin embargo, aunque hay varias aplicaciones que logran hacer esto, lo hacen accediendo a una API no oficial que, desde la versión 2.3 de Android a quedado limitada a las aplicaciones que se ejecutan con permisos del sistema. De modo que, si nuestra aplicación se ejecutará en Android 2.2 o una versión anterior, podríamos usar la estrategia que se ilustra claramente este post: Blocking Incoming call - Android. Sin embargo, deberá tenerse en cuenta que ese código no funcionará en versiones de Android posteriores a la 2.2 pues desde la 2.3 el permiso necesario para manipular una llamada (android.permission.MODIFY_PHONE_STATE) se ha limitado a las aplicaciones del sistema. En Stakoverflow este tema se ha tratado extensamente (como en este hilo) y queda claro que no es posible hacerlo, y aunque hay quien propone diferentes estrategias para paliar el problema, ninguna es la solución definitiva a éste problema que pueda aplicarse a cualquier versión del sistema y en cualquier terminal. De modo que:

No es posible colgar una llamada entrante, por programación, en Android 2.3 o superior.

Hasta aquí las limitaciones con las que me he topado en el desarrollo de aplicaciones para Android. Seguramente haya muchas más, pero de momento, estas están verificadas como problemas, hasta el momento, irresolubles. A lo mejor alguien encuentra una solución universal y la comparte; pero por ahora:

• No es posible inhabilitar o desactivar el comportamiento del botón de encendido del móvil.
• No es posible reiniciar o apagar el móvil, por programación.
• No es posible colgar una llamada entrante, por programación, en Android 2.3 o superior.

JavaME dice adiós a los smartphones

En un post anterior comenté que asistiría a la charla Java ME Platform Evolution que se impartiría en Madrid, y asistí y lo hice con esperanza... incluso diría que con ilusión. Sin embargo, el encuentro fue tan decepcionante que me ha costado semanas acopiar ganas para hablar del tema.

Resulta que la primera impresión (que como dicen "es la que vale") fue decepcionante: en la sala estábamos 4 gatos -literalmente hablando- porque si éramos 8 o 9, debía descontarse a la conferenciante, el organizador y 2 trabajadores de Oracle que asistieron por voluntad propia pero que no cuentan para esta estadística. De modo que, asistentes como yo seríamos, como mucho, 4 o 5.

Entonces... mala señal: ¿una conferencia sobre una tecnología, relacionada con Java, el lenguaje más utilizado de España, impartida en Madrid, una de las dos ciudades con mayor movimiento informático de España... y solo asisten 5 personas?! Algo anda mal.

La charla estuvo muy bien. Renu Motwani expuso muy clara y organizadamente cuál era el presente y cuál sería el futuro de JavaME. Durante una buena parte del tiempo habló del crecimiento en la interconexión de dispositivos (no solo de teléfonos) y del crecimiento del número de feature phones (no smartphones) en mercados emergentes como las zonas rurales de la India o en África. Este crecimiento está claro que necesitará estar acompañado de servicios, y es ahí donde Oracle se concentrará: mejorar la plataforma para homogeneizar los desarrollos y abarcar la mayor cantidad posible de estos dispositivos y pheature phones.

De Android no se dijo nada; de iOS, nada; de Windows Phone, nada... incluso ni se mencionó algo del futuro del JavaME con  BlackBerry. Solo, luego de alguna que otra pregunta reincidente, salió Nokia como un "aliado no publicitado" de Oracle. (Lo cual no sería de extrañar pues el ex número 1 del mundo de los móviles trataría de usar todos los palos que pueda para hacerse su balsa salvavidas.)

Entonces fui esperando ver el despertar de Oracle, el renacer de JavaME en los smartphones y los tablets; pero me encontré con un cambio de dirección, donde Oracle ha reorientado sus esfuerzos hacia otros mercados.

Está claro que los pheature phones pueden ser una plataforma utilísima  pues un pheature phone de hoy puede tener más poder de cómputo que un ordenador personal de la década pasada; pero aún así, me sentí decepcionado: mi esperanza de usar JavaME en mis futuros desarrollos para smartphones y tablets se esfumó.

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