App offline: preserve a tarefa quando a conexão falha

O desafio de app offline

O aplicativo pode mostrar uma tela mesmo sem conseguir concluir a operação. Essa diferença aparece quando um vendedor registra um pedido em um local sem sinal e acredita que ele já chegou à empresa. Projetar o modo offline exige distinguir informação disponível no aparelho, alteração pendente e confirmação recebida pelo servidor.

Como organizar dados locais

Selecione quais tarefas precisam continuar sem rede e quais dependem de informação atualizada. A arquitetura offline-first descrita pelo Android considera uma fonte local para leitura. Na operação, a interface também precisa revelar a idade dos dados e o estado de cada alteração.

1. Separe consultas locais de ações que exigem confirmação imediata do servidor.
2. Crie estados visíveis para rascunho, envio pendente, sincronização e falha recuperável.
3. Teste perda de sinal antes, durante e depois da transmissão de uma alteração.

A informação de pendência precisa existir onde a pessoa toma decisões. Uma faixa genérica de sem conexão não revela quais relatórios estão salvos ou quais anexos faltam transmitir. Mostre o estado do item e permita consultar a fila. Se o aparelho tiver pouco espaço, explique a falha ao salvar localmente antes de permitir que a pessoa interprete a tarefa como preservada. Ausência de rede e ausência de armazenamento são situações distintas.

Exemplo aplicado: sincronização mobile

Exemplo hipotético: um técnico preenche um relatório em uma instalação com sinal irregular. O app salva o texto e as fotos localmente, informa que o envio está pendente e permite continuar. Ao recuperar a conexão, transmite os anexos e só apresenta o relatório como recebido após a confirmação do serviço.

O técnico não precisa interpretar um ícone abstrato para saber se pode encerrar a visita. A mensagem distingue o trabalho preservado no aparelho da entrega efetivamente concluída.

O ensaio deve começar antes da primeira consulta. Um aparelho que nunca abriu determinado relatório talvez não possua sua cópia local. Defina o que deve ser preparado enquanto existe rede e como a pessoa reconhece esse conteúdo como disponível. No caso das fotos, registre quais arquivos pertencem ao relatório e se o envio parcial pode ser retomado sem reenviar tudo. A fila deve sobreviver às interrupções previstas no produto.

Critérios para fila de envio

Disponibilize offline o que tem utilidade com dados possivelmente antigos. Bloqueie ou confirme novamente decisões cuja validade depende do estado atual, como disputar o último horário de uma agenda.

Ocultar a falha com uma mensagem de sucesso cria confiança indevida. Também é arriscado limpar a fila ao sair da conta sem explicar que há registros ainda não transmitidos.

Considere a validade do trabalho offline ao voltar para a rede. O relatório pode ter sido alterado por outra pessoa ou a ordem pode ter sido cancelada. A sincronização precisa responder a esses casos sem descartar silenciosamente o conteúdo produzido em campo. Quando a operação exigir uma decisão humana, mantenha a alteração pendente e mostre a divergência com opções compreensíveis. A capacidade de trabalhar sem conexão inclui conseguir reconciliar o resultado posteriormente.

Acompanhamento de conexão instável

Observe quantidade e idade dos itens pendentes, falhas por tipo de conexão e alterações perdidas. Diferencie envio atrasado de erro definitivo para evitar intervenções desnecessárias da equipe de suporte.

Escolha uma tarefa crítica e execute um ensaio completo em modo avião, incluindo encerramento do app e retomada, antes de declarar o fluxo disponível offline.