Manejando las redes como un señor

Notas del editor

• #5: Javi me decía, vamos a poner tu charla en el track 1. Y yo le respondía que no, porque es una charla para los más cafeteros. Así que aviso.
• #6: La razón porque estoy haciendo está charla, es porque en el último año
• #7: Estoy desarrollando una aplicación móvil especializada en sistemas MES (Manufacturing execution system)
• #8: Fliparíais como parte de esas plantas llegan a ser pseudo jaulas de Faraday, para proteger la producción lo máximo posible.
• #9: Cuando tenemos conexión al servidor esto es estupendo
• #10: Pero va a ser más común tener este escenario.
• #11: ¿Qué podemos hacer para gestionar este escenario correctamente?
• #12: Debemos tener una correcta gestión de la conectividad y que está sea lo más transparente posible para el usuario
• #13: Para que sea transparente para el usuario, debemos tener una cache fuerte y que nos permita almacenar todos estos datos
• #14: Debemos saber como tener una lógica para la gestión del offline dentro de nuestra aplicación. Ahora veremos estos tres puntos con detenimiento
• #16: ¿Primero me gustaría preguntaros como gestionais la conectividad en vuestras aplicaciones?
• #17: Muchos de vosotros pensareis tengo Xamarin Essentials, con eso tengo suficiente.
• #18: Así es como gestiona la conectividad Xamarin Essentials en iOS y es muy similar en otras plataformas. Te digo que el usuiario está conectado, si este tiene una red activa ya sea Wifi o Internet
• #19: Pero esto no nos vale para nuestro escenario previo. Que ocurre si tengo conexión de internet, pero el servidor es local o no es accesible desde 4G
• #20: Además ocurre otra situación. Existen redes publicas que si no estás conectado a la misma, tu API te va a decir que tiene conectividad, pero cuando haces peticiones si el usuario no ha hecho login sobre este tipo de redes wifi, la respuesta que vas a recibir A tus llamadas de API es el HTML de login de estas páginas.
• #21: Para añadir una mayor seguridad de conocer si hay o no conexión lo mejor es realizar una petición de PING, una petición de conectividad básica
• #22: Pero esto generaba un nuevo problema, antes de poder hacer una petición al servidor, se debía verificar si el servidor respondía con su correspondiente Timeout mínimo esperado, con lo que la respuesta se ralentizaba
• #23: Como podíamos evitar que el usuario no tuviese que esperar
• #24: Hemos creado un servicio que trabaja por detrás que realiza por nosotros este. Ping para tener la respuesta en el momento, además que hemos conseguido que el sistema sea más reactivo, porque no esperamos que el usuario haga una peticióin al servidor para verificar si tiene o no tiene conexión.
• #26: El usuario está conectado al wifi, la aplicación ya sabe si debe responder online u offline a la respuesta y llegar al servidor local
• #27: Entonces todo funciona perfectamente.
• #28: Pues no…
• #29: Estamos obteniendo datos en los cuales comprobamos que los usuarios están conectados con el sistema casi todo el tiempo, en ocasiones todo el tiempo, pero seguimos recibiendo peticiones con respuesta de Timeout
• #30: Que pensamos que está ocurriiendo. El usuario en la planta se encuentra conectado a un punto wifi y realiza una petición.
• #31: Este durante el tiempo que llega o no llega la petición y espera la respuesta por parte del servidor, se conecta a otro punto de acceso y por lo tanto se pierde la primera petición.
• #32: Estamos desarrollando ahora mismo obtener información de los puntos de acceso que tiene los usuarios cerca, para ser más inteligentes a la hora de decidir de manera más eficiente si podemos o no, lanzar las peticiones online u offline.
• #34: ¿Que es mejor para gestionar nuestra cache? SQLite? Akavache? Un Json?
• #35: ¿Que es mejor para gestionar nuestra cache? SQLite? Akavache? Un Json?
• #36: ¿Que es mejor para gestionar nuestra cache? SQLite? Akavache? Un Json?
• #37: ¿Que es mejor para gestionar nuestra cache? SQLite? Akavache? Un Json?
• #38: ¿Que es mejor para gestionar nuestra cache? SQLite? Akavache? Un Json?
• #39: ¿Que es mejor para gestionar nuestra cache? SQLite? Akavache? Un Json?
• #40: ¿Que es mejor para gestionar nuestra cache? SQLite? Akavache? Un Json?
• #41: Para obterner la respuesta, podeis revisitar una charla que di, hace unos años también en la Monkey donde se analiza detenidamente cada uno de los métodos como almacenar nuestros datos localmente. Aunque tiene un par de años, todos los métodos Siguen siendo funcionales y estables.
• #42: Como bien sabemos todos, los programadores tenemos dos problemas principales: Nombrar las cosas y cuando invalidar la cache. ¿Entonces como resolver el segundo problema inteligentemente?
• #43: Crea una capa de abstracción sobre tu cache, para tener diferentes caducidades sobre diferentes entidades
• #44: Crea estrategias en tu backend de obtener lo último actualizado
• #45: Crea procesos que te permitan comodamente cargar información en tu cache al arranque y puedas estrategicamente saber que cargar.
• #47: Volvamos a recordar nuestro escenario de conectividad. El usuario está conectado al wifi, la aplicación ya sabe si debe responder online u offline a la respuesta y llegar al servidor local
• #48: Como y de que uso deben tener todas nuestras partes de la aplicación que sepan o no sepan si el sistema es offline.
• #49: Los viewmodels deben conocer si es offline o no. Pero lo más razonable es que este conocimiento solo fuese necesario para la lógica de la vista o para gestionar puntos concretos de ese ViewModel. Nunca deben ser los responsables de dar conocimiento a otros fragmentos de nuestra aplicación.
• #51: Todo nuestro servicio web, debe saber como operar con la petición, pero el retorno debe ser idéntico y toda la gestión debe quedarse dentro de nuestra API para el webservice.
• #53: Los servicios interesados de nuestra aplicación que quieran conocer si hay o no hay conexión, deberían saberlo.
• #54: Para resolver el problema de conectividad tanto para ViewModels, como para los servicios se debe crear una interfaz, que implemente los puntos mínimos de ejecución online u offline y el estado en el quue se encueuntra.
• #55: Denrtro del servicio de conectividad, informaremos a todos los interesados (todos los que hayan implementado la interfaz) haciendolo responsables. Vamos, un evento de dominio.
• #58: Volvamos a nuestra api de web service. Cualquier parte de nuestro código llama a esta API
• #59: Esta inspecciona si tenemos o no conexión.
• #60: Si estamos online, resolvemos con el servidor y ya estaría.
• #61: Si no, respondemos contra nuestra cache dentro de todo lo que sea posible.
• #62: Además debemos tener dos acciones una: responder contra la cache, siempre teniendo como referencia nuestro endpoint. Otra ejecutar un proceso offline de sincronización.
• #63: Como se sincroniza posteriormente. Usando el método FIFO pero con ciertos Peros
• #64: Si existen operaciones relacionadas entre ellas que se ejecuten en un bloque. Por ejemplo si pido crear una entidad que está se ejecuta offline y luego se opera con la misma entidad, todas esas operaciones irán linkadas a la tarea de sincronización de la primera tarea.
• #65: Antes de ejecutar las tareas de siincronización tenemos un sistema de reglas que nos permita mover el orden de las tareas o poder verificar si hay tareas que pueda generar conflictos a la hora de sincronizarse.
• #66: Antes de ejecutar las tareas de siincronización tenemos un sistema de reglas que nos permita mover el orden de las tareas o poder verificar si hay tareas que pueda generar conflictos a la hora de sincronizarse.
• #78: He dedicido no hacer ejemplos de código hablando de esto, porque al final es un trabajo extra que al final cae en saco roto, en la mayoría de los casos. Si necesitais ayuda al respecto no dudeis en contactar conmigo para que pueda echaros un cable, que no muerdo.