Cual es el problema? Que es lo que desearíamos?Supongamos que un cliente ingresa a mi sitio.Luego en algún momento ocurre un evento en el servidor que modifica datos. Por lo tanto el cliente a partir de ese momento está viendo una vista desactualizada de los datos. Nos gustaría que nuestros clientes sean notificados inmediatamente de este suceso. Por lo tanto, que es lo que necesitamos?Necesitamos poder invertir el diálogo entre la aplicación y el cliente. Y así poder notificar directamente al cliente sobre los cambios sucedidos.
El primer ejemplo de este escenario que se nos vino a la mente fue una aplicación de seguimiento de flotas.En donde tenemos un mapa con la ubicación de cada flota y sería deseable que la ubicación de cada unidad se refresque de manera inmediata sin interacción del usuario. Nos gustaría que la información se actualice automáticamente. La información se actualice cuando realmente hay información nueva,
Este ejemplo fue sacado de un sistema real.Supongamos una aplicación para reservar entradas en un cine. En uno de los pasos quiero reservar mis asientos.Estoy viendo las butacas de cuando ingresé a la página. Desearía que la disponibilidad de los asientos sea presentada en tiempo real y que no ocurriera que el asiento que elijo al final de la transacción no esté más disponible en caso que me demore un tiempo en elegir y que justo otro usuario elija el mismo que yo.
También hay ejemplos claros que usan esta funcionalidad como por ejemplo sitio de noticias.El muro de Facebook o el Chat son típicos casos donde se utilizan estos mecanismos de notificaciones en tiempo real para mejorar la experiencia del usuario. En DropBox también hay una fuerte utilización de este tipo de técnicas. En fin, hay muchos otros ejemplos en la web que usamos cotidianamente lo que nos demuestra que este requerimiento que se ha transformado en una necesidad y no en un lujo.
Estoymostrandounaimagen deuna app real de reserva de habitaciones de hoteles.Porejemplocuandoyoingresé, me parecióinteresanteque en un momentodesps de algunossegundos me apareció un mensajediciendo “Atencion” miraque hay más de 10 personas mirandoestahabitación. Luego “ miraque solo quedan 2 habitaciones”. Esdecir me ibanotificandoinmediatamentelasactualizaciones de estahabitación. Esto no tengodudas de quesirvecomoestímuloparaque los clienteshagansusreservasmásrápidamente. Y es un ejemplo de estetipo de escenario en dondequierodispararalgúnevento en el cliente a partir de algúneventoqueocurrió.
Otro ejemplo claro que hoy no podemos resolver con GX de forma nativa es la notificación de progreso de una tarea.Es decir, poder disparar una tarea, que no tranque la UI y que además me vaya notificando el % de progreso de la misma. Esta funcionalidad parece imprescindible para muchas aplicaciones que se desarrollan en la actualidad. En fin, son muchos los usos que le podemos dar. La mala noticia es que hoy es complicado de resolver estos escenarios.La buen noticia es que GeneXus Tilo, resolver esto será muy sencillo.
Para ver como vamos a implementar esta nueva funcionalidad, es necesario entender como fueron evolucionando las tecnologías en lo en lo que se refiere a la comunicación navegador/servidor. Ya que el problema en cuestión básicamente radicaba en que no teníamos forma de comunicarnos directamente con el cliente. Veamos entonces en que etapa estamos y hacia donde vamos. En la primer etapa se refrescaba totalmente la pantalla en cada acción. Si bien funciona bien, la experiencia de usuario no era la mejor. Luego en el año 2005 se introdujo la AJAX lo que nos permitió mejorar enormemente la experiencia de usuario al no tener que recargar toda la página ante una acción del usuario. Luego vino Comet (long polling) quepermitemantenerunaconexiónpermanente con el servidor. Si bienresuelve el problema, consideramos que es una especie de WorkAround que preferimos de evitar por ahora. (offtopic)La diferencia que existe entre AJAX y Comet es que en este modelo se mantiene una conexión abierta entre el cliente y el servidor web; el cliente no solicita los datos, pero si envía información al servidor, y el servidor no le responde al cliente con un bloque de datos, se espera a que haya algún evento de lado del servidor para enviar la información.We see that WebSocket is a bit simpler than XMLHttpRequest but it amplifies the problem created with the asynchronous mode: data are received at any time unrelated to the order in which is made the request to the server. The user has to bring order in what he receives.Websocket connections have significantly less overhead than traditional XmlHttp based connections, because they are not stateless, meaning, you’re not sending the same header information every single time you need to retrieve data.
Haciadondevamos?Nosdirigimosentonces a soportarestosescenarios a partir del Uso de HTML5 WebSockets.En GeneXusTiloutilizaremosestatecnologíapara resolver los requerimientos.
Con GX queremos que puedan empezar a resolver estos tipos de escenarios, creando aplicaciones mucho más interactivas, teniendo como objetivo mejorar radicalmente la experiencia del usuario. Y lo más importante de todo, brindarles a ustedes una solución simple de usar y apoyada en lo último en tecnología que es donde queremos estar.