Trabalho offline em campo: como a equipe opera sem sinal e sincroniza depois

Existe uma cena que se repete em praticamente todo projeto de campo. Na homologação, dentro do escritório, o aplicativo funciona: o mapa carrega, o formulário abre, a foto sobe. Na primeira semana de operação real, chega o chamado. "O sistema não abre a ordem de serviço no sítio." Não é bug. É o aplicativo pedindo dado a um servidor que, naquele ponto, não existe.

A resposta comum é otimizar a chamada, reduzir o tamanho da resposta, aumentar o timeout. Nada disso resolve, porque o problema não é de desempenho: é de premissa. Um sistema que precisa da rede no instante da execução transfere para o técnico um risco que ele não controla. Este guia trata do desenho alternativo, aquele em que a rede é conveniência e não requisito.

Offline tem níveis, e quase ninguém combina qual

Antes de discutir tecnologia, vale alinhar vocabulário. "Funciona offline" costuma significar quatro coisas diferentes, com custos de implementação muito distintos.

A escolha do nível é uma decisão de negócio, não de tecnologia. Uma equipe de inspeção urbana com boa cobertura talvez viva bem no nível 2. Uma equipe de manutenção de rede em área rural precisa do nível 3 no primeiro dia. Levantamento cadastral com várias frentes editando o mesmo acervo exige o nível 4, e aí o projeto muda de porte. Se o seu ponto de partida é anterior a isso, o ciclo completo da ordem de serviço está detalhado no nosso guia de field service.

O pacote que sai com a equipe

Operar no nível 3 começa por uma pergunta simples: o que exatamente vai embarcado no dispositivo? Na prática, quatro coisas.

• Mapa base. Recorte da área do dia em tiles, com os níveis de zoom que a equipe realmente usa. Não é o Brasil inteiro, é o município ou o setor.
• Dado operacional. Ativos, lotes, trechos de rede, pontos de coleta. Só o subconjunto pertinente, com os atributos que o formulário consulta.
• Regras. Listas de domínio, obrigatoriedade de campo, validação, formulários e seus condicionais. Regra que só existe no servidor não protege ninguém em campo.
• Fila de saída. A estrutura onde ficam os registros produzidos até que a sincronização confirme o recebimento.

O quarto item é o mais esquecido e o mais importante. Sem uma fila explícita, com estado por registro, o aplicativo não sabe dizer o que já subiu e o que não subiu. É essa incerteza, e não a falta de sinal, que faz a operação perder confiança na ferramenta.

GeoPackage: o contêiner que viaja

Do lado geoespacial, existe um formato pensado exatamente para esse cenário. A OGC define o GeoPackage como "um formato aberto, baseado em padrões, independente de plataforma, portátil, autodescritivo e compacto para transferir informação geoespacial". Na prática, o arquivo é um banco SQLite: a própria OGC registra que "um GeoPackage é o contêiner SQLite, e o GeoPackage Encoding Standard governa as regras e requisitos do conteúdo armazenado em um contêiner GeoPackage".

O padrão cobre armazenamento de feições vetoriais e de "conjuntos de matrizes de tiles de imagens e mapas raster em várias escalas", o que significa que mapa base e dado operacional cabem no mesmo arquivo. Dois pontos da especificação explicam por que ele virou o formato natural de campo:

• Uso direto, sem conversão. A OGC destaca que os dados podem ser "acessados e atualizados em formato de armazenamento nativo, sem traduções de formato intermediárias". Menos etapas entre o servidor e o dispositivo significa menos lugares onde o dado se perde.
• Feito para conectividade ruim. A descrição oficial diz que o formato é "particularmente útil em dispositivos móveis como celulares e tablets em ambientes de comunicação onde há conectividade e banda limitadas".

Vale registrar o contraste com os padrões de serviço web. WMS, WFS e OGC API - Features são excelentes para consumir dado ao vivo, mas todos pressupõem um servidor alcançável. É a diferença que tratamos no guia de padrões OGC: no escritório você consome geoserviço, em campo você carrega contêiner.

Como o QGIS prepara um projeto offline

Quem já trabalha com QGIS tem esse fluxo pronto no software, sem plugin de terceiros. A documentação oficial descreve o Offline Editing Plugin como um recurso que "automatiza a sincronização copiando o conteúdo da fonte de dados para um banco de dados SpatiaLite ou GeoPackage e armazenando as edições offline em tabelas dedicadas". A sequência documentada é direta:

1. Abrir um projeto com camadas vetoriais, que podem vir de shapefile, PostgreSQL ou de uma fonte WFS-T.
2. Ir em Database, Offline Editing, Convert to offline project.
3. Escolher o tipo de armazenamento: "pode ser do tipo banco de dados GeoPackage ou SpatiaLite".
4. Na seção de camadas remotas, marcar as camadas que devem ser salvas.
5. Salvar o projeto, levar para campo, editar sem rede.
6. Na volta, aplicar as mudanças com Database, Offline Editing, Synchronize.

Há uma opção pequena com efeito grande, também documentada: "sincronizar apenas as feições selecionadas se houver uma seleção presente, permitindo salvar e trabalhar somente sobre um subconjunto". É o mecanismo que evita levar o acervo inteiro quando a frente do dia cobre três quadras. Menos dado embarcado significa pacote mais leve, sincronização mais rápida e, principalmente, menor superfície de conflito.

Do lado do servidor, esse desenho conversa bem com um banco espacial central. A base corporativa fica no PostGIS, os recortes de campo saem dela e voltam para ela. O arquivo local é uma cópia de trabalho com prazo de validade, nunca a fonte de verdade.

Aplicativo de campo e nuvem: o modelo do QField

Quando a operação tem muitas equipes, o empacotamento manual não escala, e entra um serviço de sincronização. O ecossistema QField, voltado a campo com QGIS, documenta um comportamento que vale conhecer mesmo para quem usa outra ferramenta, porque expõe as decisões inevitáveis desse tipo de arquitetura.

A primeira delas é a normalização do formato. A documentação do QFieldCloud afirma que, "independentemente de seus arquivos estarem armazenados em um GeoPackage, banco de dados ou outro formato, o QFieldCloud criará um GeoPackage temporário de todos os dados do projeto". Ou seja, a origem pode ser qualquer uma; o que vai para o dispositivo é sempre um contêiner local.

A segunda é o isolamento do trabalho de cada pessoa. Ainda segundo a documentação, "as mudanças feitas nesse GeoPackage não estarão disponíveis para outros" e, "uma vez que as mudanças são sincronizadas ou enviadas de volta ao QFieldCloud, somente as mudanças feitas serão aplicadas ao arquivo existente no QFieldCloud". Esse é o ponto que muita gente descobre tarde: enquanto a equipe está na rua, o painel do escritório não reflete o que está sendo feito. Se a gestão precisa de acompanhamento contínuo, isso precisa ser resolvido por um canal próprio, e não pela expectativa de que a base compartilhada esteja atualizada em tempo real.

Quando o aplicativo é web: service worker e fila de envio

Nem toda operação usa aplicativo nativo. Sistemas de gestão acessados pelo navegador também podem funcionar sem rede, e a peça central chama-se service worker. A MDN o descreve como "um worker orientado a eventos, registrado contra uma origem e um caminho", que assume "a forma de um arquivo JavaScript capaz de controlar a página ou o site ao qual está associado, interceptando e modificando requisições de navegação e de recursos, e fazendo cache de recursos de forma bastante granular". O propósito é declarado sem rodeios: eles existem, entre outras coisas, para "permitir a criação de experiências offline efetivas".

Três restrições documentadas afetam o projeto e é melhor conhecê-las antes:

• Contexto seguro obrigatório. Service workers "só estão disponíveis em contextos seguros", isto é, HTTPS, com http://localhost tratado como exceção para desenvolvimento.
• Outra thread, sem DOM. Eles "rodam em um contexto de worker: portanto não têm acesso ao DOM e rodam em uma thread diferente da do JavaScript principal", sendo "não bloqueantes e projetados para serem totalmente assíncronos".
• APIs síncronas fora. Como consequência, "APIs como XHR síncrono e Web Storage não podem ser usadas dentro de um service worker". O armazenamento estruturado local passa por IndexedDB.

Para o envio adiado existe uma API específica. A MDN descreve a Background Synchronization API como aquela que "permite que aplicações web adiem o trabalho de sincronização com o servidor para o seu service worker tratar mais tarde, caso o dispositivo esteja offline". O exemplo oficial é justamente o de um cliente de e-mail que deixa o usuário compor e enviar mensagens a qualquer momento, mesmo sem conexão: "o frontend da aplicação apenas registra uma solicitação de sync e o service worker é alertado quando a rede está presente novamente e trata a sincronização".

Recomendação prática, e aqui falamos por experiência de implantação: trate a fila como parte da interface, não como detalhe interno. O técnico precisa ver quantos registros estão pendentes e desde quando. Uma fila invisível funciona igual a uma fila quebrada aos olhos de quem opera.

Conflito: a parte difícil que ninguém especifica

Enquanto cada equipe coleta o que é seu, offline é quase trivial. O problema aparece quando duas pessoas, ou uma pessoa e o escritório, mexem no mesmo registro entre o empacotamento e a sincronização. Três orientações da documentação do QFieldCloud resumem bem os cuidados que valem para qualquer arquitetura desse tipo.

1. Chave estável, não sequencial. A recomendação é adicionar um campo UUID e usá-lo como chave primária ou estrangeira, com um alerta explícito: "não use o campo fid padrão para relações". A justificativa documentada é que "o campo fid pode ser sincronizado ao trabalhar com o QFieldCloud e levará a erros ao longo do tempo", enquanto "um UUID, por outro lado, é único e não será sincronizado". Traduzindo: identificador gerado pelo banco central não sobrevive a um mundo em que registros nascem no dispositivo.
2. Não mexer no projeto durante a operação. A documentação orienta: "não modifique o projeto QGIS enquanto o pessoal estiver trabalhando simultaneamente no QField", porque a sincronização a partir do desktop faz o serviço sobrescrever os arquivos.
3. Estrutura de dados congelada até a volta. Também está registrado que não se deve alterar a estrutura de dados antes de sincronizar as últimas edições de campo, sob risco de erro quando as mudanças ainda não foram enviadas.

A leitura de fundo é que sincronização não é um botão, é uma política. Alguém precisa decidir, antes do primeiro dia de operação, o que acontece quando os dois lados mudaram o mesmo campo: o campo vence, o escritório vence, ou o registro entra em uma fila de revisão humana. Não decidir é decidir pela pior opção, que é a sobrescrita silenciosa.

Dez decisões antes de mandar o time para a rua

A lista a seguir é a nossa checagem de projeto, formada em implantações de campo. Não é afirmação das fontes citadas.

1. Definir o nível de offline entre os quatro do início deste guia, por escrito, com o cliente ou a área usuária.
2. Delimitar o recorte do dia. Área, camadas e atributos que realmente vão embarcados, e não a base inteira por precaução.
3. Adotar identificador estável gerado no dispositivo, para que o registro nasça com identidade própria.
4. Levar as regras junto. Validação que só roda no servidor gera retrabalho quando o lote sobe com erro.
5. Tornar a fila visível para quem opera, com contagem, data e motivo de falha.
6. Definir a política de conflito por tipo de dado, antes da primeira semana de uso.
7. Tratar mídia à parte. Foto e vídeo dominam o volume; devem subir em fila própria, com compressão e retomada.
8. Cuidar da coordenada. Sem correção em tempo real, a precisão em campo muda de natureza, assunto que detalhamos em precisão do GPS em campo.
9. Testar o pacote completo em modo avião antes de liberar, incluindo abrir o aplicativo do zero, e não apenas continuar uma sessão já aberta.
10. Medir o tempo de sincronização com o volume de um dia cheio, e não com três registros de teste.

Nenhum desses itens é caro. Todos ficam caros quando entram depois, com equipe em produção e dado já perdido no meio do caminho. É por isso que, nos projetos de gestão operacional que a Felikis conduz com o Phrisma, o desenho do fluxo de campo é discutido antes da tela: primeiro o que o técnico precisa concluir sem sinal, depois a interface que sustenta isso. Se você quer ver como esse encadeamento aparece na prática, os produtos da Felikis mostram o caminho do dado desde a coleta até o painel de decisão.

Perguntas frequentes

Fontes e referências