Índice:

Offline first com React Native

Índice:

O que é Offline first?

A maioria dos aplicativos do mercado funciona acessando um banco de dados localizado em seus servidores e fornecendo os dados solicitados ao usuário.

Os aplicativos offline first, embora ainda exijam uma conexão com os servidores, não precisam de uma conexão constante à internet. Os dados dos servidores são baixados para o dispositivo do usuário e ainda podem ser acessados offline.

Um aplicativo offline primeiro fará o download das atualizações do servidor quando a conexão estiver disponível, enquanto carrega simultaneamente as alterações que o usuário fez enquanto estava offline no servidor.

Se o seu aplicativo demorar muito para iniciar devido à falta de conexão com o servidor ou mesmo se parar de funcionar repentinamente quando a conexão com o servidor for perdida, o usuário poderá ficar frustrado. Ao pensar primeiro no modo offline, o aplicativo se torna mais fluido em redes com baixa conexão que aplicativos comuns.

Todo list

O exemplo mais clássico no mundo da programação

Vamos supor que o nosso produto é um todo list. Com ele, o nosso cliente é capaz de fazer operações de incluir uma nova tarefa ou excluir uma existente. Apesar de simples o nosso aplicativo é muito eficiente em sua tarefa com uma pequena exceção: estamos reféns da conexão com o servidor.

O nosso app se conecta com API, recebe e envia dados. Como todo evento dispara uma requisição a uma API que pode se encontrar indisponível pela falta de rede, o usuário fica incapacitado de continuar. Quando falamos de um ambiente desktop, sempre conectado com a internet e com alimentação de energia constante, uma eventual desconexão temporária ou serviço lento não representa um grande problema. Já em aplicações web ou mobile, é de se esperar um certo nível de operações a serem realizadas mesmo offline.

A primeira operação é a listagem de todos que fica em branco quando estamos offline. Obviamente não é possível mostrar nenhum dado se não fizermos nenhuma conexão primária com o servidor. Porém, uma vez que o usuário baixou uma certa quantidade de dados, precisamos garantir que ele continue tendo acesso à esses dados mesmo offline. Como podemos fazer isso?

Cache e persistência de dados

Com cache, armazenando os dados em memória e persistindo quando offline.

O nosso app se conecta com API, recebe e envia dados. Vamos primeiro focar no recebimento de dados. O que precisamos fazer é colocar um cache, um lugar onde os dados baixados pelo aplicativo são salvos e podem retornar ao app. Supondo um estado inicial pra nossa API com duas tarefas e nenhuma salva na memória do aplicativo e no cache. Ainda online, o app recebe os todos do servidor e salva também no cache. Se a conexão com o servidor é perdida por algum motivo, o cache passa a alimentar o app.

Assim, tanto online quanto offline temos acesso a lista de tarefas pré-carregadas.

A próxima funcionalidade que vamos permitir ser utilizada no modo offline é a de adicionar uma nova atividade.

*Conexão lenta

Quando adicionamos uma nova atividade estando conectados, o app processa a requisição e mostra na lista como esperado. Já no modo offline, o debug acusa um erro de conexão com a network. Pra entender como alterar dados sem conexão com a internet, vamos primeiro analisar a forma como é feito online.

O nosso app se conecta com API, recebe e envia dados. Supondo a API inicia com uma atividade salva no banco, iniciamos salvando na memória do app esse todo. Quando queremos salvar um novo, nosso APP envia a informação pra API que salva no banco e rapidamente requisitamos a lista de todos que agora contém a nova atividade.

Optimistic UI

A solução pra isso é uma interface do usuário otimista.

Optimistic User Interface é um padrão para simular os resultados de uma mutação e atualizar a interface do usuário mesmo antes de receber uma resposta do servidor. Quando a resposta chega, o resultado otimista é descartado e substituído pelo resultado real. A UI otimista fornece uma maneira fácil de fazer com que a interface do usuário responda muito mais rapidamente, garantindo que os dados se tornem consistentes com a resposta real quando eles chegarem.

Voltando ao exemplo da API iniciando com um todo no banco, nosso app carrega na memória e a conexão é perdida. Dessa vez, quando queremos adicionar uma nova tarefa, salvamos na memória o que deve ser o resultado da operação depois de passar pra API. No exemplo salvamos a descrição de uma tarefa “New todo” que fica em um objeto com um ID. Como não sabemos qual ID virá da API geramos um valor aleatório e cruzamos os dedos pra que isso esteja certo. Quando a conexão é restabelecida, sem nosso usuário perceber, a informação é enviada pro servidor que processa colocando o ID correto e retorna pro APP que corrige na memória. Um erro que não afeta diretamente o usuário, então tudo dentro do esperado!

*Conexão lenta

Além de conseguirmos adicionar tarefas mesmo offline, existe um cenário onde ele se sai melhor do que o aplicativo sem a técnica do optmistic UI: quando a conexão está lenta ou o servidor demora muito pra processar a requisição.

Conclusão

Mesmo sabendo que a conectividade vem aumentando e melhorando de forma exponencial, vale a pena planejar o uso da sua aplicação em um cenário sem internet. Em um país com proporções continentais como o Brasil e com um percentual de 84% da população com telefone celular, é fundamental que a aplicação não se limite apenas a momentos em que o usuário esteja conectado, claro que isso não é possível em todas as aplicações.

Não podemos manter a construção de aplicativos com o mindset de desktop com conectividade rápida, em que uma desconexão temporária ou serviço lento é considerado como problema e comunicado como erro. As redes móveis simplesmente não fornecem o mesmo nível de qualidade e consistência, e é mais do que tempo de começarmos a nos adaptar a essa realidade.

Com react-native e Apollo GraphQL fica muito fácil desenvolver sempre apps offline-first. E é isso que eu vou mostrar em um vídeo no canal da ez.devs, então se inscreve lá e fica ligado no blog para mais conteúdos como este!

Confira também – Implementando Lottie a uma Aplicação React Native

Publicado por:
Compartilhe:

Posts relacionados

métrica developer experience

Entender e otimizar a developer experience é crucial para o sucesso de qualquer projeto de software. Uma experiência positiva pode impulsionar a produtividade e a satisfação da equipe, elementos chave

developer experience

A developer experience, ou DX, é um conceito cada vez mais importante no cenário de desenvolvimento de software. Mas por que a experiência do desenvolvedor é tão importante? Como ela

estimativa de software

Estimar software vai muito além de apenas chutar prazos. É sobre sincronizar de forma inteligente os esforços de desenvolvimento, garantindo que cada recurso seja usado onde realmente importa. Pensando nisso,