let me tell you how you should build your gradle structure

Murat Can Bur
Jan 20, 2016 · 4 min read

organize your dependencies in a better way…

at the first step, you have two different gradle build files in your app. These are called Project Build File and Module Build File.

Project Build File

the project-level Gradle file uses buildscript to define the Gradle repositories and dependencies.

ext {

}
ext {

configuration = [

package : "co.mobiwise.moviebox",
compileSdkVersion: 23,
targetSdkVersion : 23,
minSdkVersion : 16,
buildToolsVersion: "23.0.1",
]

libraries = [
butterknife : "7.0.1",
supportVersion : "23.1.1",
retrofit : "2.0.0-beta3",
retrofitConvertor: "converter-gson:2.0.0-beta1",
rxjava : "1.0.10",
rxandroid : "1.1.0",
rxadapter : "2.0.0-beta1",
okhttpVersion : "2.5.0",
dagger : "2.0",
dagger_compiler : "2.0",
javax_annotation : "10.0-b28",
otto : "1.3.8",
]
}

Application versioning

the Google Play Store uses application version code in order to detect new versions of the application. There is a common way to give version to your application. That is called Semantic Versioning (the traditional major.minor.patch versioning). You might not use the traditional major.minor.patch versioning for your Android application. Anyway, I am going to share the way I follow:

versionMajor = 0
versionMinor = 0
versionPatch = 0
versionBuild = 1

versionCode = versionMajor * 1000000 + versionMinor * 10000 + versionPatch * 100 + versionBuild
versionName = "${versionMajor}.${versionMinor}.${versionPatch}"

Module Build File

The application module Gradle build file allows you to configure defaultConfig and productFlavors, buildTypes, dependencies.

def configuration = rootProject.ext.configuration;
def libraries = rootProject.ext.libraries;
compile "com.squareup:otto:${libraries.otto}"

defaultConfig

you can define manifest properties like your base applicationId, minSdkVersion, targetSdkVersion, versionCode, versionName here.

defaultConfig {
applicationId configuration.package
minSdkVersion configuration.minSdkVersion
targetSdkVersion configuration.compileSdkVersion
versionCode rootProject.ext.versionCode
versionName rootProject.ext.versionName

buildConfigField STRING, GIT_SHA, "\"${gitSha}\""
buildConfigField STRING, BUILD_TIME, "\"${buildTime}\""
buildConfigField STRING, REST_ENDPOINT, '""'
}
buildConfigField STRING, BUILD_TIME, "\"${buildTime}\""
buildConfigField INT, DATABASE_VERSION, '14'
buildConfigField STRING, USER_EMAIL, '""'
buildConfigField STRING, USER_PASS, '""'

productFlavors

we might need to add flavor that builds a different edition of the application. Think a scenario that you need to have two different apk editions. One is going to call your development server and database, and the other one is going to call your production server. In this case you need to define two different flavors that might be called dev and prod.

productFlavors {
dev {
buildConfigField STRING, REST_ENDPOINT, '""'
}
prod {
buildConfigField STRING, REST_ENDPOINT, '""'
}
}

Worth to mention;

I started a a sample project that shows you how to architect an android application and follow Material Design rules. While I develop this sample application, I want to write a blog post about libraries every Android programmer should know(Android and Electrons), Design support library, DI with Dagger2, how to use RxJava and Retrofit together and so on.

mobiwise blog

Mobile Wisdom

Murat Can Bur

Written by

Blogger, Android Developer

mobiwise blog

Mobile Wisdom