Aplicacaciones offline para Smart Devices
•Als PPT, PDF herunterladen•
0 gefällt mir•611 views
Aplicacaciones offline para Smart Devices
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (7)
Ähnlich wie Aplicacaciones offline para Smart Devices
Ähnlich wie Aplicacaciones offline para Smart Devices (20)
Mehr von GeneXus
Mehr von GeneXus (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Aplicacaciones offline para Smart Devices
- 1. #GX3175 Smart Device Offline Apps Overview Pablo Mazzilli @PabloMazzilli pmazzili@genexus.com
- 2. #GX3175 OFFLINE = ¿NOT CONNECTED?
- 3. #GX23
- 4. #GX3175 Centralized Data • Cross-Device Apps • Security • Real Time Information • Value Added Info • Full Integrated Systems
- 5. #GX3175
- 6. #GX3175
- 7. #GX3175
- 9. #GX3175 OFFLINE = NOT CONNECTED+ SYNCHRONIZED
- 10. #GX3175
- 11. The Model
- 13. #GX3175 • Centralized Data Base • REST Services Sync Programs (.net, java , ruby) • Local Data Base • Load Master Data • Events Records without connection (Android, Objetive-c) • Events Sync when connected • Events status Offline App - Requirements
- 14. Solution
- 15. #GX3175 Main Object SD Property Connectivity Support: - Online (default) - Offline
- 16. #GX3175 Online Offline BLBL Business Level Business Level Services Level Services LevelApp UIApp UI SyncSync Business Level Business Level App UIApp UI
- 18. #GX3175 Receive Data Synchronization Criteria - Automatic - Manual Data Synchronization Granularity - By Row - By Table
- 19. #GX3175 Send Local Changes Processing - When connected -User defined (Send Method) Events are Business Components!
- 20. #GX3175 Offline App Definition An autonomous application (not connection aware), with automatically generated Sync programas, and executed unattended.
- 22. #GX3175 Offline Status - Tilo • Beta 1 • Offline DB and SD Programs • Master Data sync (one way) • Beta 2 • Events sync (iOs and Android) • Security – GAM • API Events Status
- 23. Cases
- 24. #GX3175 From .NET Mobile to Android Sales Force App 160 users 2000 orders p/day 11.500 customers BackEnd : Xev2 .Net / Oracle 11g + GAM
- 25. #GX3175 Metro DF
- 26. #GX3175 ¡ GRACIAS ! THANKS! o Next - Mobile sales force using Android tablets and integration with SAP o 10:30 – Offline: Architecture and development with GeneXus o 11:00 –Advanced Concepts in Offline Applications pmazzilli@genexus.com @PabloMazzilli
Hinweis der Redaktion
- 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
- 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 …
- Trabajar con datos centralizados tiene muchas ventajas, algunas destecadas: Cross Device Seguridad … pero además, tener los datos centralizados permite…
- … que ante actualizaciones del contenido, se pueda acceder rápidamente a la misma (ej: desde el sistema de backoffice de la app del evento, se agrega / elimina alguna presentación, cambio de horario, etc). Es más, de no tener los datos centralizados, no podriamos tener esta app disponible para el evento, porque se publicó varias semanas antes y los datos se fueron alterando, incluso durante el propio evento. El comportamiento de la app fue cambiando a medida que pasaban los dias, según los datos. Por ejemplo, los dias previos al evento se mostraba una lista preliminar de charlas; durante el evento se mostraba el grid de charlas por dia, y las charlas en curso. Etc. Además, puedo marcar presentaciones favoritas, y ver esa lista desde diferentes devices o mismo desde el web.
- Otra ventaja es el valor agregado que le podemos dar a las apps, algo muy comun en las Consumer Apps, aportando info sobre los eventos registrados (directa o indirectamente) por otros usuarios de esa misma app (Ej: mi peso respecto al promedio) Aquí entran temas como Gamification, Social networking, etc.
- Y en el caso de la app de Fuerza de Ventas? Esa app es 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 más general.
- Ahora, 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…
- 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
- 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.
- 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).
- 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.
- 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:
- 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.
- 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.
- Aquí se indica en que momento quiero enviar las modificaciones realizadas locales, siempre que exista conexión o definida por el usuario.
- 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.
- 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.
- App del Metro para el DF (Mexico) con info sobre lineas de tren. 170.000 descargas ! Esta offline para iOS.
- - 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.
- 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.
- 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!