Uma equipe registra uma visita, perde o sinal e descobre depois que o formulário não foi salvo. A solução não é apenas mostrar uma mensagem “sem internet”. Para operar offline, o sistema precisa decidir quais dados ficam no dispositivo, quais ações podem acontecer sem confirmação central e como resolver conflitos quando a conexão voltar.
Operação offline é um modelo de consistência e recuperação, não um recurso visual isolado. Ela pode ser valiosa para serviços externos, inspeções e inventários, mas precisa de limites compatíveis com os riscos do processo.
1. Classifique as ações por risco
Consultar instruções previamente baixadas é diferente de confirmar estoque ou conceder um desconto. Defina ações permitidas, provisórias e proibidas sem conexão. A interface deve indicar quando o registro existe apenas no dispositivo e quando foi aceito pelo servidor.
Não prometa confirmação de uma disponibilidade que depende de outros usuários conectados. Uma reserva pode ser registrada como solicitação pendente, mas a confirmação exige a regra central. A política precisa ser compreendida pela operação antes do desenvolvimento.
| Ação | Possível comportamento offline | Controle necessário |
|---|---|---|
| Ler manual | Usar cópia local | Versão e validade |
| Preencher visita | Salvar rascunho | Recuperação local |
| Capturar foto | Enfileirar envio | Limite de armazenamento |
| Reservar recurso | Solicitar confirmação posterior | Aviso de pendência |
| Alterar dado compartilhado | Criar mudança candidata | Resolução de conflito |
2. Separe cache de dados de trabalho
Guardar arquivos da interface não significa que os formulários estão protegidos. Distinga recursos da aplicação, dados consultados e alterações ainda não sincronizadas. Cada grupo tem retenção, atualização e sensibilidade diferentes.
O guia de operação offline e em segundo plano da MDN apresenta mecanismos da plataforma web. O suporte varia por navegador e ambiente. Não faça a correção depender exclusivamente de uma tarefa em segundo plano: ofereça sincronização quando a aplicação estiver aberta e recuperação de pendências.
3. Use uma fila local explícita
Cada operação pendente deve ter identificador estável, tipo, objeto, versão de origem e estado. Preserve a intenção em vez de guardar apenas a tela final. Assim fica mais fácil explicar se o usuário criou uma visita, anexou uma foto ou alterou um endereço.
Mantenha estados como local, em envio, confirmado e conflito. Se o envio falhar depois de o servidor executar, repita com proteção idempotente. Não gere outro identificador para a mesma intenção. O manual de webhooks e idempotência aborda a prevenção de efeitos repetidos.
4. Planeje conflitos por domínio
“A última alteração vence” é simples, mas pode apagar trabalho legítimo. Para observações independentes, anexar entradas pode ser adequado. Para um campo de endereço, talvez seja necessária revisão. Para quantidade de estoque, a regra pode exigir movimentos, não substituição do saldo.
Use versão ou revisão para detectar se o objeto mudou no servidor desde o download. Quando houver conflito, apresente os valores e a origem, com autorização para decidir. O sistema deve evitar que uma resolução local sobrescreva mudanças de outra equipe sem aviso.
5. Trate anexos separadamente
Fotos e documentos podem consumir espaço e banda muito maiores que formulários. Use limites de tamanho, compressão apropriada e envio retomável quando necessário. Mostre o estado de cada anexo: um formulário sincronizado com uma imagem ainda pendente não deve parecer totalmente concluído.
Cuide das relações. Se o cadastro da visita ainda não foi confirmado, o envio do anexo precisa conseguir vinculá-lo depois. Defina o que acontece quando o usuário remove um anexo durante o envio ou quando a conexão cai no último bloco.
6. Proteja dispositivos e sessões
Dados locais podem permanecer em equipamentos compartilhados ou perdidos. Reduza o conjunto armazenado, limite a duração e implemente saída com tratamento das pendências. O usuário deve saber se sair apagará um trabalho não sincronizado.
Revogação de acesso exige política: um dispositivo desconectado não recebe imediatamente a decisão do servidor. Para dados ou ações críticos, limite o período de operação sem validação online. Criptografia e autenticação devem ser avaliadas conforme o ambiente; não são substituídas por esconder telas.
7. Exemplo hipotético de uma inspeção
Um técnico baixa ordens autorizadas antes de sair. Durante a visita, preenche um formulário e captura três fotos. A tela mostra “salvo neste dispositivo”. Ao recuperar conexão, o formulário é aceito e duas fotos são enviadas; a terceira continua pendente por falha.
O painel central deve representar esse estado parcial. Se a ordem foi cancelada enquanto o técnico estava sem sinal, o servidor aplica a política definida: recusar a conclusão, aceitar como registro histórico ou solicitar revisão. Não existe uma resposta universal; existe uma decisão de negócio que deve ser implementada.
8. Teste além de desligar o Wi-Fi
Simule conexão lenta, intermitente e que permite abrir uma página, mas não alcançar a API. Teste fechamento da aba, reinício do dispositivo, sessão expirada e falta de espaço. Verifique também atualização da aplicação enquanto existem registros locais em uma versão anterior.
Métricas úteis incluem idade das pendências, conflitos, falhas de upload e registros recuperados. Uma baixa taxa de erro no servidor pode esconder centenas de operações que nunca saíram dos dispositivos. A observação precisa cobrir os dois lados.
Checklist de projeto
- Ações offline classificadas por risco.
- Dados baixados limitados ao usuário e à finalidade.
- Rascunhos e fila local recuperáveis.
- Identificadores idempotentes preservados.
- Política de conflito definida por entidade.
- Anexos com estado e recuperação próprios.
- Sessão, revogação e saída planejadas.
- Testes com perda realista de conectividade.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre responsáveis, verificações e observações da implantação.
Perguntas frequentes
Uma PWA sempre funciona offline?
Não. A arquitetura precisa implementar e validar essa capacidade para as jornadas específicas.
Tudo pode ser confirmado sem internet?
Não. Operações que dependem de disponibilidade central ou autorização atual podem precisar permanecer pendentes.
Sincronização pode ocorrer em silêncio?
Pode, quando suportada e segura, mas pendências e conflitos relevantes devem ficar visíveis ao usuário.
Para desenhar uma operação de campo resiliente, fale com a A2CR.
Autoria: Agência A2CR. Revisão editorial: 9 de novembro de 2026. Exemplo hipotético e recomendações de arquitetura elaborados pela A2CR.
