The Social App: Kotlin Setup

If you don’t know about this project’s motivation, read the first post here.

In the previous post, we set up CircleCI to watch the branches of our project, as well as opening pull requests in the repository. Today, we’ll take a closer look at the project and start structuring it to begin the implementation later.

The project itself was built from the standard Android Studio 3.1.1 template, without any modification to its structure, and without the inclusion of Kotlin by default. My intention here is to understand what it takes to turn an Android project with Java into an Android project with Kotlin.

The first step is to adjust the main build.gradle file, the one located at the root of the project. Initially, we will remove comments from the template. They are informative about how to configure the dependencies of the project. However, we can remove them since we already know where we are going to put each piece of configuration.

The next step is to create a variable, called kotlinVersion, to save the version of Kotlin we’ll be using in the project. It is good to keep this version in a unique place, since it must be the same in all dependencies related to Kotlin in the project. Here’s a caveat: notice that we used Camel Case to name it (while the AS template for Kotlin uses Snake Case). Groovy (language used in Gradle scripts) has code conventions very similar to Java. Thus, we use Snake Case only in cases where the value is a constant, and always in the upper case.

After that, we add the Kotlin plugin to Gradle, making use of string interpolation to insert the version. So the build.gradle file looks like this:

buildscript {
  ext.kotlinVersion = '1.2.31'
  repositories {
    google()
    jcenter()
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:3.1.1'
    classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlinVersion"
  }
}
allprojects {
  repositories {
    google()
    jcenter()
  }
}
task clean(type: Delete) {
  delete rootProject.buildDir
}

Now let’s edit the app module build file (located in app/build.gradle). Here, we first apply the Kotlin plugin, following the naming convention recommended by Gradle — using the namespace. So, we apply the org.jetbrains.kotlin.android plugin. Next, let’s add the Kotlin’s standard library. This dependency has 3 versions: kotlin-stdlib (Java 6), kotlin-stdlib-jre7 (Java 7) and kotlin-stdlib-jre8 (Java 8). Particularly I add the jre7 version, first because our minimum API is KitKat (which already supports Java 7 features). We could use jre8; however, this would trigger the desugaring process during compilation, which can impact our build time.

Finally, two points of adjustment that I particularly recommend for making our script and project more organized. The first one is the addition of specific source sets for Kotlin. When we have a Java project, the source files are usually in the src/main/java folder. Thus, we add to source sets src/main/kotlin. In my opinion, this organization is particularly useful when the project ends up having files from both languages ​​(which should not happen in our case) and for the directory structure to become more semantic. The second one, more aesthetic point of adjustment, is the standardization of the use of single and double quotation marks in the file. Let’s use double quotes only when there is an interpolation in the string.

Our file, then, looks like this:

apply plugin: 'com.android.application'
apply plugin: 'org.jetbrains.kotlin.android'
android {
  compileSdkVersion 27
  defaultConfig {
    applicationId 'net.rafaeltoledo.social'
    minSdkVersion 19
    targetSdkVersion 27
    versionCode 1
    versionName '1.0'
    testInstrumentationRunner 'android.support.test.runner.AndroidJUnitRunner'
  }
  sourceSets {
    main.java.srcDirs += 'src/main/kotlin'
    test.java.srcDirs += 'src/test/kotlin'
    androidTest.java.srcDirs += 'src/androidTest/kotlin'
  }
  buildTypes {
    release {
      minifyEnabled false
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
  }
}
dependencies {
  implementation 'com.android.support:appcompat-v7:27.1.1'
  implementation "org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlinVersion"
  testImplementation 'junit:junit:4.12'
  androidTestImplementation 'com.android.support.test:runner:1.0.1'
  androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
}

As we are modifying the build configurations of our project, I recommend updating the version of Gradle that is being used. To do this, just generate the wrapper targetting the latest version (4.6 at the time of writing this post). Unless there are incompatibilities between the Android plugin and Gradle, I always recommend using the latest version of Gradle, since it often brings important performance improvements (which is always welcome). To update the wrapper, just run the following command:

./gradlew wrapper --gradle-version 4.6 --distribution-type all

As we didn’t add an Activity when creating our project, I also added an empty MainActivity and added it to Android Manifest. Just to keep the repository clean, I excluded the tests that come by default in the Android Studio template — once we start entering the features of the app, we’ll write our own.

Following our Git Flow, I created a Pull Request for the branch develop, which, as soon as it passed in the CI, was merged 🙂

So, that’s it. Although this post does not show anything very new, I believe it is essential to configure Kotlin for ourselves and know what it changes in the project. After all, build scripts are also code, and keeping them organized is part of the health of the project.

Thanks for reading, and see you soon!