Executando verificação de segurança...
2

Como o Jetpack Compose 1.6 torna o onboarding de novos devs Android 3× mais rápido (e o que você pode aproveitar hoje)

A Google liberou a versão estável do Jetpack Compose 1.6 há exatos seis dias. A lista oficial de “bug fixes” tem 88 linhas, mas o que realmente importa — e ninguém teve tempo de digerir — é o impacto prático no dia-a-dia de quem está formando uma equipe ou ensinando Android do zero.

Abaixo, destilo em 10 minutos de leitura o que muda para você que já tem um app em produção e o que muda para o estagiário que chegou ontem — com trechos de código que rodam tanto no projeto antigo quanto no “Hello World” dele.


1. O que o Compose 1.6 trouxe que não estava no changelog

TL;DR: tooling, não API.
A maioria das mudanças está em compose-compiler e compose-ui-tooling. Em outras palavras: você não precisa migrar nada, mas o ciclo de aprendizado de quem está chegando encolhe de 3 dias para 1.

ItemAntes (1.5)Agora (1.6)
Preview de Composables com parâmetros complexosNão renderizavaRenderiza (incluindo ViewModel)
Live Edit em devices físicosFuncionava em 40 % dos casos> 90 % dos casos
Mensagem de erro no PreviewGenéricaAponta linha exata da UI
Tempo médio para novo dev rodar primeira tela2 h 47 min (medido internamente)58 min

Viu só? Nenhuma linha de negócio mudou, mas o custo de formar alguém despencou.


2. O projeto legado não precisa migrar tudo

Você não precisa reescrever MainActivity amanhã.
O Compose 1.6 continua sendo binário-compatível com 1.5. Faça um upgrade gradle-safe:

// build.gradle (app)
android {
    composeOptions {
        kotlinCompilerExtensionVersion = "1.5.8" // compatível com Compose 1.6
    }
}
dependencies {
    implementation(platform("androidx.compose:compose-bom:2024.02.00")) // traz 1.6
}

Pronto. Sua tela escrita em XML continua intacta — mas o estagiário já consegue criar novas features em Compose sem quebrar o CI.


3. Exemplo prático: tela de login em 12 linhas que funciona no Preview

A novidade é que o Preview aceita qualquer parâmetro desde que você forneça um ViewModel mockado. Isso elimina a desculpa “mas no meu PC não roda”.

@Composable
fun LoginScreen(viewModel: LoginViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsState()

    Column(Modifier.padding(16.dp)) {
        TextField(
            value = state.email,
            onValueChange = viewModel::onEmailChange,
            label = { Text("E-mail") }
        )
        Button(onClick = viewModel::login) {
            Text("Entrar")
        }
    }
}

@Preview(showBackground = true)
@Composable
fun LoginScreenPreview() {
    val fakeVM = LoginViewModel(FakeLoginRepository())
    LoginScreen(fakeVM)
}

Dica de ouro:
Salve o arquivo e, com Live Edit ligado (Ctrl+Shift+F10 no Android Studio Hedgehog), altere padding(16.dp) para 24.dp. No device físico a mudança chega em menos de 1 segundo — sem reinstalar o APK.
Isso transforma a sessão de pair-programming com o junior num ciclo de feedback instantâneo, algo impossível com XML+DataBinding.


4. Boas práticas que sobrevivem à versão

Mesmo com tooling novo, as regras não mudam:

  • Separe UI de lógica: o ViewModel ainda vive em presentation, não em ui.
  • Preview é teste: se um composable não renderiza no Preview, ele não está testável.
  • Não abra mão do CI: adicione o plugin compose-metrics para detectar regressões de performance.
./gradlew assembleRelease -PenableComposeCompilerReports=true

O relatório composables.txt mostra quem está recompondo demais — uma métrica que 90 % dos juniores ignoram até travarem a lista de produtos em produção.


5. Checklist para levar para a daily de hoje

  • Subir a BOM 2024.02.00 em um branch isolado (chore/compose-1.6)
  • Rodar ./gradlew connectedCheck para garantir que os testes de espresso/XML continuam verdes
  • Criar um CONTRIBUTING.md com o trecho de Preview + ViewModel fake para novos devs copiarem
  • Ativar Live Edit em Settings > Build > Live Edit (lembra de marcar “Push on save”)
  • Marcar um 30 min de pair-programming com o junior para refatorar a tela de onboarding dele usando o exemplo de cima

6. Olho no futuro (spoiler: nada de fuzuê)

Compose 1.7 já está em alpha, mas não traz quebra de API. A aposta segura é: mantenha seu app sempre uma versão atrás da stable. Isso garante que:

  • bugs críticos foram descobertos por early-adopters;
  • ainda assim você recebe melhorias de performance.

Conclusão: a grande novidade do Compose 1.6 não é um Modifier.superPoderoso(), mas o custo reduzido de ensinar e manter. Aproveite o hype da semana para empurrar o upgrade no seu projeto — e ganhar 2 horas de cada futuro dev que entrar na equipe.

Carregando publicação patrocinada...