- `LiveData`: Mais simples, perfeito para casos de uso de UI diretos. Menos verboso. - `StateFlow`: Mais flexível, ideal para lógica mais complexa, streams de dados que não vêm diretamente da UI, ou se você já está imerso no ecossistema de Corrotines/Flows. ---

A Arquitetura Moderna (MVVM): Construindo Apps…

Q: Como ele funciona?

O `ViewModel` tem um escopo que está atrelado ao ciclo de vida do componente de UI (Activity/Fragment), mas não à sua instância. Quando uma Activity é destruída e recriada devido a uma rotação, o `ViewModel` associado a ela não é destruído. A nova instância da Activity se conecta ao *mesmo* `ViewModel` que já existia. Analogia: Imagine sua Activity como um "ator" que pode ser substituído no meio da peça. O `ViewModel` é o "roteiro" que fica no palco. O ator novo pega o mesmo roteiro e continua

💡 TL;DR (Resumo)

MVVM: Padrão de arquitetura que separa UI (View) da lógica (ViewModel) e dados (Model/Repository) para resolver fragilidade da destruição de componentes

ViewModel: Armazena e expõe estado da UI, sobrevive a mudanças de configuração (rotação de tela) porque seu ciclo de vida está desacoplado da Activity/Fragment

LiveData/StateFlow: Observáveis que notificam a View quando dados mudam, sendo lifecycle-aware (LiveData) ou requerindo composição (StateFlow) para evitar vazamentos

Repository Pattern: Abstração de acesso a dados que implementa Single Source of Truth, permitindo testar ViewModel em isolamento sem chamadas de rede reais

Takeaway Principal: MVVM com ViewModel + LiveData/StateFlow + Repository é a arquitetura padrão moderna do Android que torna apps robustos, testáveis e manuteníveis

Tempo de Leitura Estimado: 30 minutos

Você já domina a sintaxe de Kotlin e entende o motor do Android. Agora, vamos juntar essas peças para construir algo que dure. A arquitetura de um aplicativo é o que separa um protótipo frágil de um produto de software profissional, manutenível e escalável.

No Android, a arquitetura moderna, fortemente recomendada pelo Google, centra-se no padrão MVVM (Model-View-ViewModel) e em um conjunto de componentes Jetpack projetados para resolver os problemas mais comuns da plataforma.

Este artigo não é sobre teoria de design patterns abstratos. É sobre a aplicação prática de MVVM para resolver o problema número um: o ciclo de vida destrutivo dos componentes de UI. Vamos construir uma arquitetura que não apenas sobrevive a rotações de tela, mas que o faz de forma elegante, testável e com um código limpo.

O Problema Central: A Ilusão da Persistência de UI

Como vimos, uma Activity ou Fragment pode ser destruído e recriado a qualquer momento pelo sistema. Se você armazena o estado da sua aplicação (dados de um formulário, resultado de uma requisição de rede) diretamente na Activity, esse estado se perde.

As soluções antigas, como onSaveInstanceState, são manuais, limitadas (apenas para pequenas quantidades de dados) e não ajudam com operações de longa duração, como uma chamada de rede que estava em andamento quando a tela rotacionou.

A arquitetura MVVM, com seus componentes-chave, foi criada para isolar e proteger o estado da aplicação da volatilidade da camada de UI.

O Pilar Central: O `ViewModel`

O ViewModel é a estrela do show. Pense nele como o cérebro e o guardião do estado da sua tela.

Responsabilidade Fundamental

Armazenar e expor dados para a UI (View).
Sobreviver a mudanças de configuração (como a rotação de tela).

Como ele funciona?

O ViewModel tem um escopo que está atrelado ao ciclo de vida do componente de UI (Activity/Fragment), mas não à sua instância. Quando uma Activity é destruída e recriada devido a uma rotação, o ViewModel associado a ela não é destruído. A nova instância da Activity se conecta ao mesmo ViewModel que já existia.

Analogia: Imagine sua Activity como um "ator" que pode ser substituído no meio da peça. O ViewModel é o "roteiro" que fica no palco. O ator novo pega o mesmo roteiro e continua a peça de onde parou.

Exemplo Prático

kotlin

class MyViewModel : ViewModel() {
    // Este dado sobrevive à rotação de tela!
    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun onButtonClicked() {
        _userName.value = "Dados carregados!"
    }
}

Na sua Activity, você obtém uma instância do ViewModel:

kotlin

class MyActivity : AppCompatActivity() {
    private val viewModel: MyViewModel by viewModels() // Delegado property do KTX

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ... setup da UI ...

        // Se a Activity for recriada, 'viewModel' apontará para a mesma instância
        viewModel.onButtonClicked()
    }
}

O by viewModels() é um delegado que cuida da mágica de obter (ou criar) o ViewModel associado ao ciclo de vida desta Activity.

A Conexão Reativa: `LiveData` e `StateFlow`

Ok, o ViewModel segura os dados. Mas como a View (Activity/Fragment) sabe quando esses dados mudam, especialmente após uma recriação? A resposta é a programação reativa, através de LiveData ou StateFlow.

`LiveData`: A Simplicidade e a Segurança do Ciclo de Vida

LiveData é uma classe de detentora de dados observável. É "lifecycle-aware", ou seja, ela entende o ciclo de vida dos componentes Android (Activity, Fragment).

Como funciona

A View se "inscreve" (observa) um objeto LiveData no ViewModel.
A View só recebe atualizações enquanto está em um estado ativo do ciclo de vida (STARTED ou RESUMED).
Se a View for destruída (ou ficar inativa), ela automaticamente para de receber atualizações, evitando vazamentos de memória e crashes.
Quando a View é recriada (após uma rotação), ela se observa novamente e recebe imediatamente o último valor disponível no LiveData.

Exemplo

kotlin

// No ViewModel
private val _uiState = MutableLiveData<UiState>()
val uiState: LiveData<UiState> = _uiState

fun loadData() {
    _uiState.value = UiState.Loading
    // ... lógica para carregar dados ...
    _uiState.value = UiState.Success(data)
}

// Na Activity
viewModel.uiState.observe(this) { state ->
    when (state) {
        is UiState.Loading -> showProgressBar()
        is UiState.Success -> hideProgressBar() && showData(state.data)
        is UiState.Error -> showError(state.message)
    }
}

`StateFlow`: O Poder das Corrotinas

StateFlow é a alternativa mais moderna e flexível, parte do ecossistema de Corrotines de Kotlin. Ele também é um detentor de dados observável, mas com algumas diferenças chave:

Sempre tem um valor inicial: Um StateFlow nunca pode estar "vazio".
Mais poderoso: Ele se integra perfeitamente com outros operadores de flow do Kotlin.
Não é "lifecycle-aware" por padrão: Você precisa combiná-lo com um operador como lifecycleScope.launchWhenStarted ou, melhor ainda, com flowWithLifecycle para obter o mesmo comportamento seguro do LiveData.

Exemplo com `StateFlow`

kotlin

// No ViewModel
private val _uiState = MutableStateFlow<UiState>(UiState.Idle)
val uiState: StateFlow<UiState> = _uiState.asStateFlow()

fun loadData() {
    viewModelScope.launch {
        _uiState.value = UiState.Loading
        // ...
        _uiState.value = UiState.Success(data)
    }
}

// Na Activity (com a extensão 'flowWithLifecycle')
lifecycleScope.launch {
    viewModel.uiState
        .flowWithLifecycle(lifecycle, Lifecycle.State.STARTED)
        .collect { state ->
            // Lógica de UI aqui
        }
}

Qual usar?

LiveData: Mais simples, perfeito para casos de uso de UI diretos. Menos verboso.
StateFlow: Mais flexível, ideal para lógica mais complexa, streams de dados que não vêm diretamente da UI, ou se você já está imerso no ecossistema de Corrotines/Flows.

A Abstração de Dados: O Padrão Repository

O ViewModel não deve saber de onde vêm os dados. Ele não deve se importar se os dados vêm de uma API da internet, de um banco de dados local ou de um cache em memória. Essa é a responsabilidade do Repository.

O Repository é uma classe que implementa a lógica de acesso a dados. Ele atua como uma camada de abstração entre a sua aplicação e as fontes de dados.

Benefícios

Separação de Responsabilidades: O ViewModel lida com a lógica da UI; o Repository lida com a lógica de dados.
Testabilidade: Você pode "mockar" o Repository para testar o ViewModel em isolamento, sem fazer chamadas de rede reais.
Single Source of Truth (Fonte Única da Verdade): O Repository pode implementar uma lógica sofisticada, como:
- Buscar dados da rede.
- Salvá-los em um banco de dados local (usando Room).
- Expor os dados do banco de dados como a fonte única para a UI.
- A próxima vez que os dados forem solicitados, ele os busca do cache local (rápido) e atualiza em background (stale-while-revalidate).

Estrutura de Camadas

View (Activity/Fragment)
    ↓ chama métodos em
ViewModel
    ↓ chama métodos em
Repository
    ↓ decide entre
Retrofit (Network)  ←→  Room (Database)

Exemplo Prático de Repository

kotlin

class UserRepository(
    private val userApi: UserApi,
    private val userDao: UserDao
) {
    // Expõe um Flow que combina dados de rede e database
    fun getUsers(): Flow<Result<List<User>>> = flow {
        emit(Result.Loading)

        try {
            // Tenta buscar da rede
            val networkUsers = userApi.fetchUsers()

            // Salva no database
            userDao.insertAll(networkUsers)

            // Emite o resultado do database como fonte única
            emit(Result.Success(userDao.getAllUsers()))
        } catch (e: Exception) {
            // Se houver erro na rede, tenta buscar do database
            val cachedUsers = userDao.getAllUsers()
            if (cachedUsers.isNotEmpty()) {
                emit(Result.Success(cachedUsers))
            } else {
                emit(Result.Error(e))
            }
        }
    }
}

Juntando Tudo: O Fluxo Completo

Vamos visualizar um fluxo completo para uma tela que exibe uma lista de usuários.

A View (UserListFragment) é criada.
No onViewCreated, ela obtém uma instância do UserListViewModel.
A View começa a "observar" o StateFlow<UiState> do ViewModel.
A View chama viewModel.loadUsers().
O UserListViewModel chama repository.getUsers().
O UserRepository inicia uma corrotina.
- Ele primeiro emite um estado de Loading para o ViewModel.
- Ele faz uma chamada de rede usando Retrofit.
- Se a chamada for bem-sucedida, ele salva a lista de usuários no banco de dados local usando Room.
- Ele então busca a lista atualizada do Room (que agora é a "fonte da verdade") e a retorna para o ViewModel.
- Se houver erro, ele emite um estado de Error.
O UserListViewModel recebe o resultado (seja a lista de usuários ou um erro) e atualiza seu StateFlow com o novo estado (Success(data) ou Error(exception)).
A View, que está observando o StateFlow, recebe automaticamente o novo estado.
A View renderiza a UI correspondente: mostra um ProgressBar para Loading, a lista em um RecyclerView para Success, ou uma mensagem de erro para Error.

O Milagre da Rotação

Se o usuário rotacionar a tela, a View é destruída e recriada. Ela se reconecta ao mesmo ViewModel, que ainda tem o último estado (Success(data)). A View observa o StateFlow e recebe imediatamente os dados, atualizando a UI instantaneamente, sem nenhuma chamada de rede. A experiência é perfeita.

Conclusão: Arquitetura como Alicerce

Adotar MVVM com ViewModel, LiveData/StateFlow e Repository não é seguir uma moda. É construir um alicerce sólido para sua aplicação Android. Os benefícios são tangíveis e imediatos:

Robustez: Seu app se torna imune ao problema mais comum e frustrante do Android: a destruição de Activitys.
Testabilidade: Você pode testar a lógica de negócios (ViewModel) e a lógica de dados (Repository) separadamente da UI, com testes de unidade rápidos e confiáveis.
Manutenibilidade: A separação de responsabilidades é clara. Mudar a fonte de dados (trocar de API) não exige mudar o ViewModel. Mudar um botão na UI não exige mudar o Repository.
Escalabilidade: Essa arquitetura escala desde apps de uma tela até sistemas complexos com múltiplos módulos.

Com este bloco dominado, você não está mais apenas "programando para Android". Você está arquitetando soluções robustas para a plataforma. Você agora tem os alicerces para construir aplicações profissionais, mantíveis e que funcionam perfeitamente em todas as situações do mundo real.

A Arquitetura Moderna (MVVM): Construindo Apps Android Robustos e Testáveis

✨TL;DR / Sumário Executivo

💡 TL;DR (Resumo)

Tempo de Leitura Estimado: 30 minutos

O Problema Central: A Ilusão da Persistência de UI

O Pilar Central: O `ViewModel`

Responsabilidade Fundamental

Como ele funciona?

Exemplo Prático

A Conexão Reativa: `LiveData` e `StateFlow`

`LiveData`: A Simplicidade e a Segurança do Ciclo de Vida

Como funciona

Exemplo

`StateFlow`: O Poder das Corrotinas

Exemplo com `StateFlow`

Qual usar?

A Abstração de Dados: O Padrão Repository

Benefícios

Estrutura de Camadas

Exemplo Prático de Repository

Juntando Tudo: O Fluxo Completo

O Milagre da Rotação

Conclusão: Arquitetura como Alicerce

Receba novos artigos