O contexto
Um grupo de imprensa edita uma revista de programação televisiva e prolonga-a numa aplicação móvel: a grelha dos canais, as fichas dos programas e os artigos da redação.
A aplicação já existia. Tinha sido construída em Cordova com Angular — ou seja, um site encapsulado numa camada nativa, uma abordagem muito comum em meados da década de 2010. Funcionava, estava em produção e tinha chegado ao limite.
O desafio
É uma situação que muitas empresas conhecem sem saber como resolver: uma aplicação híbrida que envelheceu bem do ponto de vista funcional e mal do ponto de vista técnico.
Os sintomas são sempre os mesmos. O deslocamento de uma grelha densa de programas não tem a fluidez de uma aplicação nativa. Cada atualização do iOS ou do Android passa a ser um risco, porque a camada de encapsulamento depende de componentes que já não são verdadeiramente mantidos. E as bibliotecas do ecossistema vão rareando.
Perante isto, duas más respostas habituais:
- Não fazer nada, até ao dia em que uma atualização do sistema operativo parte a aplicação e é preciso refazê-la à pressa, sem orçamento previsto.
- Recomeçar do zero, com uma nova aplicação, um novo identificador nas lojas e a perda de todo o histórico — avaliações, posicionamento, instalações existentes. Os utilizadores têm de voltar a descarregar. Muitos não o fazem.
O verdadeiro objetivo não era, portanto, «reescrever a aplicação». Era reescrever a aplicação sem que o utilizador desse por isso.
O que fizemos
A reescrita completa em Flutter, com uma arquitetura em camadas — um núcleo técnico (rede, armazenamento, tema), funcionalidades isoladas umas das outras (grelha TV, atualidade, pesquisa, ficha de programa, definições) e uma camada partilhada. Nada de exótico: uma estrutura que outro programador pode retomar sem manual.
A continuidade de versão. A última versão híbrida tinha o número 3.1.8; a primeira versão Flutter saiu como 3.2.0. Do ponto de vista da loja e do utilizador, é mais uma atualização — não uma aplicação nova. O histórico, as avaliações e o parque instalado são preservados. É este pormenor que distingue uma migração bem-sucedida de uma migração que custa a base de utilizadores.
O conforto de leitura, que era a razão de ser do projeto:
- Cache local das grelhas, para que a aplicação abra com conteúdo em vez de um indicador de carregamento
- Cache dos pedidos de rede, para não recarregar o que não mudou
- Carregamentos progressivos na abertura dos ecrãs, em vez de um ecrã vazio
Um back-end de conteúdos, desenvolvido em Java, composto por serviços separados:
- Um enriquecedor de grelhas, que completa os dados brutos dos canais com informação adicional — incluindo recomendações vindas das plataformas de streaming
- Um agregador de artigos, que recolhe a produção editorial da redação para a apresentar na aplicação
A aplicação está publicada na App Store e na Play Store.
O resultado
Uma aplicação nativa, mantível com as ferramentas de hoje, entregue em continuidade com aquela que substitui.
Se houvesse uma única coisa a reter deste projeto, seria esta: a parte difícil de uma migração técnica quase nunca é técnica. Reescrever código sabemos fazer. O que exige método é fazê-lo sem que sejam os utilizadores a pagar a transição — manter o identificador, manter a numeração, manter os hábitos e tornar visível apenas aquilo que melhora.