Se a ligação falhar a meio de uma tarefa, o trabalho fica guardado ou tem de começar de novo?
Antes de pedir uma app que «funcione offline», decida o que a sua empresa precisa de conseguir fazer sem internet. Consultar uma instrução, registar uma observação e confirmar a disponibilidade de um equipamento são decisões diferentes.
A nossa recomendação é começar pelo trabalho que não pode ser perdido. Depois, separar aquilo que o telemóvel pode guardar daquilo que só o sistema central pode confirmar. Essa fronteira deve orientar o investimento no desenvolvimento para iPhone e Android.
Escolha a tarefa que tem de sobreviver à falta de rede
Imagine uma empresa de assistência a equipamentos de restauração. Um técnico desloca-se à cave de um restaurante para inspecionar uma máquina. Precisa da identificação do equipamento, das instruções da intervenção e de um espaço para registar o que encontrou.
Neste exemplo, propomos preservar a consulta da ficha e o registo das observações sem rede. Já a promessa de entrega de uma peça deve esperar pela confirmação da disponibilidade no sistema central.
Uma app offline não tem de executar todas as funções sem internet. A documentação Android distingue expressamente o acesso local aos dados das operações de escrita e admite que apenas uma parte crítica da aplicação funcione sem ligação. (developer.android.com)
Para escolher essa parte, peça ao responsável da operação que responda:
- Que tarefa obriga hoje a equipa a esperar, telefonar ou passar para papel?
- O que seria necessário repetir se o registo desaparecesse?
- Que decisão pode esperar pelo regresso da ligação?
- Que confirmação seria perigoso dar com informação antiga?
Não comece por descarregar toda a informação da empresa para o telefone. Comece por uma intervenção completa que faça sentido conseguir executar sem rede.
Uma tabela para separar registo de confirmação
Use esta tabela numa reunião entre operações e desenvolvimento. As decisões abaixo são propostas para o exemplo da assistência técnica, não regras universais para qualquer app.
| Operação | Comportamento proposto sem rede | Limite a comunicar |
|---|---|---|
| Consultar a ficha do equipamento | Mostrar a cópia previamente descarregada | Indicar quando foi atualizada |
| Ler as instruções da intervenção | Disponibilizar a versão preparada antes da visita | Avisar se não existir uma cópia local |
| Registar observações e fotografias | Guardar no dispositivo para envio posterior | Mostrar que ainda não chegaram à empresa |
| Pedir uma peça | Guardar um pedido pendente | Não prometer disponibilidade nem entrega |
| Alterar a atribuição da intervenção | Exigir confirmação do sistema central | Explicar que a alteração depende de ligação |
| Consultar o histórico completo | Manter online, salvo necessidade demonstrada | Não bloquear por isso a intervenção atual |
Para cada linha, registe também quem aceita o risco de trabalhar com uma cópia antiga. Uma ficha de identificação e uma informação de disponibilidade não devem receber automaticamente o mesmo tratamento.
A decisão editorial que recomendamos é simples: permitir recolher trabalho não significa autorizar a app a assumir compromissos em nome da empresa.
Se ninguém conseguir explicar o que acontece quando a informação estiver desatualizada, mantenha a confirmação online até essa regra ficar resolvida.
Prepare os dados antes de a equipa sair
O acesso offline depende de haver dados no dispositivo. Uma estratégia que descarrega informação apenas quando o utilizador abre um ecrã pode deixá-lo sem o conteúdo necessário quando perde a ligação. A documentação Android identifica precisamente esse risco nas estratégias de atualização a pedido. (developer.android.com)
Para a empresa do nosso exemplo, propomos uma ação de preparação do dia: descarregar as intervenções atribuídas e verificar se cada uma tem os elementos necessários.
Essa preparação deve responder a perguntas práticas:
- A ficha está disponível ou existe apenas o título da intervenção?
- As instruções foram descarregadas por inteiro?
- Faltam anexos que o técnico vai precisar de consultar?
- A aplicação mostra claramente o que ainda não está pronto?
Não use apenas uma mensagem como «dados atualizados». Prefira uma indicação verificável: quais as intervenções preparadas e quais continuam incompletas.
Defina ainda o que sai do dispositivo depois de terminar o trabalho. Como critério de projeto, limite a informação local ao necessário para a operação e estabeleça regras para terminar sessão, mudar de utilizador e eliminar cópias antigas. Não deixe estas decisões escondidas numa opção técnica chamada cache.
O momento difícil é quando a ligação regressa
A sincronização é a reconciliação entre os dados locais e os dados do servidor. Se ambos tiverem sido alterados, pode ser necessário resolver um conflito antes de concluir essa reconciliação. (developer.android.com)
Voltemos ao exemplo. Enquanto o técnico trabalha sem rede, o coordenador altera a intervenção no escritório. Quem deve prevalecer?
Não aceite uma resposta única para todos os campos. Propomos que as observações do técnico sejam acrescentadas ao histórico, mas que uma alteração à pessoa responsável pela intervenção seja validada pelo sistema central. Se houver incompatibilidade, o trabalho recolhido deve continuar acessível para revisão.
Há ferramentas com regras automáticas de resolução. Por exemplo, a documentação do Cloud Firestore descreve uma política em que a última escrita prevalece nas alterações ao mesmo documento. Isso é um comportamento da ferramenta, não uma decisão operacional que deva ser aceite sem análise. (firebase.google.com)
Peça à equipa de desenvolvimento que demonstre estes casos:
1. Envio repetido: a mesma observação é reenviada depois de uma interrupção. Exija que não apareça duplicada.
2. Alteração concorrente: o escritório e o telefone modificam a mesma informação. Exija uma regra explícita para escolher ou conciliar as versões.
3. Registo entretanto cancelado: o técnico tenta enviar trabalho para uma intervenção cancelada. Exija preservação do conteúdo e um destino para revisão.
4. Envio parcial: chegam as observações, mas falta uma fotografia. Exija que o estado não apresente o conjunto como concluído.
Estes são critérios de aceitação propostos para o projeto. Não são capacidades garantidas por instalar uma biblioteca de sincronização.
Guardado no telefone não é recebido pela empresa
Recomendamos distinguir no ecrã os estados «guardado neste dispositivo», «por enviar», «recebido pelo servidor» e «precisa de revisão». Escolha palavras adequadas à equipa, mas não esconda estados diferentes atrás de um visto verde.
Para o técnico, deve ser possível perceber se pode continuar a trabalhar. Para o coordenador, deve ser possível identificar o que ainda falta receber. Defina também quem intervém quando um envio permanece pendente.
No iPhone, a Apple disponibiliza várias estratégias de execução em segundo plano, mas o sistema controla o momento de execução de determinadas tarefas e limita o tempo disponível. Não trate uma app fechada como um processo que pode trabalhar continuamente à vontade. (developer.apple.com)
No Android, o WorkManager permite agendar trabalho persistente sujeito a condições, como a existência de rede. A execução pode ocorrer depois de essas condições serem satisfeitas; isso não equivale a uma promessa de envio imediato. (developer.android.com)
Por isso, inclua uma forma visível de consultar os envios pendentes e voltar a tentar com a app aberta. Para trabalho urgente, proponha um procedimento de confirmação antes de a equipa terminar o turno, em vez de depender apenas de tarefas invisíveis.
Também deve separar urgência de volume. A Apple recomenda agrupar pedidos e adiar transferências não essenciais quando as condições de rede e energia o justificam. (developer.apple.com)
No nosso exemplo, peça para avaliar o envio prioritário das observações e um tratamento separado dos anexos pesados. A decisão deve refletir o que o escritório precisa primeiro, sem apresentar uma intervenção incompleta como totalmente recebida.
Faça um ensaio que atravesse a operação inteira
Não aprove o modo offline apenas porque um ecrã abriu em modo de avião. Propomos um ensaio com dois utilizadores: um no telefone e outro no sistema de gestão.
Escolha uma intervenção de teste, sem dados reais de clientes, e execute esta sequência em iPhone e Android:
1. Prepare a intervenção com ligação e confirme os conteúdos disponíveis.
2. Desligue a rede, abra a ficha e registe uma observação com anexo.
3. Saia da app e volte a abri-la. Verifique se o trabalho continua acessível.
4. No sistema central, altere um dado que também tenha sido modificado no telefone.
5. Reponha a ligação e acompanhe cada estado até à receção ou revisão.
6. Interrompa um envio e repita a tentativa. Procure duplicados e anexos em falta.
7. Confirme que o coordenador consegue encontrar o resultado sem pedir ao técnico que repita o trabalho.
Acrescente um teste com sessão expirada e outro com pouco espaço disponível. O objetivo é observar a resposta da app e ajustar os critérios de aceitação, não presumir que qualquer dispositivo consegue guardar indefinidamente.
Registe o resultado por operação: preservou o conteúdo, indicou o estado correto, resolveu o conflito e permitiu concluir a tarefa? Um erro deve ter um responsável e uma ação prevista, não apenas uma mensagem técnica.
Aprove uma operação offline, não uma promessa genérica
Antes de adjudicar esta componente, peça uma demonstração do percurso completo: preparação, trabalho sem rede, regresso da ligação e confirmação no sistema central.
Entregue ao fornecedor a tabela preenchida com as suas operações. Peça que identifique o trabalho necessário na app e no servidor, os conflitos que serão tratados e as situações que continuarão a exigir ligação. Não aceite que «suporte offline» fique como uma linha sem limites definidos.
Para uma primeira entrega, recomendamos escolher a tarefa cuja interrupção mais prejudica a operação e que pode ser executada com informação previamente preparada. Deixe a expansão para outras funções dependente dos resultados desse ensaio.
A decisão fica então concreta: que trabalho a sua equipa consegue terminar sem rede, que compromissos precisam de confirmação e como a empresa verifica que recebeu tudo. É essa capacidade que vale a pena contratar.