When developing a modularized Android project it is expected to have many modules and some of which are interdependent. However, as the project grows, it becomes harder and harder to keep track of the modules location and names, which can lead to situations where one have to spend some amount of time remembering this info, or even to compilation errors.
It is very common to have similar lines in our build.gradle
when declaring the project dependencies:
dependencies { implementation(project(":features:login")) implementation(project(":libraries:ui")) }
Fortunately, in Gradle 7.0, the one required with Android Studio 2020.3.1 Artic Fox, a new type-safe project accessors was included to make out life easier.
Setting up
First of all, keep in mind that this feature is experimental at the moment. At the time that this article was written, the latest stable version for Gradle is 7.2, but this feature is expected to become stable in future releases.
In order to enable this feature in our project, we need to add the following line to our setting.gradle(kts)
file:
enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")
Accessing the modules
After adding the experimental line and syncing Gradle files, it is now possible to access the modules in a new way. Now, instead of hard-coding the modules location and names, we have a safer way, including IDE auto-complete. Let’s take on the new approach:
dependencies { implementation(projects.features.login) implementation(projects.libraries.ui) }
IDE auto-complete for Gradle modules
Another great addition that this feature brings to the table is smarter compilation errors. Previously, if some module were renamed or moved, the script would fail only when compiling the app. When using the type-safe project accessors, the error will now shown up with more context:
Compilation error when Gradle modules is not correct
General tips
All the project accessors are mapped from the project path, this means that if a module path is :libraries:commons:ui
, then the project accessor will be projects.commons.ui
and so on.
Also, when a module was created with kebab case ( some-module-api
) or snake case ( some_module_api
), both will be converted to camel case when using the accessors ( projects.someModuleApi
).
Job Offers
What’s next?
If you want to take a deep dive in the code, please take a look in the Pull Request submitted to Alkaa in order to update all the hard-coded references to project accessors.
During my tests, I only was able to make the IDE auto-complete to work when using build.gradle.kts
files. There is support for regular build.gradle
files however it seems that it does not have the same powerful support like its .kts
counterpart.
Final thoughts
We’ve been trying for years to improve the dependency handling with Gradle, and the type-safety accessors are a huge step towards this goal. The type-safety and the auto-completion it brings to the table help a lot, leading to fewer errors and speeding up the development while we focus in what really matters: our application.
Personally, I’m very excited with all the new changes that are coming to Gradle in the last years. It feels that the team is really listening to our comments and acting to make our life easier. 😊
External reference
For more information about the new type-safe project accessors, I recommend the official docs from Gradle.org. If you find any bugs while using this feature in Android development, please open an Issue Tracker to help the team and the community.
Thanks a lot for reading my article. ❤️
Thanks to Bruno Kenji Tiba.