Aplicaciones offline para Smart Devices
•Transferir como PPTX, PDF•
0 gostou•1,087 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Aplicaciones offline para Smart Devices
Semelhante a Aplicaciones offline para Smart Devices (20)
Mais de GeneXus
Mais de GeneXus (20)
Aplicaciones offline para Smart Devices
- 1. Offline Applications for Smart Devices Gustavo Proto gp@genexus.com, Artech
- 4. Agenda • What – The scenarios • How – The model • When – Implementation plan
- 5. Scenarios
- 6. Point of sales Scenarios I
- 7. The concept Scenarios Master Sync Masters Customer Product Customer Product Order Company Order Deposit Country City Route Event Sync Area Event
- 8. Cook book Scenarios II
- 9. Bank transaction Scenarios III
- 10. The model
- 11. The concept The model Connectivity Support: Offline Data Synchronization Criteria Master Sync Main SD Customer Product Customer Product Order Company Order Deposit Country City Route Event Sync Area Local changes processing
- 12. The concept - recap The model • Main property • Connectivity Support property – Online – Offline • Data Synchronization criteria – At application startup – User defined • Local changes processing – When connected – User defined
- 13. Synchronizer The model • New object • One for each Offline Main SD • Automatically created/maintained • User conditions • User code
- 14. Synchronizer parts The model
- 15. Synchronization API The model • .Receive • .Send • .Backup • .Restore
- 16. Constraints The model • Events are Business Components • Master sync is one-way • Events are always recorded off-line, then synced • Offline database always created
- 18. Platforms Plan • Android Alfa test in several customers • iOS Under development
- 19. Functionality Plan • Create SD Database Done. • Master Synchronization Under development. • Event synchronization Starting soon
- 20. What’s next? • Attend • Offline Smart Device Apps, estado del arte con GeneXus y casos • Café con Offline Smart Device Apps • Start development now with GeneXus X Evolution 2 • Stay tuned for Genexus Tilo alpha testing
- 21. Thank you Gustavo Proto gp@genexus.com
Notas do Editor
- Estaría bueno que Offline fuera desconectarse, en algún lugar paradisíaco como el de la foto. Lejos de las ocupaciones y preocupaciones. O como dijo un ex cuñado mientras descansábamos en una salida de pesca: esto sí que vida, mi única preocupación es que creo que el vino no va a ser suficiente para la noche!La mala noticia es que vamos a hablar de aplicaciones que pueden evitar que, a pesar de estar en un lugar como el de la foto, quedemos totalmente desconectados.La buena noticia es que estaremos hablando de aplicaciones que podrían ser, como desarrolladores, nuestro Boardingpass a un lugar como el de la foto :-).Yendo al punto, la mayoría de las aplicaciones que estamos acostumbrados a desarrollar, Web, Window, etc. necesitan una conexión permanente a la base de datos central, al “server”. Si no la tienen, no pueden operar.Existen, y no es algo nuevo, aplicaciones que deben funcionar aún cuando la conexión con el server no esté disponible y eventualmente sincronizarse (intercambiar actualizaciones) con éste cuando la conexión se recupere. Estas aplicaciones surgen por la necesidad de dar un servicio o llegar lo más cerca posible al punto donde están los datos y la ausencia, calidad o costo de la conexión en ese punto.Una aplicación Offline entonces es la que funciona aún cuando la conexión con el server no esta disponible y, que es capaz de re sincronizarse, si lo necesita, luego de una pérdida de conectividad.
- La presentación está centrada en tres puntos:El qué vamos a resolverEsta parte la presentaremos en función de los escenarios que hemos identificadoEl cómo vamos a resolverloDentro del equipo de desarrollo solemos presentar las soluciones en forma de modelos así que presentaremos el modelo aplicado a esta soluciónCuándo tendremos qué funcionalidadEstaremos dando un estimativo del plan de implementación
- Es el caso del vendedor ambulante que debe tomar pedidos a sus clientes en distintos lugares. 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 para luego mandarlo al server de forma definitiva.Este escenario comprende todas las actividades donde se recaban datos desde un SD en áreas de conectividad limitada o nula. 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 cálculos (total del pedido) y ejecutar reglas (no se puede pasar el limite de crédito).A su vez el registro del Evento puede alterar los datos Maestros (el stock de un Producto).Qué necesitamos?Cargar los datos Maestros antes de entrar en modo desconectado.Registrar el Evento estando sin conexión, realizando cálculos y controlesDisponer de un mecanismo para ver los eventos registrados sin conexiónEnviar los Eventos registrados estando sin conexión cuando ésta vuelva (o cuando sea requerido)En el orden estricto en que fueron ingresadosEjecutando nuevamente los cálculos y controles que se realizaron cuando se registró sin conexión.Disponiendo de un mecanismo de manejo de los rechazosPuntos a considerar:NumeradoresReferencias a los numeradoresCambios en valores de los campos (cambio el total del pedido)
- Lavariación de este escenario con el de Punto de ventas radica en la necesidad/posibilidad de incluir datos en el deploy de la aplicación ya que esto mejorará la UX en la primera ejecución de la aplicación. Los usuarios están acostumbrados a necesitar una conexión y esperar durante el proceso de instalación. No así durante la primera ejecución.Dentro de este escenario se incluyen los casos de aplicaciones como la del Encuentro de Usuarios GeneXus y Vademécums donde las actualizaciones desde el server son escasas o nulas (las actualizaciones se distribuyen como nuevas versiones). También dentro de este ejemplo estamos incluyendo aquellas aplicaciones como la de Registro de gastos personales, totalmente Offline).Este es un caso extremo: los datos deben ser distribuidos con la instalación y nunca serán actualizados. La actualización de los datos se hará con nuevas versiones de la aplicación.Esto comprende aplicaciones como Vademécum, Registro de gastos personales y cualquier otra que _no_ requiera actualizar o compartir sus datos.
- Para este tercer escenario hemos elegido como escenario una transacción bancaria que, por definición, debe ser Online. Al terminar la transacción satisfactoriamente las cuentas involucradas deben quedar actualizadas en el server. Sin embargo, se quiere que los Maestros (números de cuenta, monedas, límites de las transacciones, etc.), estén Offline (en el dispositivo) con el objetivo de agilizar la preparación de la transacción (selección de cuentas, moneda, validaciones básicas).Otra aplicación que entra en este escenario es la de pago de bienes o servicios y cualquier otra en la que se requiera que al momento de finalizar el evento la información se encuentre actualizada centralmente.
- Repasemos los conceptos vistos anteriormente para identificar qué funcionalidades necesitamos.Las aplicaciones SD forman normalmente parte de una aplicación empresarial de mucho mayor porte. Lo primero que debemos identificar entonces es cuál es el subconjunto de tablas y atributos que participan de la aplicación SD. Para ello sólo definimos cuál es el punto de entrada de nuestra aplicación: definimos cuál es el Main SD. Con ello GeneXus identificará qué tablas y atributos son necesarios para ejecutar dicha aplicación.El siguiente paso es declarar que la aplicación queremos que sea Offline. Para ello se agrega la propiedad Connectivity Support con valores Online y Offline.GeneXus sabe entonces que deberá crear las tablas accedidas por el main en el dispositivo y con los atributos necesarios. Igualmente sabe que muchos de los servicios se deben generar con el SD y no con el MainGenerator.Por último, necesitaremos indicar con qué criterio sincronizaremos los eventos que se generen estando sin conexión mediante la propiedad Local changesprocessing.
- Una “aplicación” SD es el conjunto de objetos llamados por un objeto Main para SD. A estos objetos se le agrega la propiedad “Connectivity Support” con valores Online y Offline.El valor Online produce aplicaciones como las que hoy (GeneXus Evolution 2) tenemos, donde todos los datos están en el server.El valor Offline habilita el uso de la aplicación fuera de línea.También se agrega la propiedad Data Synchronizationcriteria que especifica en qué momento se sincronizará la información de los maestros.Por último, la propiedad “Local changesprocessing” especifica el criterio por el cual los cambios en el SD serán transmitidos al server.
- Cómo se especifica qué registros de las tablas de la aplicación SD? Para esto tendremos un nuevo objeto denominado Synchronizer. Básicamente representa la base de datos del dispositivo.