Aplicaciones Offline para Smart Devices: Visión General

Editor's Notes

• #3: Offline definition: Not under the control of a central computer Not connected to a computer or computer network. Si miramos la definición de Offline, se refiere a poder operar en forma totalmente independiente a un sistema central. Cuando pensamos en una App Offline, es eso lo que precisamos? Puede una app hoy estar totalmente desconectada ? Veamos algunos ejemplos
• #4: Esto son 3 ejemplos de app que apuntan a actividades o perfiles de usuarios bien diferenciados: La primera es Pesobook, una app de las que denominamos “Consumer App”, es decir, para cualquier usuario del mundo. La segunda es la app del Evento, es decir, para una Comunidad especifica. La tercera es una app para Fuerza de Ventas, es decir, los usuarios en este caso son los vendedores de una empresa particular. Esto es lo que en gral se denomina Business Apps. Que tienen en común, además del hecho de haber sido creadas con GX ? Las 3 van sobre datos centralizados …
• #5: Trabajar con datos centralizados tiene muchas ventajas, algunas destecadas:
• #9: … pero además, tener los datos centralizados permite: dar valor agregado a las app, dando info sobre los eventos registrados (directa o inderectamente) por otros usuarios de esa misma app (mi peso respecto al promedio) que ante actualizaciones del contenido, pueda acceder rapidamente a ello (desde el sistema de retaguardia de la app del evento, se agrega / elimina alguna presentación, cambio de horario, etc). Si no estuviesen los datos centralizados, no podriamos tener esta app disponible para el evento, porque se publico una semana antes y los datos se fueron alterando, incluso en el propio evento. La app la uso en varios devices, y los favoritos que voy marcando quiero verlos en cualquiera de ellos. en el caso de la app de FV, esa app en sí parte de un sistema corp. El pedido que el vendedor ingresa ,termina generando un orden de produccion, una factura, etc, es decir esta integrado a un sistema mas general.
• #10: El problema de trabajar con datos centralizados, es la conectividad, que si no disponemos de ella, puede limitarnos en su funcionalidad. Y en algunos escenarios es un factor importante. Ahí surge el tema de que nuestra apps continúen funcionando en ambientes de conectividad limitada o nula. . Poder registrar mi peso en el momento que me lo tomo. . Poder acceder a la agenda del evento, sabiendo que no tengo 3g o wifi en el momento. . Para el caso de FV, mas que una opción, es una necesidad. Si no tengo conectividad, podría no vender…
• #11: El objetivo entonces es que cualquier App pueda funcionar simpre independientemente de la conectividad Aplicaciones que en general tienen conexión, pero que tienen que seguir prestando sus funcionalidades principales antes la pérdida de esta. Ahora, tenemos que re-hacer esas Apps para que funcionen offline, o pensar diferente ? Esta pregunta la responderemos al final… Veamos ahora los requerimientos de una app offline
• #12: Esta es una imagem de al gente de la Fundacion SEADE (Sistema Estadual de Analisis de Dados) de Brasil ( http://www.seade.gov.br/ ) Recopilando info sobre Empleo a través de una app SD en la zona metropolitana de Sao Paulo. Muestra lo importante de : Poder usar la app sin conectividad Necesidad de enviar los datos al sistema centralizado ni bien exista conexión (ante la eventualidad de pérdida o robo del dispositivo). Se paga por visitas.
• #13: La solucion es hacer la app totalmente desconectada? Por lo que vimos antes, no es una opcion. Aplicaciones que en general tienen conexión, pero que tienen que seguir prestando sus funcionalidades principales antes la pérdida de esta. Ahora, tenemos que re-hacer esas Apps para que funcionen offline, o pensar diferente ? Esta pregunta la responderemos al final… Veamos ahora los requerimientos de una app offline
• #15: Es el caso del vendedor ambulante que debe tomar pedidos a sus clientes en distintos lugares con un  SD . En algunos puede tener conectividad y en otros no. Lo que requiere este escenario es que en el caso de no tener conectividad igual se pueda tomar el pedido (aunque sea de forma temporaria * ) para luego mandarlo de forma definitiva. Este escenario comprende todas las actividades que deben recabar datos desde un SD en áreas de poca conectividad. Ejemplos: un hospital, datos sobre enfermedades en el domicilio de los pacientes, obteniendo datos en la calle, en el campo, o similar. Los datos recabados son procesados luego, en una base de datos centralizada. De forma abstracta podemos decir que este escenario consiste en poder registrar un  Evento  (un pedido, un registro medico, etc.) que necesita consultar una serie de datos relacionados al mismo (Clientes, Productos, etc), que llamaremos de datos  Maestros  y realizar una serie de calculos (total del pedido) y ejecutar reglas (no se puede pasar el limite de credito). A su vez el registro del Evento puede alterar los datos Maestros (el stock de un Producto).
• #16: Tener ya cargados los datos Maestros antes de entrar en modo desconectado. Poder registrar el Evento cuando el aparato esta desconectado en modo 'temporario' pero realizando todos los calculos y controles del caso conectado. Poder enviar todos los Eventos registrados en modo temporario cuando se tenga conexion (volviendo obviamente a ejecutar todas los calculos y controles que se realizaron en forma temporal anteriormente). En el caso que se rechazo el Evento (porque las reglas fallaron) tener algun mecanismo para poder modificarlo/cancelarlo. El momento cuando se realiza esta operacion puede ser automatica (cuando se recupera la conexión) o manual (el usuario decide cuando hacerlo) Es importante que en el momento de enviar los Eventos al server estos se puedan enviar en el mismo orden cronologico en el que fueron digitados. Un problema a resolver es que pasa si cuando se envian los datos al server algun valor del Evento cambia (por ejemplo cambia el total del Pedido).  Poder visualizar los Eventos que estan en modo temporario.
• #18: Cuando esta propiedad toma el valor Offline, en el prox Run suceden, en forma automática, varias cosas: Se generan los programas para crear la base de datos en el device (SQLite). Ahora, no preciso toda la base de datos, sino un subconjunto de ésta. Ese subconjunto se puede determinar automaticamente, en base a los programas que ese main accede. Se generan esos programas (Proc, data providers, BC ) en forma nativa, porque ahora tienen que ejecutar en el dispositivo (Java , Objective-c). A partir de este cambio, ese main y sus llamados que hereden la propiedad Offline van a ir siempre sobre la base de datos local. Por ultimo, se generan automaticamente los procedimientos de sincronización, tanto para obtener los datos maestros del servidor al device, como para enviar los eventos que se registran locales del device al server. Todo esto es transparente para el desarrollador GX. Relacionado con el ultimo punto, tienen algunas opciones:
• #19: A nivel de arquitectura, si hacemos un comparativo entre online y offline, vemos que en offline, todos los data providers , procs, BC ya no se acceden a través de una capa de servicios REST, sino que se general locales, en el lenguaje nativo.
• #21: Indicar cual es el criterio para obtener los datos Maestros, si queremos que sea automática, en ese caso, basta indicar el intervalo de tiempo en que queremos que se haga la sync. Y si queremos Sync por registro, es decir, solo vienen los cambios realizados en el server, o por tabla, es decir, se borra todo y se insertan nuevamente los datos. En cualquiera de estos dos casos, la Sync solo se realiza si en la tabla hubo cambios.
• #22: Aquí se indica en que momento quiero enviar las modificaciones realizadas locales, siempre que exista conexión o definida por el usuario.
• #23: App autónoma , independiente de la conectividad, con mecanismos de sincronización generados automáticamente , respecto a un sistema central, y ejecutados en forma desatendida.
• #27: Caso: Conversion rapida. La empresa Infomodulus de Brasil ha desarrolloado un sistema general para fuerza de Ventas. Esta en produccion desde hace un par de años, desarrollo iniciado con el generador .net mobile. Actualmente todo el backend de la aplicación esta en GX X Evolution 2 , generado para .net con Oracle y la seguridad a través del GAM. Los 160 usuarios ya estan con la solucion Android desarrollada con la X Evolution 2. El desarrollo de la primer version offline en Android de la aplicación que entro en produccion en setiembre, llevó un total de 35 horas, con la version alpha de GX.
• #28: App del Metro para el DF (Mexico) con info sobre lineas de tren. 170.000 descargas ! Esta offline para iOS.
• #29: - de 15/12/2012 a 30/03/2013 foram enviados 14256 pedidos e 16934 conexões com nosso servidor; - o usuário adaptou-se rapidamente a nova ferramenta; - o usuário tem a percepção que está trabalhando, praticamente, online, devido ao uso dos webservices; - a aplicação se demonstrou estável, tendo um baixo nível de chamados; A Catarinense é distribuidora exclusiva dos Sorvetes Nestlé para o Estado de Santa Catarina, sendo que nosso pico de vendas é de 15/dez ao Carnaval, ou seja, exatamente o período em que nossa aplicação foi implantada. Acho interessante ressaltar, que começamos a utilizar o Genexus há 2 anos somente.
• #30: SEADE (Fundacao Sistema Estadual de Analisis de Dados) de Brasil ( http://www.seade.gov.br/ ) junto con el apoyo de Fornax, estan desarrollando una app Offline de Encuestas, para recopilar info sobre Empleo en la zona metropolitana de Sao Paulo. Es una app que va sobre servicios existentes. No tiene middleware. Se conecta a los servicios directamente desde la app offline.
• #31: Nuevamente, escenarios bien diferentes, pero aplicando soluciones inteligentes y automáticas, para que Uds pueden poner foco en su negocio, y hacer la diferencia. Muchas gracias!