Offline, atrasado, retomado: percursos móveis

Considere uma pessoa que inicia uma ação com uma ligação estável, continua enquanto a resposta está atrasada e regressa depois de a aplicação ter sido fechada. A interface tem de considerar todo o percurso, não apenas o momento em que o pedido é concluído com êxito. O funcionamento offline, ou seja, sem um caminho de rede utilizável, é uma condição inserida nesse problema mais amplo de continuidade.

A latência é o atraso entre uma ação e a respetiva resposta. Uma sessão interrompida é um percurso no produto que fica suspenso antes de a aplicação ter resolvido por completo a intenção da pessoa. Tratar ambos como elementos de conceção conduz a perguntas mais claras: o que pode continuar localmente, o que exige confirmação e o que deve ser apresentado quando não há certeza?

Mapeie o percurso antes de escolher uma alternativa

Comece pela ação pretendida e acompanhe todos os estados em que pode entrar. Um documento pode estar inalterado, editado localmente, a aguardar carregamento, confirmado remotamente ou bloqueado por um conflito. Dar nome a estes estados impede que um ecrã de carregamento vago abranja várias situações que exigem explicações ou controlos diferentes.

O mapa deve incluir saídas e regressos. Questione o que permanece se a aplicação fechar, se a ligação mudar ou se uma resposta chegar depois de o ecrã visível ter desaparecido. Em vez de compilar casos extremos, descreva o percurso no produto em cada condição de implementação que a equipa tem de suportar e verificar.

• Identifique a intenção da pessoa separadamente do pedido de rede utilizado para a concretizar.
• Assinale os passos que podem ser concluídos localmente e os que exigem confirmação remota.
• Registe o que a interface apresenta enquanto o resultado permanecer incerto.
• Defina onde uma sessão que regressa é retomada e que contexto é restaurado.

Dê um significado claro a cada estado visível

O estado é a informação que uma aplicação retém sobre a situação atual. Alguns estados pertencem apenas à interface, como um painel aberto. Outros estados representam progressos relevantes, como um rascunho editado. As equipas de produto devem decidir que informações têm de sobreviver a uma interrupção e colocá-las num armazenamento duradouro, ou seja, num armazenamento concebido para permanecer disponível depois de a sessão atual terminar.

Os rótulos visíveis devem distinguir o progresso da confirmação. Guardado neste dispositivo, a aguardar envio e não foi possível confirmar descrevem condições diferentes. A formulação exata depende do produto, mas cada mensagem deve esclarecer o que aconteceu, se a pessoa tem de agir e se o seu trabalho continua disponível.

1. Dê um nome ao estado relevante na linguagem do produto, em vez de utilizar a linguagem da implementação.
2. Decida que provas permitem à aplicação apresentar esse estado com segurança.
3. Disponibilize uma ação seguinte apenas quando uma intervenção puder alterar o resultado.
4. Preserve contexto suficiente para que a mensagem continue compreensível após o regresso.

Separe o progresso local da verdade partilhada

Uma fonte de verdade é o registo controlado que um produto considera oficial quando as cópias divergem. Uma aplicação pode manter o trabalho local enquanto aguarda a comparação com esse registo. A interface não deve sugerir uma confirmação remota apenas porque o armazenamento local foi bem-sucedido, mas também não deve apresentar progressos locais úteis como se tivessem sido perdidos.

Uma atualização otimista apresenta um resultado pretendido antes de chegar a confirmação remota. Esta escolha pode substituir uma espera visível por um estado provisório, mas a equipa tem então de definir o que acontece após uma rejeição, um atraso ou uma correção. Considere-a quando o estado provisório for compreensível e reversível. Para ações com consequências ou irreversíveis, uma confirmação explícita pode proporcionar um limite mais claro.

• Apresente um estado provisório quando uma correção posterior possa, de outro modo, parecer surpreendente.
• Mantenha as edições locais disponíveis enquanto a confirmação remota permanecer por resolver.
• Explique os conflitos através do conteúdo afetado, em vez de utilizar um erro de sincronização genérico.
• Evite a substituição silenciosa quando o produto puder ter de preservar alterações concorrentes.

Trate o trabalho pendente como uma fila gerida

Uma fila é uma coleção ordenada de operações que aguardam processamento. Se uma ação tiver de continuar depois de a conectividade regressar, represente-a como uma operação duradoura, em vez de uma animação associada a um único ecrã. A equipa deve verificar as condições de implementação relativas ao armazenamento, ao trabalho fora do ecrã visível e às tentativas repetidas antes de decidir com que independência essa fila pode funcionar.

Cada operação necessita de uma identidade, de um estado atual e de uma política de novas tentativas, que define quando é adequado efetuar outra tentativa. Quando o produto e o sistema remoto o permitirem, torne o processamento idempotente, o que significa que repetir a mesma operação não cria um efeito adicional. Se a equipa não conseguir estabelecer essa condição, o produto deve parar antes de uma repetição ambígua e disponibilizar uma forma de inspecionar a ação por resolver.

1. Armazene a operação pretendida com o contexto mínimo necessário para a retomar em segurança.
2. Assinale se o processamento não começou, permanece incerto, foi concluído com êxito ou exige atenção.
3. Tente novamente apenas quando a operação e o sistema remoto tornarem segura a repetição.
4. Remova o trabalho concluído sem apagar o contexto necessário para explicar o resultado visível.

Teste os limites das interrupções, não apenas os ecrãs

Os testes de interrupção devem acompanhar as ações através dos limites: antes do envio, durante uma resposta atrasada, depois do armazenamento local e antes da confirmação remota. Um teste específico altera uma condição de cada vez e verifica depois tanto a interface imediata como o estado apresentado após a reabertura. Isto proporciona à equipa uma forma direta de localizar regras de recuperação pouco claras.

Feche a aplicação em cada fase relevante de uma ação com vários passos e, depois, restaure a conectividade antes e depois da criação do trabalho pendente. Introduza uma edição hipotética em conflito e inspecione o percurso de resolução. Regresse através de um ponto de entrada diferente e verifique se o estado continua compreensível sem depender do ecrã original.

Analise o resultado tanto da perspetiva do produto como da perspetiva técnica. Em cada teste, considere se a conclusão técnica e a mensagem visível estão de acordo. Os critérios de aceitação, ou seja, as condições utilizadas para avaliar o percurso, devem abranger o trabalho retido, o estado visível, a repetição segura e o posterior alinhamento com o registo oficial.

Escreva um contrato de continuidade para cada ação principal

Transforme o modelo num contrato de continuidade: uma breve descrição interna do que a aplicação preserva, comunica e tenta fazer quando uma ação é interrompida. Para cada percurso principal, registe o estado local, o registo oficial, as condições de confirmação, a regra de novas tentativas e a opção de recuperação disponível para a pessoa.

A decisão prática não consiste em saber se uma aplicação está simplesmente online ou offline. Consiste na forma como o produto representa a incerteza entre a intenção e a confirmação. Mapeie os estados, distinga o progresso local da verdade partilhada, faça uma gestão explícita do trabalho pendente e teste cada limite de interrupção. Em conjunto, estas decisões formam um plano utilizável para percursos em que a continuidade não pode ser considerada garantida.