The real challenges when adopting Kotlin
For Android devs, Kotlin, the new cool kid and rising star in town, doesn’t require much of an introduction. We take you through the challenges we encountered while adopting Kotlin, and the best practices we uncovered in the process.
Kotlin is a fairly new programming language, developed by Jetbrains, that recently started gaining some serious traction in the Android community. As an Android developer, you probably know about its selling points by now, so we’re not going to bother rehashing them all – we think you can find a great recap in this article.
Instead, we wanted to talk about the real challenges you’ll run into when you start using Kotlin within your company. And no, we don’t mean the fact that Google doesn’t officially support it, nor the fact that your entire app is written in Java.
Although both are valid points, they can be tackled fairly easily. No official support? Doesn’t matter – we think Kotlin is here to stay. Jetbrains has over twenty people working on the language, and they are committed to supporting it for the future. Moreover, parts of IntelliJ are written in Kotlin, the Gradle build script supports Kotlin… And as far as IDE support is concerned: Android Studio is built upon Jetbrains’ IDE IntelliJ IDEA.
Yes, Google will probably break Kotlin support in a future canary/unstable version of Android Studio, but as we have seen multiple times in the past, Jetbrains will release a fix for that within a matter of days – which is months before the next stable release of Android Studio hits.
And the fact that your app is written in Java? Not a huge problem either! You don’t have to rebuild your apps: Java and Kotlin work perfectly together. A good starting point would be to start using Kotlin in side projects, stand-alone libraries and non-production code like unit tests.
The real problem is the fact that your team only speaks Java.
But, having seen what Kotlin can do, we decided to give it a try. We started with a small temporary project, written entirely in Kotlin. At first, being new to the language, we were basically writing Java in Kotlin syntax. But soon, we started to really think in Kotlin, found its best features and wrote a couple of super useful extensions which made our lives a lot easier.
And so, as you’ve probably guessed by now, we started to become huge Kotlin fans. We couldn’t help it: writing a single line in Kotlin where we’d have needed 3-5 lines in Java is just extremely satisfying.
Taking Kotlin team-wide
But now, the real challenge faced us. Being convinced of its values, our entire Android Team needed to be able to read and write code in Kotlin. However, we don’t have a lot of small temporary projects that we could use to allow everyone to become confident with Kotlin.
To make sure we got everyone on board regardless, we started with a Kotlin workshop during one of our Android Afternoons. We explained some key features, gave everyone the opportunity to write some code in Kotlin and gave them a few challenges to solve with a single line of code.
After the workshop, we started to share impressive Kotlin tricks with our team, so we could all quickly learn from each other. This was also an opportunity to spot some rookie mistakes and improve the code while we were still working on it.
But for everyone to get some real experience, we needed something better than a 2-hour workshop and some code samples. So, we decided to start by writing a simple Android Studio Plugin in Kotlin.
With that under our belt, we wanted to create a more complex project as well. At November Five, we make a lot of internal tools, which every member of the team can work on. That’s why when discussing the requirements of a new tool, we decided to train ourselves by writing this in Kotlin. It was the perfect guinea pig for learning Kotlin and experimenting with it – without risking the stability and features of our apps.
Trouble in the library
Although we now had a platform where everybody could learn Kotlin, we still had some more problems to solve.
Over the years, we’ve created a lot of Android libraries at November Five, but they were all written in Java. As mentioned before, Java and Kotlin work great together. But because Kotlin contains more features than Java, we had to make sure our libraries worked flawlessly within Kotlin. While most of our libraries worked fine, we did find some best practices for preparing your libraries for use in Kotlin.
Kotlin fixes Java’s nullability issues. However, while this works great within Kotlin, it doesn’t work that well when combining Kotlin and Java. The issue boils down to the fact that in Kotlin, we can specify if a reference can be null or if it’s forced to have an object linked to it. In order to improve compatibility, you have to add Nullability Annotations to your Java code.
There are multiple implementations of these annotations available online. We prefer to use the one created by Google, as it contains other useful annotations as well. While these annotations only generate warnings within Java, Kotlin supports these annotations and forces the nullability information they provide.
As a general principle you want to make sure to keep great Java interoperability with your Kotlin libraries, so that you can use them in Java-only projects when necessary. We found this to be very doable, thanks to some great annotations provided by Jetbrains – at least, as long as you keep Java interoperability in mind from the start.
As you don’t want to clutter your Java libraries with Kotlin-specific code, you should create specific modules for use only in Kotlin projects. For example, you could have a ‘media’ and ‘media-kotlin’ module. The first one would contain most of the business logic, while the latter optimizes the use of the library within Kotlin. By using Kotlin extensions, you can extend the core functionality of your libraries and improve the syntax and usability when programming in Kotlin.
As for Kotlin-specific libraries, we already made a Kotlin Extension library! This contains some of the best and most useful Kotlin Extensions we could come up with. Some of these will definitely end up saving us more time than it took us to master Kotlin – and we’re only just getting started!
We really like the Android platform, but a lot of things are just overcomplicated.
Kotlin makes it possible to do far more than we were able to with Java, including solving problems Java simply couldn’t solve.
So, what’s next for Kotlin at November Five? Will we forget about Java and write everything in Kotlin? Well, no. But we will be using Kotlin for a lot more projects and tools in the future, and we can’t wait to see what the next versions of Kotlin will bring us.