Tratamento Elegante de Erros e Sessões Abandonadas em Webviews

Quando se integram aplicações móveis com serviços de autenticação externa, gateways de pagamento, ou validações 3D Secure, é muito comum recorrer a Webviews (carregar uma página web diretamente dentro da app nativa).

Do ponto de vista de desenvolvimento, desenhamos sempre o caminho feliz: o utilizador abre a webview, insere os dados, a webview fecha e o sistema regista sucesso.

Mas o que acontece se o utilizador fechar a aplicação à força a meio?

Sessões Abandonadas (Abandonment)

Sessões abandonadas provocam um estrago gigantesco se a máquina de estado do backend estiver dependente da resposta explícita do frontend. Se a webview falha (erro HTTP 400 por exemplo) e for fechada de forma abrupta, o seu backend pode pensar que o pedido ainda está "Em Processamento" para sempre.

Soluções Práticas

1. Expiradores de Estado (Guard Expire Windows): Nunca deixe um processo em aberto infinitamente. Se for um pagamento, configure as tarefas assíncronas (Jobs/Crons) com um prazo de validade (ex: 10 minutos). Se após esse tempo o estado não foi validado externamente de forma síncrona, a máquina de estado deve assumi-lo como "falhado" e libertar os recursos.
2. Handle Graceful (400 Bad Request): Se a página da Webview rebentar com erros de terceiros, deve ser capturada de forma amigável no seu servidor nativo que entrega a webview. Redirecione o erro feio para uma página HTML genérica da sua própria marca que avisa o utilizador e, mais importante, envia um sinal assíncrono para o backend e fecha a webview nativamente.

Sistemas sólidos lidam graciosamente com o caos, antecipando que o utilizador fechará a aplicação no pior momento possível.