domingo, 15 de marzo de 2009

De desktop a Web RIA

Cuando empece mi ultimo proyecto nunca pensé que iba a terminar haciéndolo como una aplicación web.  El sistema se parece a un cajero automático: es un PC, una impresora y una pantalla touchscreen instalados en un rack cerrado.  El usuario selecciona algunos datos, la aplicación se conecta a algunos sensores e imprime una etiqueta adhesiva con códigos de barra. 

Mi primera opción fue usar Java y la API Swing para crear una aplicación desktop convencional.  Alcance a desarrollar un prototipo inicial con Matisse de Netbeans y empece a actualizar mis conocimientos de Java2D para usar la impresora.  Mi única preocupación era hacer botones y labeles grandes para que el usuario los pueda seleccionar sin problema.  

Cuando llego el primer diseño de la interfaz al usuario, empece a cambiar de opinión.  Los botones no se parecen en nada a los de Swing, de Windows o de ningún sistema operativo conocido: sus bordes se mezclan poco a poco con el fondo de la pantalla en un efecto tipo anti-aliasing.  Al disparar un botón, ejecuta una animación que se parece a un destello de luz.  Pensé que iba a tener que crear mi propio renderer de Swing y eso me sonó como complicado.  

Además, habría tenido que ubicar los distintos elementos con una precisión de pixel porque el fondo no es de un solo color, sino una trama de grises oscuros: un pixel de error y se pierde el efecto de anti-aliasing.  O sea, tenia que decir chao a los layout de Java/AWT,  Eso me sonó como mucho trabajo.

Finalmente, un nuevo requerimiento funcional hacia muy probable la necesidad de recibir un archivo vía HTTP  Tenia que integrar un servidor web dentro de la aplicación desktop.

Entonces, surgió la posibilidad de hacerlo como una aplicación web.  Por el tipo de UI, era obvia la solución: una aplicación web RIA con javascript con jQuery en el browser y el soporte AJAX de Lift en el servidor.  


Comentarios

No lamente el cambio, porque pude solicitar la entrega del diseño UI en HTML, jpeg, GIF y CSS: el diseñador se llevo la tarea de colocar todo pixel a pixel.  Incluso, logre liberarme de Java2D para la impresión: en su reemplazo use la API Java iText y una plantilla PDF que me entrego el mismo diseñador de la UI.  Con eso pude imprimir a través del plug-in Adobe Reader en el browser en lugar de controlar yo mismo la impresión.

Cada vez me gusta más jQuery.  Recomiendo a los que quieren aprender Lift, aprender a usar bien jQuery (o Yahoo UI el otro framework javascript soportado por Lift).  De esta forma, es fácil prototipear en HTML, Javascript y luego pasar a código Scala/Lift en el servidor si es necesario.

Este proyecto me permitió profundizar el soporte AJAX de Lift, el cual es muy bueno.  El código quedó modular y re-utilizable: pude crear varios componentes de negocio, como una pre-visualización HTML de la impresión y un teclado numérico touchscreen, que re-utilice tal cual entre varias paginas.  Se que hacer lo mismo con Servlet/JSP, Struts, JSF es casi imposible.  Lift es realmente una mejora significativa.

También Scala salio muy bien.  El hecho de poder llamar directamente a las API's de Java y instalarse sobre cualquier servidor de aplicación Java es realmente una ventaja enorme sobre otros lenguajes.  Por ejemplo, pude usar Apache iText (para PDF), Apache POI (para Excel) y la API Socket de Java para conectarme con los sensores.  

3 comentarios:

Jorge.Rodriguez.Suarez dijo...

Hola Francois,

Le diste una mirada a Adobe Flex ?, creo que a partir de la version 4 se esta convirtiendo en una opcion valida a tener en cuenta.

Me gustaria saber tu opinion.

Saludos.

Francois dijo...

@Jorge:

No he usado Flex pero algunos colegas han hecho cosas bastante buenas con el. Flex es una buena alternativa para RIA sin lugar a duda.

Por mi parte, prefiero las soluciones estándares. Además, veo que Google y Apple están en el camino Javascript. Su participación en la guerra de los browsers con Chrome y Safari, se centra en hacer la ejecución de Javascript equivalente a Java o C. Eso esta presionando a MS y a Firefox.

Entonces, veo cada vez mejor futuro a Javascript y eso me frena dedicar tiempo a soluciones alternativas como Flex, Silverlight o JavaFX.

Saludos

Jorge.Rodriguez.Suarez dijo...

Tambien soy purista en ese aspecto, sigo prefiriendo JavaScript/Ajax/JSON

Ahora bien, mirando de forma pragmatica no se como te ha ido, pero yo gasto el 30% del tiempo de desarrollo compatibilizando mi javascript en IE 6/7, esto me ha hecho mirar a Flex con otros ojos.