Digitalizar uma obra sem conectividade: o que funciona offline e o que não
A conectividade intermitente é a restrição mais subestimada da digitalização de obra. Um sistema que funciona bem no escritório e falha duas vezes em campo perde a confiança do usuário de forma permanente: depois da segunda perda de dados, o residente volta para a caderneta e não retorna mais.
E não é um problema exclusivo de obras remotas. O subsolo de um edifício no centro de uma cidade pode ter sinal pior do que uma estrada rural.
Os quatro cenários
Nem toda conectividade ruim é igual, e a solução técnica depende de qual você tem.
| Cenário | Situação típica | O que exige |
|---|---|---|
| Sem cobertura | Zona rural, túnel, subsolo | Captura totalmente local com sincronização posterior |
| Cobertura intermitente | Obra periurbana, edifício em estrutura | Fila de reenvio automática |
| Cobertura lenta | Rede saturada, 2G ou 3G degradado | Conteúdo leve, envio diferido de fotos |
| Boa cobertura | Obra urbana consolidada | Nada especial |
O segundo cenário é o mais comum e o que mais causa problemas, porque o sistema «parece» ter sinal. O aplicativo tenta, falha parcialmente e o usuário não sabe se o dado foi salvo. Essa incerteza é pior do que a ausência total de sinal.
O que funciona offline
Captura de texto e voz. Não exige rede no momento. O dado é salvo localmente e enviado depois. É o mais fácil de resolver e o mais importante.
Captura de fotos. Igual, com uma consideração de tamanho: se acumularem duzentas fotos sem enviar, a sincronização posterior pode ser pesada. Convém comprimir localmente e enviar em lotes.
Consulta de informação já baixada. O catálogo de serviços, o orçamento, o cronograma. Se foram baixados quando havia sinal, podem ser consultados sem ele.
Cálculos locais. Produtividades, acumulados, avanço do dia. Se a lógica está do lado do dispositivo, não precisa de servidor.
O que não funciona offline
Transcrição de voz por modelo grande. Os modelos de reconhecimento de fala de boa qualidade rodam em servidores. A nota de voz pode ser gravada sem sinal, mas a transcrição acontece quando há rede.
Isso não é problema se o desenho previr: o residente grava, o sistema enfileira e, quando há sinal, transcreve e devolve a confirmação. O residente não espera.
Qualquer análise contra dados de outras obras. Comparativos entre projetos, consolidados da empresa, painéis de direção. Tudo isso vive do lado do servidor.
Sincronização entre usuários. Se duas pessoas registram na mesma obra sem sinal, seus dados não se veem até que ambos sincronizem.
Concordância e assinatura da contraparte. Exige que ambas as partes estejam conectadas. Uma assinatura pode ser solicitada sem sinal, mas se completa quando há.
Por que o WhatsApp resolve boa parte do problema
Vale apontar porque costuma passar despercebido: o WhatsApp já resolveu o problema da fila de reenvio, e resolveu bem.
Quando não há sinal, a mensagem fica com uma marca de relógio e se envia sozinha quando a rede aparece. O usuário não precisa fazer nada, não precisa lembrar e não precisa se perguntar se foi salvo. É um comportamento que as pessoas já conhecem e no qual já confiam.
Qualquer sistema de captura de obra que se apoie nesse canal herda essa robustez sem construí-la.
O problema que a fila não resolve
E aqui está o ponto que quase ninguém considera: a fila resolve o envio, não a data.
Uma mensagem enviada na terça às quatro da tarde, sem sinal, pode chegar ao servidor na quarta às sete da manhã. Se o sistema atribui o registro pela hora de chegada, você acabou de produzir um diário com a data errada.
E um diário com datas erradas é pior do que não ter diário, porque destrói a credibilidade de todo o registro. Se um único assento tem data inconsistente, qualquer contraparte vai questionar o resto.
A solução de desenho é manter dois relógios e nunca misturá-los:
- Data declarada: a hora do dispositivo quando o usuário capturou, ou a que o usuário declara explicitamente
- Data de recebimento: a hora do servidor, autoritativa e independente
As duas são guardadas, as duas são mostradas e, quando diferem, a diferença é explicada. Além disso é preciso um mecanismo trivial para declarar retroativamente: «isto foi de ontem», registrado como declaração do usuário e não como dado do sistema.
Perguntas de avaliação
Cinco perguntas para fazer a qualquer fornecedor antes de comprar:
- O que acontece exatamente se eu registrar sem sinal? Peça que demonstrem colocando o telefone em modo avião durante a demonstração. É o teste mais revelador e quase ninguém pede.
- Como o usuário sabe que o dado foi salvo? Tem de haver um sinal visual inequívoco.
- O que acontece se a mensagem chegar no dia seguinte? É aqui que se distingue quem pensou o problema.
- Quanto ocupa o aplicativo e quanto consome de dados? Muitos trabalhadores de obra têm planos pré-pagos limitados. Um sistema que consome o plano do usuário não será usado.
- O que acontece se o telefone se perder ou quebrar? Os dados não sincronizados se perdem?
O que convém resolver antes de digitalizar
Duas coisas práticas que poupam muita dor:
Mapeie a cobertura real da obra. Não a teórica da operadora: percorra as frentes e anote onde há sinal. Quase sempre há um ponto —o escritório de campo, a entrada, uma laje alta— que tem. Esse ponto vira o lugar de sincronização.
Ofereça conectividade em pelo menos um ponto. Um roteador com rede móvel no escritório de campo custa pouco e resolve a maioria dos casos. É mais barato do que qualquer engenharia de software para operar sem rede.
Perguntas frequentes
- Vale a pena digitalizar uma obra sem nenhuma cobertura?
- Sim, se a captura for local e a sincronização diferida. O que não funciona é um sistema que exija conexão permanente. Em obras sem cobertura, um ponto de sincronização no fim do dia costuma ser suficiente.
- O que acontece se duas pessoas registrarem a mesma coisa sem sinal?
- Ocorre um conflito de dados que precisa ser resolvido na sincronização. Os sistemas sérios detectam isso e mostram as duas versões. Os que não preveem sobrescrevem com o último que chega e perdem informação silenciosamente, que é o pior comportamento possível.
- Um aplicativo web serve ou é preciso um nativo?
- Um aplicativo web progressivo bem construído funciona offline na maioria dos casos e evita o problema da instalação. O nativo leva vantagem quando é preciso acesso profundo à câmera ou ao armazenamento, por exemplo para preservar os metadados originais das fotos.
- A captura offline consome muita bateria?
- A captura não; a sincronização sim, sobretudo quando busca rede de forma agressiva. Um sistema bem feito sincroniza quando detecta bom sinal, e não tentando a cada trinta segundos.
- Como lidar com a data se o relógio do telefone estiver errado?
- É um caso real e por isso o sistema deve guardar as duas datas. Quando a diferença entre o relógio do dispositivo e o do servidor é implausível, convém sinalizar para revisão em vez de aceitar em silêncio.
Chileno, desenhando para a América Latina. Do research em campo tira o que realmente importa para os clientes, e com isso monta produtos que pessoas não técnicas adotam sozinhas —jurídico, educação, contabilidade— e que aparecem na produtividade já na primeira semana.
Ver todos os seus artigos →
