Previously in this series we’ve created a basic Gradle build-based project, and looked at the build configuration. In this article we’ll have a look at the default structure for storing source and resource files, and look at how we can change this structure.
Up to now we’re seen that our source and resource files are stored within the
src/ directory within our Android project, but not looked any deeper in to this structure. This folder contains a single folder named
main/ which contains all of our source and resources, but why do we need this? The simple answer is that we can have multiple source trees to perform different tasks. For example, if we want to start adding test code, we can create a new source structure inside a folder named
test/ and this will keep our test code and any required resources separate from our the main code that it actually tests. Under the old build system we’d have to create a separate project containing our tests, but under the Gradle build system we can include the test code within the same project, but under a different source tree.
main/ folder we have two child folders named
res/. Hopefully this is fairly self-explanatory that the former contains our Java code, and the latter contains our resources. The structures below these two folders are the same as we’re used to: The
java/ folder contains our Java source within its package hierarchy; and the
res/ directory contains our resources in the standard hierarchy which supports the configuration qualifier components within the directory names (i.e. having different resource folders containing resources for different screen sizes, display densities, languages, etc., etc.).
Another important thing to note within the
main/ folder is that it also contains our
AndroidManifest.xml. The reason for this is that different source trees may result in different build artifacts being created. For example, the
main/ source tree will produce the APK for the project, but the
test/ source tree may create a different executable which will run the necessary tests. This may, itself, be an APK that requires a different Manifest. Therefore we can have different Manifests for these different artifacts, and they are stored within the appropriate source tree.
This may seem a little daunting at first, but it really does make a lot of sense – it just requires to think a little differently about how the source is organised. Having said that, this new structure can actually be modified to suit our requirements. As an example of this, I recently updated my PresenterLite application to include a new Animations presentation. I wanted to keep this new presentation separate from the existing presentation on Android Layouts, so I wanted to create the resources for each in its own folder. Under the old build system this would have been rather difficult, but I converted the project to a Gradle build and was able to achieve what was required.
Engine/src/main/ folder I have created a new folder named
presentations/ in addition to the existing
res/ folders. Inside this I created two folders named
animations/ which contain the two presentations; and each of these contains a resource tree. It is worth remembering that when the build is run, these resources will be merged together so we must be careful to avoid file naming conflicts. For example, if we had two layouts named “title.xml” then this would result in a single file with undefined results (I say undefined because I didn’t bother to try it as I thought it would cause me problems). So I made a point of prefixing all of the layouts with the name of the presentation (“layouts_title.xml” and “animations_title.xml”) to avoid any such conflicts.
It is worth noting that there is an
arrays.xml in each of the presentation projects, and these get merged together during the build. So it is perfectly aceptable to have multiple resources which will get merged, but layouts are generally identified by the name of the file they are stored in, so conflicts here could be much more problematic than for value resources which have a declared name for each individual entry.
Creating these new resource trees is easy enough, but how about configuring the build to recognise them? This is done by modifying
Engine/build.gradle – the build configuration file for the
Engine library. We can modify the
android section to override the resource directories used for the build:
srcDirs = [
sourceSets value specifies the sources used within the build. This is hierarchical, and we are specifying the that we’re changing the resource directories within the main tree. Remember that Gradle uses convention over configuration, so we only need to specify what is different to the defaults. In this case the java source is using the defaults, and we are only overriding the resource directories. By providing an array to the
srcDirs, we specify multiple directories which will get merged before the resources are processed and the
R.java file being generated.
If we look at the output from the build commands that we’ve run previously we can see that once of the tasks which is run during the build is a merge resources task, which gets run separately for debug and release builds, and is run before the process resources task:
GradleTestProject >./gradlew assemble --daemon
The TaskContainer.add() method has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the create() method instead.
Total time: 1.852 secs
So we are able to create what appears to be a much more complex project, but the changes to the build configuration are relatively minor – which begins to show quite how powerful the Gradle build can be, while still remaining pretty simple.
In the next article we’ll look at Android Library projects and how much simpler they are using the Gradle build.
The source for PresenterLite which demonstrates multiple resource trees is available here.
© 2013 – 2014, Mark Allison. All rights reserved.
Gradle Build – Part 3 by Styling Android is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Permissions beyond the scope of this license may be available at http://blog.stylingandroid.com/license-information.