Aplicativo de campo offline: como registrar o atendimento onde não há sinal

Há uma cena que se repete em quase toda operação com equipe externa. O técnico chega ao local, executa o serviço, abre o aplicativo para registrar e a tela trava em "carregando". Ele espera, tenta de novo, desiste e anota no papel. À noite, alguém digita aquilo em uma planilha, sem foto, sem horário real e sem a coordenada de onde o atendimento aconteceu. O trabalho foi feito, mas o registro que sustenta a medição, a auditoria e o indicador simplesmente não existe.

Operar offline não é um detalhe técnico do fornecedor de software. É uma decisão de gestão sobre o que a operação aceita perder quando a rede falha. Este texto trata do tema pelo ângulo de quem gerencia a equipe: o que precisa continuar funcionando sem sinal, quais escolhas o sistema faz por você e o que verificar antes de contratar ou implantar.

Onde o sinal falha, e por que isso não é exceção

A conectividade brasileira melhorou muito, mas continua desigual no território, e é exatamente no território que a equipe de campo trabalha. A Agência Nacional de Telecomunicações mantém o Índice Brasileiro de Conectividade (IBC), que ranqueia os 5.570 municípios e as unidades da federação em uma escala de 0 a 100. O desenho do índice já diz bastante sobre o problema: entre as dimensões que ele combina estão a densidade de acessos móveis, a cobertura móvel da população em tecnologia 4G ou superior, a densidade de estações rádio-base e a cobertura móvel das áreas agricultáveis. Em outras palavras, o próprio regulador mede cobertura como algo que varia de município para município e de área para área dentro do mesmo município.

Do lado do uso, a pesquisa TIC Domicílios 2025, do Cetic.br/NIC.br, registrou 87% dos domicílios urbanos com acesso à internet contra 81% dos domicílios rurais. É um indicador de domicílio, não de cobertura em via pública, e por isso serve como sinal de contexto, não como medida do que a equipe encontra na rua. Ainda assim, aponta na mesma direção: a diferença entre o Brasil urbano e o rural não desapareceu.

E há um ponto que nenhum índice captura: boa parte das falhas de conexão em campo não vem da ausência de cobertura no município, e sim do local específico do atendimento. Subsolo de edifício, casa de máquinas, galpão com estrutura metálica, poço de elevador, túnel, área de mata, interior de indústria. O mapa de cobertura da operadora pode estar correto e o técnico continuar sem sinal onde ele precisa trabalhar.

Os três níveis de "funciona offline"

Fornecedores diferentes usam a mesma palavra para coisas bem distintas. Vale separar em três níveis, em ordem crescente de esforço e de proteção.

Nível 1: leitura offline

O aplicativo guarda o que já foi carregado e permite consultar sem rede: a lista de ordens do dia, o endereço, o histórico do cliente, o manual do equipamento. Qualquer ação que altere dados exige conexão. Resolve o caso de quem só precisa olhar a próxima visita, mas não protege o registro do atendimento.

Nível 2: escrita em fila

O técnico consegue preencher e concluir o atendimento sem rede. O registro entra em uma fila local e é enviado quando a conexão volta. É o nível que resolve o problema de gestão descrito no início deste texto, e é onde a maioria das operações precisa chegar.

Nível 3: offline como padrão

O aplicativo trata o armazenamento local como fonte principal e a rede como um segundo canal que atualiza esse armazenamento em segundo plano. A documentação de arquitetura do Android chama esse padrão de offline-first e o define como o aplicativo capaz de executar toda ou uma parte crítica da sua funcionalidade principal sem acesso à internet. A tela nunca espera a rede: ela lê do banco local e reage quando o dado muda.

As quatro decisões que definem o comportamento do aplicativo

Estas escolhas são técnicas, mas cada uma tem uma consequência direta na rotina da equipe. O gestor não precisa implementá-las; precisa saber qual foi adotada, porque é ele quem vai explicar o resultado quando algo der errado.

1. Qual é a fonte da verdade

Ou o aplicativo lê direto do servidor e usa o armazenamento local como cópia de apoio, ou trata o banco local como referência e sincroniza com o servidor depois. A documentação do Android é explícita ao recomendar, para aplicativos offline-first, que a fonte local seja a fonte da verdade da tela, com a rede fornecendo o estado mais recente. A diferença aparece na percepção do usuário: no primeiro caso a lista "some" quando o sinal cai; no segundo, ela continua lá.

2. Como as escritas são tratadas

A mesma documentação separa três estratégias de escrita: somente online, em que a operação falha se não houver rede e é adequada a transações que não podem ficar pendentes; escrita em fila, em que a ação entra em uma fila e é drenada quando a conexão volta; e escrita preguiçosa, em que o dado é gravado localmente primeiro e o envio ao servidor acontece em seguida. Para conclusão de ordem de serviço em campo, as duas últimas são as que fazem sentido.

3. Como a sincronização é disparada

Existem dois modelos básicos. Na sincronização sob demanda, o aplicativo busca os dados quando o usuário abre a tela: simples de implementar, mas exige sinal naquele instante. Na sincronização proativa, o servidor avisa que houve mudança e o aparelho se atualiza antes de precisar: consome menos dados e permite operar mais tempo desconectado, ao custo de um controle de versões mais complexo. Na web, esse disparo automático é padronizado pela Background Synchronization API, que executa a tarefa pendente assim que o dispositivo tiver conectividade de rede, mesmo com a aba fechada, segundo a documentação da MDN.

4. Como o conflito é resolvido

Se o mesmo registro foi alterado no aparelho e no servidor, alguém tem que perder. A estratégia mais difundida é a chamada última escrita vence, em que cada dispositivo anexa um carimbo de tempo e o servidor descarta a versão mais antiga. É simples e automática, mas descarta trabalho sem avisar ninguém. Em operações com valor contratual ou evidência regulatória, costuma valer mais bloquear a ordem de serviço para um único executor e mandar o conflito para revisão humana do que aceitar o descarte silencioso.

O que muda no registro de evidências

Quando o dado nasce sem rede, três itens do registro merecem atenção especial, porque são justamente os que sustentam a comprovação do serviço.

• Horário: o carimbo de tempo passa a vir do relógio do aparelho, que o usuário pode alterar. Registrar os dois horários, o de execução informado pelo dispositivo e o de recebimento no servidor, resolve a maior parte das dúvidas e evita discussão sobre cumprimento de prazo. É o mesmo raciocínio que sustenta o cálculo de SLA e disponibilidade.
• Localização: o receptor de GPS não depende de conexão de dados para calcular a posição, mas o mapa não carrega, o endereço não é resolvido e o posicionamento assistido por rede fica indisponível, o que tende a aumentar o tempo até a primeira leitura e a piorar a precisão. Guardar a coordenada bruta com a precisão estimada e converter em endereço depois da sincronização é mais confiável do que exigir o endereço na hora.
• Fotos e anexos: são o que mais ocupa espaço e o que mais falha no envio. Comprimir no aparelho, enviar em partes e permitir que o restante do registro seja aceito enquanto as imagens ainda sobem evita que uma foto de 8 MB segure a conclusão de uma ordem inteira.

Vale lembrar que o aparelho passa a guardar dados pessoais por algum tempo, e isso entra no escopo do tratamento previsto na legislação. Baixar apenas as ordens do período, limpar o armazenamento local depois da confirmação de envio e exigir autenticação no aplicativo são medidas simples e coerentes com o que discutimos no artigo sobre LGPD no registro de dados em campo.

Cinco verificações antes de implantar

1. Medir a frequência real da falta de sinal

Antes de pedir orçamento, levante em quantos atendimentos do último trimestre houve registro feito fora do local ou fora do horário. Se o sistema atual não permite esse levantamento, uma semana de anotação manual pela própria equipe já dá ordem de grandeza suficiente para dimensionar o problema.

2. Definir o que é essencial offline

Nem tudo precisa funcionar sem rede. Listar as três ou quatro ações que não podem falhar, tipicamente abrir a ordem, preencher o formulário, anexar evidência e concluir, evita um projeto inflado que tenta replicar o sistema inteiro no aparelho.

3. Testar no pior cenário, não no escritório

Teste com o aparelho em modo avião, com o sinal oscilando e com a bateria baixa. O caso mais traiçoeiro não é a ausência de rede: é a conexão ruim, em que o aplicativo acredita estar online e fica tentando enviar até esgotar o tempo. Simule também o aparelho ficando sem espaço, situação comum em celulares de equipe com muitas fotos.

4. Tornar a pendência visível para as duas pontas

O técnico precisa ver quantos registros ainda não subiram, e o gestor precisa ver quais ordens estão concluídas no campo mas não recebidas no servidor. Pendência invisível vira retrabalho na conciliação do fim do mês.

5. Definir a regra de conflito e a de expiração

Decida antecipadamente o que acontece se um registro ficar dias sem sincronizar e se a mesma ordem for alterada em dois lugares. Ter a regra escrita antes evita que ela seja inventada sob pressão, no meio de uma auditoria.

Indicadores para acompanhar depois da implantação

Operação offline cria um conjunto novo de números que antes não existia. Quatro deles costumam bastar:

• Proporção de registros criados offline: mostra o tamanho real do problema e ajuda a mapear as regiões e os tipos de serviço mais afetados.
• Tempo médio entre execução e sincronização: quanto tempo o dado fica preso no aparelho. Valores altos indicam que a equipe está passando o dia inteiro fora de cobertura ou que a fila não está drenando.
• Taxa de falha de envio: registros que precisaram de mais de uma tentativa ou de intervenção manual. É o indicador que antecipa perda de dado.
• Conflitos por período: quantos registros chegaram divergentes. Se o número não é zero e ninguém sabia disso, alguma informação já foi descartada em silêncio.

Nenhum desses números aparece em uma planilha preenchida no fim do dia. Eles dependem de um aplicativo que marque a origem de cada registro e de um servidor que guarde o histórico completo da sincronização, tema que se conecta ao que tratamos no guia de gestão de ordens de serviço e equipes em campo e às decisões de integração entre sistemas da operação.

Erros comuns

• Tratar offline como recurso opcional a ser ativado depois: a decisão sobre fonte da verdade e fila de escrita molda o aplicativo inteiro. Adaptar depois costuma custar mais do que nascer assim.
• Confiar apenas no horário do aparelho: sem o horário de recebimento no servidor, não há como distinguir registro atrasado de relógio ajustado.
• Deixar a fila invisível: o técnico acha que enviou, o gestor acha que não foi feito, e a conversa acontece três semanas depois.
• Baixar a base inteira no aparelho: além do consumo de espaço e bateria, amplia desnecessariamente a exposição de dados pessoais.
• Aceitar "funciona offline" sem perguntar qual nível: leitura offline e escrita em fila resolvem problemas completamente diferentes.