DEV Community

Rodrigo Sicarelli
Rodrigo Sicarelli

Posted on • Updated on

Android Plataforma - Parte 2: Início do Projeto

🌱 Branch: 1-2/introduction

🔗 Repositório: github.com/rsicarelli/kotlin-gradle-android-platform

⬅️ Artigo Anterior: Parte 1: Modularização

➡️ Próximo Artigo: Parte 3: Compartilhando scripts do Gradle


Neste post, vamos explorar um projeto inicial, entender os desafios de manter os arquivos build.gradle.kts e descobrir como o conceito de Composite Builds do Gradle pode auxiliar nessa jornada.


Iniciaremos a partir de um projeto simples, gerado a partir de um template padrão do IntelliJ, ao qual foram adicionados alguns módulos:

Image description

  • app: Atua como o ponto central do aplicativo, contendo a MainActivity.
  • core:designsystem: Define os principais elementos visuais, como tema, cores, tipografia e ícones do projeto.
  • features:home: Representa a primeira tela de interação, exibindo o conteúdo do módulo details.
  • features:details: Apresenta uma mensagem textual na interface.

Image description

Problema a ser solucionado

Dê uma olhada nos arquivos Gradle de cada módulo:

É possível perceber uma redundância: embora os módulos apliquem configurações semelhantes utilizando a extensão android {}, as suas dependências são diferentes.

Nosso objetivo inicial é estabelecer uma padronização nesses scripts, permitindo sua reutilização e simplificando a manutenção.

Utilizando Composite Builds do Gradle

Ao enfrentarmos desafios de gestão e manutenção de múltiplos módulos no Gradle, uma solução eficaz é o recurso Composite Builds. Esse recurso nos permite combinar múltiplos builds independentes em um só, facilitando a padronização e reutilização de scripts.

Nos próximos tópicos, mergulharemos mais profundamente no funcionamento dos composite builds, como configurá-los e como integrá-los ao seu projeto existente.

Top comments (0)