Apps e operação em campo
App que funciona sem internet: o que isso significa para a sua operação
Três coisas diferentes se escondem atrás de "funciona offline". Qual delas a sua operação precisa, o que cada uma muda no prazo, e quando um aplicativo de prateleira já resolve.
9 min de leitura
"Funciona sem internet" não descreve uma funcionalidade. Descreve pelo menos três coisas diferentes, com custos de construção muito distintos entre si. Um aplicativo que apenas mostra sem rede o que já foi baixado é um projeto. Um aplicativo em que a pessoa trabalha um turno inteiro sem sinal e depois devolve tudo para o sistema é outro. Um aplicativo que, além disso, conversa com um equipamento no meio do campo é um terceiro. Quem pede orçamento sem separar os três recebe números que não dá para comparar.
A pergunta útil não é "funciona offline?". É: o que a pessoa precisa conseguir concluir sem sinal, e por quanto tempo ela fica assim. Enquanto essa resposta não existir por escrito, qualquer prazo é chute. Este texto é para quem decide a contratação, não para quem escreve o código: o que muda, onde o dinheiro vai, e quando a resposta certa é comprar um produto pronto em vez de mandar construir.
O que "funciona sem internet" quer dizer, na prática?
São três níveis, e vale identificar o seu antes de conversar com qualquer fornecedor.
Nível 1, consulta offline. O aplicativo guarda no aparelho o que já foi baixado e continua exibindo isso sem rede: catálogo, tabela, manual, roteiro do dia. A pessoa lê, mas não produz nada novo. É o nível mais barato e o que quase todo aplicativo já faz com algum cuidado de cache.
Nível 2, operação offline. A pessoa registra, edita, tira foto, conclui uma ordem de serviço, fecha uma visita, tudo sem rede. Durante esse período o aparelho passa a ser a fonte temporária da verdade, e o servidor está desatualizado sem saber disso. Quando o sinal volta, alguém precisa reconciliar as duas versões. É aqui que o custo do projeto muda de patamar, e é o nível que a maioria das empresas quer dizer quando fala "funciona offline".
Nível 3, operação offline com equipamento. Além de registrar, o aplicativo conversa com um hardware ali mesmo: leitor RFID, GPS acoplado, balança, coletor, sensor. Não existe rede e não existe servidor para arbitrar nada. O aparelho é, ao mesmo tempo, a interface, o registro e a ponte com o equipamento.
Sinal de alerta
Proposta que responde "sim, funciona offline" sem dizer qual dos três níveis está orçando. Os três cabem na mesma frase e não cabem no mesmo orçamento.
Qual nível a sua operação pede?
Isso não se decide olhando tecnologia. Decide-se olhando a rotina de quem vai usar. Quatro perguntas resolvem quase sempre.
- O que a pessoa precisa terminar sem sinal? Consultar uma informação é uma coisa; fechar um registro que o financeiro vai cobrar depois é outra.
- Por quanto tempo ela fica sem rede? Minutos entre um galpão e outro, um turno inteiro na lavoura, ou uma semana em uma frente de obra. O tempo muda o volume de dado acumulado e a chance de conflito.
- Duas pessoas podem mexer no mesmo registro nesse período? Se sim, o projeto ganha uma regra de desempate, e essa regra é decisão de negócio, não de programação.
- O que acontece se o aparelho quebrar ou for perdido antes de sincronizar? A resposta honesta define quanto se investe em sincronização parcial e frequente.
Sinal de alerta
Responder as quatro com "não sei" e mesmo assim receber um prazo fechado. Levantar isso em campo é parte do projeto, e um fornecedor sério cobra por essa etapa em vez de fingir que ela não existe.
Por que a parte difícil é a volta, e não a ida?
Guardar dado no aparelho é o trecho fácil. Todo celular tem banco local, e isso está resolvido há anos. O que consome o orçamento é a volta: o momento em que o aparelho reencontra a rede e as duas metades precisam virar uma só, sem perder registro e sem duplicar nada.
Quatro decisões aparecem sempre, e todas são de negócio antes de serem técnicas. Quem é a fonte da verdade quando as duas pontas mudaram enquanto estavam separadas. O que fazer quando o mesmo registro foi editado nos dois lados. Como um registro criado sem rede ganha um identificador que não colide com o de mais ninguém. E em que ordem os eventos entram no servidor, já que a ordem em que chegam não é a ordem em que aconteceram.
Foi exatamente esse o trabalho no Farm Tracker. O cliente já tinha um hardware proprietário com GPS e RFID, projetado para ficar acoplado ao trator durante a aplicação de insumos. Faltava a camada de software: aplicativo em Flutter conversando com o equipamento por Bluetooth, arquitetura offline-first porque lavoura quase não tem sinal, sincronização assim que a rede volta, dashboard em Flutter Web para o gestor e uma API em C# / .NET sobre PostgreSQL costurando as pontas. A decisão difícil não foi o Bluetooth. Foi o modelo de dados: definir quem manda quando as duas versões divergem.
Sinal de alerta
Fornecedor que trata sincronização como detalhe de implementação. A regra de desempate muda o resultado do seu negócio, e quem decide é você.
O que isso muda no prazo?
As faixas que a gente usa como referência deixam a diferença visível. Uma primeira versão enxuta, com as telas essenciais e publicação nas lojas, leva de 6 a 12 semanas. Um aplicativo médio, com backend próprio e painel administrativo, de 3 a 5 meses. Quando entra integração com equipamento ou operação sem internet, de 4 a 6 meses.
A diferença não está na quantidade de telas. Está no que precisa ser testado. Um aplicativo comum se valida no escritório. Um aplicativo offline se valida no estado intermediário: sinal fraco, sincronização interrompida no meio, aparelho desligado com dado pendente, dois usuários voltando à rede ao mesmo tempo. Boa parte desse teste acontece em campo, com o equipamento real, e campo tem agenda própria.
E some até 30 dias entre o build finalizado e o aplicativo disponível para baixar. A revisão da App Store e da Google Play tem tempo próprio e não depende de nenhum dos dois lados.
Sinal de alerta
Prazo de operação offline igual ao de um aplicativo comum. Ou o fornecedor não entendeu o pedido, ou está orçando o nível 1 e vai descobrir o nível 2 no meio do projeto.
Quando um aplicativo de prateleira já resolve?
Boa parte de quem procura por isso não precisa mandar construir nada. Se o seu processo é o padrão do setor, e o dado que interessa é o que um produto pronto já modela, comprar é mais rápido e mais barato. Existe produto de prateleira decente com operação offline em gestão rural, ponto eletrônico, ponto de venda e ordem de serviço.
Construir sob medida se justifica em três situações concretas.
- Existe hardware proprietário no meio. Nenhum produto de prateleira fala com o equipamento que o seu fornecedor desenhou.
- O processo não cabe no formulário do produto pronto. Quando adaptar a operação ao software custa mais do que o software, a conta virou.
- O dado precisa cair dentro de um sistema que já existe. Se o destino final é o ERP, o sistema interno ou o banco que a empresa já opera, o trabalho é de integração, e prateleira raramente entrega isso do jeito que precisa.
Sinal de alerta
Fornecedor que nunca diz "nesse caso, compre pronto". Quem só sabe recomendar o que vende não está avaliando o seu caso.
E o PWA: um site que funciona offline resolve?
Navegador moderno consegue guardar arquivos e dados e continuar servindo a página sem rede. Para o nível 1, e para formulário curto de nível 2, isso costuma bastar, e sai mais barato, porque não passa por loja nenhuma.
Os limites aparecem antes do que se imagina. Execução em segundo plano é restrita, então sincronizar sozinho enquanto o aparelho está no bolso é pouco confiável. Acesso a Bluetooth e a periférico é limitado e desigual entre plataformas, o que praticamente exclui o nível 3. O espaço de armazenamento fica sujeito à limpeza do sistema operacional, o que é aceitável para cache e arriscado para dado que ainda não subiu. E o comportamento difere bastante entre iOS e Android, o que dobra o teste em vez de reduzir.
A regra prática: consulta offline, o PWA resolve bem. Turno inteiro produzindo dado sem rede, ou qualquer conversa com equipamento, pede aplicativo instalado.
Sinal de alerta
"A gente faz um PWA e resolve" dito antes de alguém perguntar quanto tempo a equipe fica sem sinal.
O que perguntar ao fornecedor antes de assinar?
Seis perguntas separam quem já construiu operação offline de quem vai aprender no seu orçamento.
- Qual dos três níveis esta proposta está orçando?
- O que exatamente a pessoa consegue concluir sem rede, e o que fica bloqueado?
- Quando o mesmo registro é editado nos dois lados, quem ganha, e quem decidiu essa regra?
- Como vocês testam o estado intermediário: sincronização interrompida, aparelho perdido, dois usuários voltando juntos?
- O teste em campo, com o equipamento real, está no cronograma e no preço?
- O que acontece com o dado pendente se o aplicativo for desinstalado?
Os sinais de alerta, numa lista só
Se você levar só uma coisa daqui, leve esta lista. Cada item é a versão curta de uma das seções acima.
- Responde "sim, funciona offline" sem dizer qual nível.
- Dá prazo de operação offline igual ao de aplicativo comum.
- Não pergunta por quanto tempo a equipe fica sem sinal.
- Não tem regra de desempate para edição simultânea, ou trata isso como detalhe técnico.
- Deixa o teste em campo fora do cronograma.
- Propõe PWA sem discutir segundo plano, armazenamento e diferença entre plataformas.
- Nunca recomenda comprar um produto pronto.
Como a gente trata isso
A gente já construiu o nível 3, que é o mais caro dos três: aplicativo de campo falando com hardware proprietário por Bluetooth, rastreio rodando sem rede e sincronizando quando o sinal volta, com dashboard e API do outro lado. Está descrito no portfólio, com o problema que o cliente trouxe, o que foi construído e a stack usada. Não é o único jeito de resolver o problema. É o jeito que a gente já viveu, e é sobre isso que dá para conversar com detalhe.
Se a sua operação passa horas sem sinal, comece descrevendo a rotina, não a tecnologia: quem usa, onde, por quanto tempo, e o que não pode parar. A partir daí dá para dizer qual dos três níveis é o seu, se prateleira resolve, e só então quanto tempo leva. E quando for para construir, o código-fonte é do cliente e o repositório é entregue ao fim do projeto.