Thursday, May 7, 2015

Gradle tip - Read the changelog of the Android Build Tools

Read the change log of the Android Build Tools - This line in the build.gradle:
buildToolsVersion "x.y.z"
Controls the actual wrapping of your Android app. Be cautious when upgrading it and brief through the release notes to understand impacts.

Monday, April 20, 2015

Gradle tip - Always choose dependencies explicitly

For the sake of your CI process and versioning (the ability to go back in time in your SCM and get the same result) - always use explicit versions in your maven dependencies.
compile "some.library :21.0.3"
compile "some.library :21.0.+"
Also, use the same gradle version (that can be easily achieved using a gradle wrapper) .

Sunday, April 5, 2015

Gradle tip - Prefer a remote maven dependency

Prefer a remote maven dependency over a local jar. Just because it makes your build easier keeps your SCM lighter, and lets you easily change versions.

Monday, March 30, 2015

Gradle tip - Set names to your modules

Set names to your modules/sub-projects. The name for your module/sub-project will be defined according to the filesystem directory it's in. You can change naming for better readability later on, using:
include ':SDK'
project(':SDK').projectDir = new File('MySdkProjectDirectory/')

Tuesday, March 10, 2015

Gradle tip - Leverage a top-level build.gradle

Usually a project contains more than one sub project or module. In that case you will want to have common settings that will be shared among them, saving you the trouble of rewriting them or maintaining future changes. A common setting will be the Android's buildscript dependency - classpath ''

Thursday, February 19, 2015

Gradle tip - Always use a gradle wrapper

The wrapper sits in your project and defines a common build behaviour for all your team and CI tools. 

Why not use a local gradle installation? 
A. You will find yourself out-of-sync with other team members
B. You won't be able to run your project without pre-installing stuff (bad for CI implementations)
C. Your project build behaviour won't be tracked in git, which will cause problems going back to old revisions.

A gradle wrapper version is set in - Only thing that needs to change in a gradle wrapper is the distributionUrl. It marks which gradle version should be used.