Conceber aplicações móveis para continuidade interrompida

Um produto móvel deve ser concebido para conectividade variável, respostas tardias e sessões que terminam sem aviso. Não se trata apenas de casos técnicos extremos. Estas condições determinam se uma ação é compreensível, se o trabalho inacabado é preservado e se a interface consegue explicar o que acontecerá a seguir.

A questão útil de conceção não é apenas saber se uma aplicação funciona offline. É necessário determinar que partes permanecem disponíveis, que estado o dispositivo consegue preservar e como as ações locais são conciliadas quando a comunicação é retomada. Responder cedo a estas questões produz um modelo de produto mais claro para a conceção, a engenharia e os testes.

Conceber para a continuidade, não para uma ligação perfeita

Um pedido que depende da ligação pode falhar antes de começar, enquanto está a ser processado ou depois de o sistema remoto o ter aceitado. A interface pode não saber qual destes casos ocorreu. Por isso, as equipas de produto precisam de uma política explícita para a incerteza, em vez de uma mensagem de erro genérica que trate todas as interrupções da mesma forma.

Continuidade significa preservar o significado da tarefa nestas condições. Uma vista de leitura pode continuar a partir de material armazenado, enquanto um fluxo de envio pode guardar um rascunho concluído sem afirmar que foi entregue. O comportamento adequado depende das consequências do atraso, da duplicação e da informação desatualizada.

Mapear o estado antes de conceber os ecrãs

O estado é a informação necessária para representar o produto num determinado momento. O estado local é mantido no dispositivo, enquanto o estado remoto é mantido noutro local por um serviço controlado. Mapear ambos revela que informação pode ser apresentada imediatamente, qual exige verificação e qual pode tornar-se incoerente.

• Identificar a informação que pode continuar a ser útil quando já não está atualizada.
• Assinalar as ações que não devem ser repetidas sem verificar o respetivo resultado remoto.
• Separar os dados introduzidos e inacabados dos registos confirmados e dos detalhes temporários da interface.
• Definir o que deve sobreviver ao fecho de uma sessão, a um reinício ou à falha de um pedido.

Um mapa de estados deve descrever as transições, além dos ecrãs. Para cada ação importante, importa perguntar o que a interface apresenta antes do pedido, durante a espera, depois da confirmação e após uma falha ambígua. Esta sequência torna visíveis os estados de recuperação em falta antes de estes se transformarem em decisões de implementação dispersas.

Tornar legíveis as ações atrasadas

A latência é o tempo entre o início de uma ação e a receção de uma resposta utilizável. Durante esse intervalo, a interface deve comunicar se os dados introduzidos foram aceites localmente, se a confirmação remota está pendente e se outra ação criaria um duplicado. Um indicador de carregamento, por si só, raramente responde a estas questões sobre o produto.

1. Acusar imediatamente a receção da ação sem sugerir que foi concluída remotamente.
2. Preservar os dados introduzidos relevantes enquanto o resultado permanecer incerto.
3. Apresentar um estado pendente estável quando a espera puder prolongar-se para além do ecrã atual.
4. Disponibilizar uma nova tentativa apenas quando a repetição da operação estiver definida como segura.
5. Substituir o estado temporário por um resultado confirmado ou recuperável.

Uma política de novas tentativas também precisa de suporte técnico. A idempotência é uma propriedade que permite voltar a submeter a mesma operação sem aplicar o efeito pretendido mais do que uma vez. Quando o sistema controlado consegue suportar a idempotência, um identificador idempotente do pedido pode reduzir a ambiguidade. Quando o sistema controlado não consegue suportá-la, a interface pode precisar de verificar o resultado antes de repetir a tentativa.

Conciliar a realidade local e a remota

A sincronização é o processo de levar o estado local e o estado remoto a uma forma acordada. Não é uma única ação de atualização. Um produto deve decidir que lado tem autoridade sobre cada campo, como são representadas as alterações pendentes e o que acontece quando ambos os lados mudaram durante a interrupção.

A resolução de conflitos é a política utilizada quando alterações concorrentes não podem ser combinadas automaticamente. Uma preferência inócua pode utilizar o último valor aceite, enquanto o conteúdo editado pode exigir a preservação de ambas as cópias ou um pedido de escolha. A política deve seguir o significado dos dados, em vez de aplicar uma única regra em todos os casos.

Preservar deliberadamente o trabalho interrompido

Uma sessão interrompida pode deixar dados valiosos na memória, no armazenamento persistente do dispositivo ou em lado nenhum. A persistência significa armazenar informação para que esta continue disponível após o fim do processo atual. As equipas devem decidir o que merece persistência, durante quanto tempo permanece relevante e quando a sua reposição pode induzir em erro.

• Guardar rascunhos em momentos significativos, e não apenas no envio final.
• Distinguir os dados repostos da informação já aceite remotamente.
• Evitar preservar material sensível, salvo se as respetivas condições de armazenamento forem adequadas.
• Remover trabalho pendente obsoleto após uma confirmação clara ou uma eliminação deliberada.

A reposição deve incluir o contexto, e não apenas os valores em bruto. Se uma aplicação voltar a abrir um formulário, também pode ter de explicar se os anexos continuam disponíveis, se a informação dependente precisa de verificação e se um envio anterior continua pendente. Estas condições devem ser verificadas para a plataforma e para a conceção do armazenamento efetivamente utilizadas.

Testar percursos em condições variáveis

Um ecrã pode parecer correto enquanto o percurso mais amplo perde dados ou repete uma ação. Por isso, os testes devem variar a conectividade e os limites da sessão durante uma tarefa. O objetivo é inspecionar as transições de estado do produto, incluindo os momentos em que a interface e o sistema remoto dispõem temporariamente de informações diferentes.

1. Iniciar uma ação com ligação e, depois, interromper a comunicação antes da confirmação.
2. Fechar a sessão enquanto existir trabalho pendente e voltar a abri-la.
3. Repetir uma ação após uma resposta ambígua e inspecionar o resultado.
4. Alterar a mesma informação local e remotamente antes da sincronização.
5. Repor a conectividade quando o trabalho em fila já não for válido.

Estes cenários são mais úteis quando os resultados esperados são documentados antes da implementação. Para cada um, importa especificar o que é armazenado, o que a interface pode afirmar, o que pode ser repetido e como o produto regressa a um estado estável. A execução em segundo plano e o comportamento do armazenamento específicos da plataforma devem continuar a ser elementos a verificar, e não pressupostos.

Escolher a política para as falhas antes dos acabamentos

Um quadro prático começa com quatro decisões: que tarefas continuam a ser úteis sem ligação, que ações exigem confirmação remota, que trabalho local deve sobreviver a uma interrupção e como são conciliados os estados em conflito. Estas decisões estabelecem os limites dentro dos quais os detalhes da interface podem ser concebidos com honestidade.

A revisão final deve acompanhar percursos completos, em vez de ecrãs isolados de sucesso. É necessário seguir cada ação importante ao longo da espera, da perda de ligação, do fecho, da reposição, da nova tentativa e do conflito. Se cada transição tiver um responsável, um estado visível e um caminho de recuperação, a utilização offline e a latência tornam-se condições definidas do produto, em vez de exceções não especificadas.