É retain o começo do fim para ViewModel? Vamos descobrir.

Quando Jetpack Compose foi introduzido, gerenciar o estado da IU ficou muito mais simples e declarativo. Dependendo de quanto tempo o estado precisa sobreviver e quem é responsável por ele, Compose oferece diferentes soluções. A abordagem recomendada era direta:

remember :Para Estado Local da IU

Use remember para armazenar o estado que é local a um componente e apenas precisa sobreviver às recomposições. É ideal para interações temporárias da IU, como se uma janela modal está visível, qual guia foi selecionada ou o valor atual de um campo de texto.

rememberSaveable :Para Estado que Sobrevive a Mudanças de Configuração

Quando o estado da IU deve persistir através de mudanças de configuração como rotações de tela ou recriação do processo, rememberSaveable é a escolha preferida. Ele salva e restaura automaticamente valores usando o mecanismo Android de instância salva, tornando-o uma ótima opção para dados simples e salváveis como entrada de texto, posição de rolagem ou itens selecionados.

ViewModel :Para Gerenciamento de Estado em Nível de Tela

À medida que as aplicações crescem, uma tela frequentemente precisa gerenciar mais do que apenas interações da IU. Ela pode buscar dados de um repositório, lidar com ações do usuário, realizar operações assíncronas e expor estados como carregamento, sucesso ou erro. É aqui que entra um ViewModel. Em vez de armazenar o estado dentro do componente, o ViewModel atua como o guardião do estado em nível de tela, sobrevivendo a mudanças de configuração enquanto coordena lógica de negócios e expõe estados observáveis da IU para Compose renderizar.

Agora, o Runtime do Compose introduz uma nova API chamada retain.

Naturalmente, a comunidade Android começou a perguntar:

“Ainda precisamos de ViewModel?”

A resposta não é um simples sim ou não.

Neste artigo, exploraremos:

• O que é retention
• Como ele difere de lembrar
• Como ele se compara com ViewModel
• Quando você deve (e não deve) usá-lo