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!

Windows Mobile ya es historia... y sigue sin sucesor.

Ya es un hecho: no se encuentran móviles nuevos con Windows Mobile, de modo que si el 30 de enero decía que aún le quedaba un aliento de vida al Windows Mobile ahora, lamentablemente, debo decir que ha muerto... y sigue sin remplazo.

Aún después de la noticia de la alianza de Microsoft con Nokia pensaba que, dada la inmadurez del Windows Phone 7, el Windows Mobile tenía alguna oportunidad de sobrevivir un tiempo. Sin embargo, la estrategia de marketing de Microsoft ha llevado a desterrar de la palestra pública a cualquier vestigio de los (ya viejos) WM6. En estos momentos ya no es posible encontrar móviles con Windows Mobile, salvo los que pudieran quedar en exposición y alguno que otro en alguna tienda de barrio. Pero ya está claro: si buscas un móvil con Windows "algo" ese algo ya no será "Mobile".

Lo triste del caso es que aún así, para quienes debemos desarrollar aplicaciones empresariales, Windows Phone 7 sigue sin darnos el control que necesitamos, así que no hay otro remedio que migrar a otra plataforma.

¿La opción ahora? ¡Android! ¿Por qué? Porque no hay muchas más opciones. A Symbian lo han degradado sus propios creadores y aunque hayan sacado una nueva versión y estén dándole bombo -ya que los del Phone 7 en móviles Nokia posiblemente no saldrán hasta el 2012- está claro que no es el sistema operativo del smartphone del futuro. Por su parte iOS y BlackBerry OS están descartados por lo prohibitivo del precio de los móviles que los soportan y Bada no tiene masividad ni siquiera en los propios móviles de Samsung cuyos "estrellas" son, en su mayoría, móviles con Android.

¿Entonces, qué nos queda? Descargar el Eclipse, poner un marcador a http://developer.android.com y... ¡A estudiar!

¡¿Que Nokia y Microsoft qué?!

Aún no salgo de mi asombro. Incluso luego de leer que un ex ejecutivo de Microsoft pasaba a ser el nuevo presidente de Nokia y que era el primer extranjero en la historia en ocupar ese puesto en la empresa finlandesa, ni por asomo podía imaginar lo que se anunciaría más tarde: ¡una alianza estratégica entre Nokia y Microsoft!

Pero si solo fuera una alianza para incluir elementos de terceros, aunque rara por ser Nokia tan conservadora -y un poco contracorriente- con su línea de desarrollo, se habría podido entender  pero... que Nokia renuncie a sus proyectos para móviles de gama alta en favor del Windows Phone 7 es más que inesperado: es choqueante. Es un salto tan radical en la línea de Nokia que el e-mail que enviara su nuevo presidente a los empleados, aunque anunciaba una decisión drástica, no dejaba entrever semejante transformación.

¿Qué se puede esperar entonces?  Pues un producto bueno: los terminales de Nokia son dispositivos con un hardware de indiscutible calidad y el sistema operativo de Microsoft, aunque aún no está maduro -como comentábamos en una publicación anterior- atraerá a muchos desarrolladores pues, no cabe duda, hay algo en lo que Microsoft no tiene rival: hacerle la vida simple a los desarrolladores dándole la mejor combinación de precio, herramientas de desarrollo y documentación que se puedan encontrar. Quien se haya tenido que configurar Eclipse para hacer aplicaciones móviles o haya tenido que pagar el precio de un iMac solo para poder desarrollar para el iPhone sabrá que es cierto, y más aún ahora, que el Visual Studio para desarrollar para el Windows Phone 7 no costará ni un céntimo más que los demás entornos de desarrollo de aplicaciones para las plataformas de la competencia.

¿Tendrá éxito esta alianza? ¿Quién supiera responder a esta pregunta! Lo que está claro es que ambas empresas se han tirado a fondo y están apostando todo en esta jugada porque entre los iPhone y los terminales con Android están desplazando del mercado a Nokia y Microsoft, cada uno en su terreno: al primero en el hardware y al segundo en el software.

¿Qué hacer entonces? Esperar y mientras tanto... estudiar Silverlight... ¡por si acaso!

Windows Mobile no ha muerto todavía

Microsoft va perdiendo la carrera de los sistemas operativos móviles e intenta dar un vuelco. Windows Phone 7 es, sin dudas, un salto radical en la interfaz y experiencia de uso pero... ¿Ha logrado desterrar al "viejo" Windows Mobile?

Con la llegada del publicitado Windows Phone 7 podría creerse a primera vista que el clásico Windows Mobile ha muerto. Desde el punto de vista del consumidor está claro: los teléfonos con Windows Phone 7 son más vistosos, y con aplicaciones, efectos gráficos y animaciones más acordes a estos tiempos marcados por la "tendencia iPhone". Además, el nombre ha cambiado de "Mobile" a "Phone" y, como colofón, el número parece decirlo todo: 7 es mayor que 6.5 (la última versión de Windows Mobile).

Incluso a los desarrolladores de .NET podría parecerles lo mismo (que Windows Mobile está destinado a perecer con inmediatez) pues ya no hay entorno de desarrollo, tanto de pago como gratuito, cuya última versión incluya soporte para desarrollar aplicaciones para Windows Mobile. El Visual Studio 2010, en sus versiones de pago, se ha separado del desarrollo móvil para ofrecer un IDE gratuito exclusivo para el desarrollo de aplicaciones para Windows Phone 7. Mientras, el SharpDevelop 4 incorpora el desarrollo de aplicaciones para Windows Phone 7, pero elimina el soporte para Windows Mobile.

De modo que si alguien quisiera hacer una aplicación para Windows Mobile, necesitará usar una versión desfasada: comprar una licencia de Visual Studio 2008 (si no la tiene), o aprovecharse de la gratuidad del SharpDevelop 3.2, lidiando con sus pequeños inconvenientes.

Entonces... ¿Ha muerto Windows Mobile? El cambio de nombre, la erradicación abrupta del soporte en las nuevas herramientas de desarrollo y la campaña de marketing que Microsoft está lanzando apuntan a que sí. Sin embargo, Windows Mobile no ha muerto y no lo hará de forma inmediata, y probablemente, ni siquiera a medio plazo.

La razón es muy simple: Windows Phone 7 está aún en pleno desarrollo, y aunque le han puesto muchas cosas que lo hacen más atractivo para el consumidor final, aún le faltan otras esenciales para quienes necesitan una plataforma donde implantar soluciones empresariales. La actual imposibilidad de acceder a Bluetooth desde aplicaciones de terceros, la incapacidad para controlar el acceso a redes WiFi, la imposibilidad de instalar aplicaciones por otra vía que no sea la tienda de aplicaciones y la actual incapacidad para ejecutar aplicaciones de terceros en background, descartan de lleno el Windows Phone 7 como plataforma para el desarrollo de software empresarial. Si una empresa cuyos desarrollos están basados en las tecnologías y herramientas de Microsoft y quiere hacer un sistema de recopilación de información que interactúa con sensores y periféricos por bluetooth o puerto serie; una aplicación de control de flotas que convive con otras aplicaciones en un mismo dispositivo; un sistema para la recopilación de datos in situ que sincroniza la información solo cuando está en presencia del punto de acceso WiFi adecuado... no podrá usar Windows Phone 7.

De modo que Windows Mobile se ha quedado viejo (ya lo estaba hace años) en lo que a interfaces de usuario se refiere y en eso, no hay dudas, Windows Phone 7 lo ha desplazado por completo. Sin embargo, Windows Phone 7 no da aún a los desarrolladores todas las funcionalidades de su predecesor, funcionalidades en algunos casos esenciales; por lo que aún, a pesar de las expectativas creadas, Windows Phone 7 no está listo para enterrar a Windows Mobile.

¿Cuándo lo hará? Es difícil saberlo. ¿Tal vez para finales del 2011? ¿En algún momento del 2012?

La cuestión es que Windows Phone 7 aún no es lo que el sector empresarial espera, por tanto: Windows Mobile no ha muerto todavía.

Primera publicación: por qué surgió este Blog

Hace unas semanas, durante una presentación casi histórica de un producto que llevaba años esperando ser visto, ocurrió algo "inesperado": falló una de las tantas cosa que podían fallar y no se probaron antes de la demo. Enseguida me vinieron a la mente las Leyes de Murphy y a la boca la frase a modo de justificación: "efecto demo". Pero lo cierto es que, si bien en ocasiones durante la demo de un producto suceden cosas imprevisibles, muchas de las veces que experimentamos el tristemente célebre "efecto demo", no se debe a factores absolutamente fuera de nuestro control, sino a pequeños elementos previsibles que, por un motivo u otro, no tuvimos en cuenta; y esta no fue la excepción.

Por eso, ese día, decidí crear este blog, para plasmar mis experiencias y las de los demás, y aprender de los errores y lo éxitos cuando, pasado un tiempo, vuelva a revivir los hechos releyéndolos, analizándolos y criticándolos. Así nació este blog: de un fallo durante una demo de un producto, que instó los deseos de reflexionar sobre buenas (y malas) prácticas en los procesos ingenieriles implicados en el desarrollo de software.

¡Comencemos!