Offline Smart Device Apps, estado del arte con GeneXus y casos
•Als PPTX, PDF herunterladen•
0 gefällt mir•2,291 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie Offline Smart Device Apps, estado del arte con GeneXus y casos
Ähnlich wie Offline Smart Device Apps, estado del arte con GeneXus y casos (20)
Mehr von GeneXus
Mehr von GeneXus (20)
Offline Smart Device Apps, estado del arte con GeneXus y casos
- 1. Offline Smart Device Apps Estado del arte con GeneXus y casos Pablo Mazzilli Artech pmazzilli@genexus.com
- 2. Offline SD Apps • Aplicaciones desconectadas o parcialmente conectadas. • Lógica de procesos y base de datos local • Eventualmente conectadas • Ejemplos – Recolección de datos, Point of Sales – Catálogos, Programa de Eventos – Datos Personales
- 3. Offline Apps - Etapas • Pre-Carga • Acceso Info • Envío de Maestros • Registro Eventos al Eventos server • Eventos
- 4. Demo MASTERS CUSTOMER PRODUCT EVENTS ORDER
- 5. Registro Eventos • Pre-Carga • Acceso Info • Envío de Maestros • Registro Eventos al Eventos server • Eventos
- 6. Online vs Offline • Connectivity Support = Online | Offline | Inherit
- 7. Arquitectura Online Oracle, MSSQL , Mysql, Db2, etc Web Server • Procedures, Data Providers • Business Components KB Build Online HTTP - REST services (json) Device • UI : Layout, User Controls • Local Actions
- 9. Arquitectura Offline Web Server Device KB • UI : Layout, User Controls Build Offline • Local Actions • Procedures, Data Providers • Business Components SQLite
- 10. Carga de datos • Pre-Carga • Acceso Info • Envío de Maestros • Registro Eventos al Eventos server • Eventos
- 11. Carga de datos • New Object Synchronizer • Synchronizer.Receive • Hoy : Web Services – Expose as Web Service = True | REST – GET http://<server>/rest/GetProductos
- 12. Registro Eventos • Pre-Carga • Acceso Info • Envío de Maestros • Registro Eventos al Eventos server • Eventos
- 13. Envio de Eventos al Server • New Object Synchronizer • Synchronizer.Send Hoy • Enviarlos al servidor a través de Web Services. – POST http://<server>/rest/SetPedidos (SDT) • Recuperar los mensajes del servidor y actualizar el status
- 14. Resumen Para desarrollar una app offline hoy • Comenzar Online con X Evoluton 2 – Backend – Actualizar datos via BC – [Publicar Web Services ] • Tilo Offline (Beta) – Build Connectivity Support = offline – [Invocar Web Services + Proc de carga]
- 16. LBR Lácteos Brasil • 5 mil colaboradores • 56 mil proveedores • 2.000 millones de litros de leche / año • 4,4 millones de litros por dia (todos los dias) • 400 camiones
- 17. LBR Lácteos Brasil TRANSPORTADOR SAP - LBR MIDWARE PRODUCTOR
- 18. Conaprole (Uruguay) • App Fuerza Ventas – Pedidos Supermercados – Conexión con SAP via WS
- 19. Sancor (Argentina) • 1400 Productores Lecheros • App: Información gerencial para ejecutivos de cuentas – Saldos, Pagos, Vencimientos – +180 ejecutivos – 265 distribuidores, 45 clientes mayoristas, 1750 supermercados y 90.000 comercios minoristas atendidos
- 20. Infomodulus (Brasil) • App Fuerza de Ventas – 150 usuarios – +1200 Pedidos por día • Backend : Xev2 .Net / Oracle 11g + GAM
- 21. ¡GRACIAS! Café con Apps Online 17:15 Sala Torres García
Hinweis der Redaktion
- Permítanme hacer una breve introducción al tema para los que no estuvieron en la presentación anterior. Cuando hablamos de aplicaciones Offline, nos estamos refiriendo a aplicaciones que se ejecutan en dispositivos inteligentes y que puedan funcionar (acceder y/o almacenar información) sin necesidad de tener conexión a internet, es decir de forma desconectada o parcialmente conectada.A nivel mas tecnico, toda la logica de procesos y la base de datos tiene que estar local en el dispositivo. Esto no invalida a las aplicaciones online, las cuales siguen teniendo sus grandes ventajas. Seguramente la gran mayoria de las apps van a seguir siendo online, por la facilidad de conectividad que se tiene en muchos lugares y la posibilidad entonces de acceder siempre a información actualizada.Esto es un complemento a ese tipo de aplicaciones, o en algunos escenarios, es directamente parte de la solución, por problemas de conectividad, costo de contratar planes de datos, sobre todo si estoy en otro Pais, etc. Algunos escenarios donde este tipo de solución es mas evidente:Recolección de datos: Encuestas, Datos de ProduccionPoint of Sales, como fue mencionada en la presentacion anterior. Catalogo de Productos, Programa de un evento.Apps para guardar informacion personal.
- Podemos pensar en una app Offline, al menos en el escenario más completo, como una app con 3 etapas bien diferenciadas: Pre-carga de datos, Registros de datos locales, envio de datos al servidor. La frecuencia en que se van a ejecutar esos pasos, sobre todo el primero y ultimo dependerá de la conectividad y de la necesidad de tener sincronizados los datos locales con el servidor.Precarga de datos Maestros. Esto puede ser a demanda, por ejemplo para actualizar los clientes a visitar o los precios de los productos, o automática al detectar conectividad y acceder a los productos. Tambienpodria venir ya pre-cargada con la aplicación, como seria el caso de un catalogo o una grilla de programas, para los casos donde no hay actualización de info, al menos para una misma versión de la app.El segundo punto es el uso de la aplicación en sí, lo que ya estamos haciendo hoy con las apps Online. Quizas la diferencia aquí con respecto a una app Online es que no vamos registrar los datos Maestros, para que estos siempre vengan del servidor. El ultimo punto es la posibilidad de enviar al servidor esos datos que estan siendo actualizados localmente y obtener el feedback de si los registros fueron actualizados y cuales son fueron los errores en caso contrario.
- Les quiero mostrar ahora una aplicación offline desarrollada con GX, que si bien en sencilla, resuelve uno de los escenarios mas completos (3 etapas).
- Bien, como vimos en la demo, podemos resolver completamente una app offline hoy con Android y venimos avanzando bien con iOS. Veamos ahora que fue lo que hice para que esta aplicación funcione sin conectividad?Como mencionábamos hay básicamente 3 etapas en las apps offline. Voy a comenzar por la parte del medio que se refiere al desarrollo de la aplicación offline y luego vemos la parte de sincronizacion.Qué tengo que hacer para poder acceder y registrar datos en forma local ? Como desarrollador GX, no tengo que hacer nada diferente a lo que estaba haciendo hoy (con xev2) para desarrollar una app online. Veamos que es lo que hace GX al respecto.
- Lo que tenemos en la version Tilo es una nueva propiedad para los objetos SD, llamada ConnectivitySupport.Para los objetos que son Main, por ejemplo un Dashboard, la propiedad tiene dos valores Online | Offline. A los objetos SD no main, se le agrega una tercer opción : Inherit. Esto determina como se ejecutara la aplicación invocada por ese main.El valor Online es el comportamiento que tienen actualmente las apps desarrolladas con la Xev2. Veamos que es lo que hace GX cuando generamos una aplicación online…
- Cuando hacemos el build deuna app Online, se generan : El paquete que va a ser instalado en el propio dispositivo, que incluye una metadata con toda la info de las pantallas, mas código nativo para manejar los eventos y acciones locales; aquellas que interactúan con las funcionalidades propias del dispositivo, como ser la cámara, GPS, acelerómetro, agenda, etc. Pero además :Creacion de la base de datos en el servidor remoto o la nube. Generacion de todos los servicios necesarios para la app interactuar con la base de datos y ejecutar procesos. Esto incluye la generación de Procedures, Data Providers y BC (muchos de ellos invisibles para el usuario por ser generados a traves del pattern WWSD) y que son ejecutados a través de servicios REST , intercambiando mensajes JSON. Nota: Para mas detalle sobre la arquitectura de una app Online, ver presentación de Arquitectura por Luis Murillo:http://www.genexus.com/encuentro2012/xxii-encuentro-genexus--conferencia?es,0,,2837
- Si cambiamos el valor de la propiedad al valor Offline, al momento de ejecutar nuestra aplicación ahora vamos a ver que se invoca otro generador.
- Todo los programas que ese main accede y que antes se generaban con el generador web (java, .net o Ruby) ahora automaticamente pasan a ser generadores con el lenguaje de la plataforma del dispositivo, Java para Android, Objective-c para iOS, etc.La base de datos será creada localmente en el SQLite del dispositivo. Es decir, ya tenemos nuestra app offline , y todo sin necesidad de cambiar los programas, ni la forma de acceder a los datos. Observar las combinaciones interesantes que se pueden dar entre diferentes programas y arquitecturas, sin conocer nada de ellas: podria tener parte de mi app online , cuyos servicios esten generados en .net, pero el resto de la aplicación local, para el caso de Android, sera Java.
- Hasta podemos decir entonces que para desarrollar una app offline no difiere de lo que ya conocemos para hacerlo Online. Que nos falta ? La parte de sincronizacion de datos entre el dispositivo y el servidor.
- Como nos contaba Gustavo en la presentacion anterior, para la carga de datos estamos trabajando en un nuevo objeto, que resuelve la carga de información de una forma inteligente. EL objeto Synchronizer detectar cuales son los datos necesarios basado en la especificación del Mainobject. A partir de eso, mas los posibles filtros que el usuario pueda agregar, se generan todos los procesos de carga y los servicios necesarios para poder ser invocar desde el device. Ademas optimiza la creacion de base de datos en el dispositivo, para incluir solo las columnas necesarias para cada tabla.Se esta trabajando en ese nuevo objeto, pero esto no impide que hoy por ejemplo podamos resolver esto de una forma un poco mas manual, a traves del uso de web services desarrollados con GX, lo que es muy sencillo.
- Este proceso consiste en enviar al servidor la información que ha sido almacenada o actualizada en forma local.
- Proceso automático para replicar al server las mismas actualizaciones que se realizaron localmente a través de BC.Al igual que el caso anterior, trabajando en la automatización de ese proceso. Esto es, enviar todas las actualizaciones que se realizan localmente , a traves de BC y replicar esa secuencia de cambios en el servidor. Esto incluirá la posibilidad de obtener los eventuales errores al ejecutar esa secuencia en el servidor.De cualquier forma, al igual que el caso de la Carga inicial de datos, esto hoy se puede resolver a traves del uso de Web Services.
- LBR Empresa privada de productos lácteos mas grande de Brasil, unión de las empresas Bom Gosto y LeitBomSituación actual:Manual en todas las etapas: captación, entrega y controlesDificil de controlarVolumenes importantes 4,4 millones de litros por dia (todos los dias)400 camionesSospechas de desviosPuntos de colecta sin señal telefonicoGrandes distancias (en algunos casos hasta 400 kms.)Idea inicial:Comprar software prontoAnálise de costos: Aproximadamente US$ 160.000,00 (Licencias de uso e implantación)Aproximadamente US$ 2.500,00 mensual (mantenimiento)Precisa de customizacionesDecisión:Software propioTecnologia Smart Devices (Android)Datos almacenados en el dispositivo para posterior descargaImpresión de comprobante para el ProductorRegistro de visitas y respectivo control (Latitud y Longitud)
- Caso : volumen de info y complejidad.Carga de DatosSAPEnvia para Midware: Rutas, datos productores, datos transportadorasMIDWAREEnvia para Dispositivo: Colecta (ruta, fecha, productor, camion)Envio de Eventos:DISPOSITIVOCaptura de datos de la colectaCaptura coordenadas geograficasMIDWARERecibe Colecta y hace conferenciaSAPRecibe Colecta y sigue para proceso industrial
- Caso: mas con menosUnos pocos vendedores (6) resuelven el mayor porcentaje de ventas de productos, ya que son los que recorren las grande superficies (supermercados) en Uruguay. Realizando mas de 500 pedidos mensuales.
- Sancor – caso 80/20Cooperativa Argentina que nuclea a 1400 productores Lecheros. 4.000.000 de litros diarios de leche procesados16 Complejos Industriales Más de 100 productos diferentes7 Sucursales de Ventas 10 Oficinas Comerciales265 distribuidores, 45 clientes mayoristas, 1750 supermercados y 90.000 comercios minoristas atendidos.La aplicación permite a los ejecutivos de cuentas (180) descargarse los datos de los saldos de los clientes, toda la definición de pagos de dichos clientes, cuanto se les vence en los proximos días, por ejemplo dice mañana que saldo se les vence, pasado, en 5 días, en 10 días y en 15 días.
- Arco Sistemas tiene desarrollado con la version Xev2 una app Online (Android) que permitir la captura en sitio mediante Smart devices de la información de recogida de producción de leche (en más de 600 tambos), generando, por impresora bluetooth, el ticket de recibido para el productor y posteriormente en planta mediante la misma impresora generando la impresión de la relación de recogidas en la ruta.Problemas a resolver: Disponibilidad offline dada la poca o nula cobertura de señal celular en algunos puntos de recogida. Disminución de costos asociados a planes de datos (3g)Hoy esta siendo homologada la version offline desarrollada con GX TiloDatos técnicos: Backend: GeneXusEvX2 U1. Generador .Net. Base de datos: MSSQL 2008R2Dispostivos:Android 2.2Para la impresión y configuración de la mac de la impresora bluetooth del dispositivoandroid, se creo un externalobject.
- Caso: Conversionrapida.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 .netmobile. 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.De los 150 usuarios que utilizar la app, 110 ya estan con una solucionAndroid desarrollada con la X Evolution 2. El resto aun mantiene la solucionmobile por trabajar en areas de poca cobertura. En esta semana fue realizar la version offline en Android de la aplicación, lo que llevó un total de 35 horas, con la versionalpha de GX.