Criando aplicativos Android em 2025

Introdução ao ambiente atual de desenvolvimento de apps Android

• Build: gradle
• Configuração de build: convention plugin
• Gerenciamento de dependências: version catalog
• Adoção de build cache
• Análise de desempenho de build: build-scan
• Estrutura de módulos: separação por feature
• Rede - retrofit
• Mapeamento de JSON - kotlinx serialization
• Armazenamento persistente de dados - jetpack datastore, room
• DI - koin
• Carregador de imagens - coil
• UI - compose
• Comunicação entre View e ViewModel - flow
• Controle de qualidade de código - ktlint , konsist
• Testes unitários - junit 4

[kipsong133]

Ótimo texto, obrigado.

[ganadist]

Como alguém que, de alguma forma, acabou se estabelecendo como engenheiro de build de apps Android, deixo minha opinião...

> Build: gradle

Mesmo sendo muito grande ou complexo, é preciso usar gradle... (olhando para o horizonte)
Como os projetos abaixo estão em andamento para melhorar o desempenho de build do gradle em projetos muito grandes ou complexos, se você já usa gradle em um projeto grande, é bom se preparar para a migração com antecedência.

• https://docs.gradle.org/current/userguide/configuration_cache.html
• https://docs.gradle.org/current/userguide/isolated_projects.html

> Estrutura de módulos: separação por feature

Pessoalmente, não vejo motivo para expor as camadas de arquitetura no sistema de build.
No caso do app que eu mantenho, fazemos com que feature-api / feature-impl fiquem expostos no sistema de build como módulos.

• feature-app :
  • modelo de dados, ou interfaces integradas com outros módulos
• feature-impl:
  • implementação real da feature

Com essa estrutura, alterações no código de feature-impl não afetam outros módulos que referenciam feature-api (isolamento de dependências), o que ajuda bastante no incremental build e no aumento da taxa de acerto do build cache.

> Teste unitário - junit 4

Acho que a decisão do Google teve um papel importante nisso.

• https://issuetracker.google.com/issues/127100532
• No caso da Android Platform, o JUnit3 (com cara de JUnit4) e o framework de testes das ferramentas de build do Android é baseado em JUnit4, e o Google deixou claro que não pretende migrar para JUnit5.
  No entanto, o plugin de screenshot testing lançado recentemente é baseado em JUnit5.

[ganadist]

No entanto, para adotar tecnologias mais recentes (?), o JUnit4 frequentemente acaba atrapalhando, então pessoalmente tenho um pequeno desejo de que houvesse uma migração para o JUnit5.
https://docs.gradle.com/develocity/test-distribution/

Usando o junit-vintage-engine, é possível executar testes em JUnit4 no JUnit5 sem grandes alterações, mas o overhead é considerável. (fica cerca de 20% mais lento)

[kingori]

Que honra para a família Huh, haha.

[gera1d]

Sou o Wilson!

[brainer]

Hum... como observação paralela, nos últimos anos tem sido observado um fenômeno curioso: a maioria das startups vai de Flutter, enquanto grandes empresas como META e OpenAI vão de nativo..

[tsboard]

Eu estava justamente pensando em criar um app Android este ano, então isso foi uma orientação bem útil. haha