Acessando dependências de projeto com type-safe no Gradle
Ao desenvolver um projeto Android modularizado é esperado que se tenha vários módulos e que alguns sejam interdependentes. Entretanto, conforme o projeto cresce, vai se tornando cada vez mais difícil manter o controle do nome e localização dos módulos, o que pode levar a situações onde se perde algum tempo tentando lembrar essas informações, ou até mesmo a erros de compilação.
É bastante comum ter linhas de código similares no nosso build.gradle quando declaramos as dependências de projeto:
dependencies {
implementation(project(":features:login"))
implementation(project(":libraries:ui"))
}Felizmente, no Gradle 7.0, a versão necessária para o Android Studio 2020.3.1 Arctic Fox, uma nova forma de acessar os projetos foi incluído: o type-safe project accessors.
Configurando
Em primeiro lugar, tenha em mente que essa funcionalidade ainda é experimental. No momento em que esse artigo foi escrito, a última versão estável do Gradle é a 7.2, mas é esperado que essa funcionalidade se torne estável nos lançamentos futuros.
Para habilitar essa funcionalidade no seu projeto, precisamos adicionar a seguinte linha no nosso arquivo build.gradle(kts):
enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")Acessando os módulos
Após adicionar a linha habilitando a funcionalidade experimental e sincronizar os arquivos Gradle, é possível acessar os módulos de uma nova forma. Agora ao invés de adicionar a localização e nomes dos módulos de forma hard-coded, nós temos uma maneira muito mais segura, incluindo o auto-complete do Android Studio para nos ajudar. Vamos dar uma olhada na nova abordagem:
dependencies {
implementation(projects.features.login)
implementation(projects.libraries.ui)
}
Outra ótima adição que essa funcionalidade traz é ter erros de compilação mais inteligentes. Anteriormente, se algum módulo fosse renomeado ou movido, o script iria falhar quando tentássemos rodar o aplicativo. Ao usar o type-safe project accessors, o erro será mostrado com mais contexto:
Dicas gerais
Todos os projetos/módulos são mapeados a partir da raiz do projeto, o que significa que se um módulo fica localizado em :libraries:commons:ui, logo o seu acesso será feito em projects.commons.ui e assim por diante.
Além disso, quando um módulo é criado com kebab case ( some-module-api) ou snake case ( some_module_api), ambos serão convertidos para camel case ao usar essa funcionalidade ( projects.someModuleApi).
E agora?
Se você quiser se aprofundar no código, por favor dê uma olhada no Pull Request enviado para o Alkaa atualizando as referências hard-coded para esse novo formato.
Durante meus testes, eu apenas consegui que o auto-complete da IDE funcionasse usando arquivos build.gradle.kts. Existe o suporte para arquivos build.gradle entretanto eles parecem não ter um suporte tão rico quando os .kts.
Conclusão
Por anos nós tentamos melhorar o gerenciamento de dependências com Gradle, e com o type-safe project accessors damos um grande passo nesse objetivo. A segurança que o type-safety e auto-complete trazem ajudam muito, levando a menos erros e acelerando o desenvolvimento enquanto focamos no que realmente importa: a nossa aplicação.
Pessoalmente, eu estou muito animado com todas as novas mudanças que o Gradle vem recebendo nos últimos anos. Eu sinto que o time de desenvolvimento realmente está nos ouvindo e agindo para fazer nossa vida mais fácil. 😊
Referências externas
Para mais informações sobre o novo type-safe project accessors, eu recomendo a documentação oficial do Gradle.org. Se você encontrar problemas ao utilizar essa funcionalidade no desenvolvimento Android, por favor abra um chamado no Issue Tracker para ajudar o time e a comunidade.
Muito obrigado por ler meu artigo. ❤️
