With the release of Android back in 2008, the go-to language for app development has always been Java – however, that’s beginning to change. At Google IO 2017, it was announced that Android would be receiving “first class support” for Kotlin. Since then, the language has been slowly ramping up to becoming the preferred language for development on the Android platform.

In the following article I’m going to give you some ways you can refactor/rewrite your existing Java app code to Kotlin, while also pointing out the advantages Kotlin gives us.

But what about Java?

I still feel like Java is worth knowing, since a lot of the Android APIs, as well as their documentation, are written in it. If you’re just starting Android development, I would reccommend developing at least an intermediate level of Java knowledge before moving on to Kotlin. If you’d like an in-depth guide to getting started with Android development, you can read an article I wrote detailing how to become an Android developer in under a year.

I should also mention that Kotlin is interoperable with Java. For this reason, you aren’t forced to choose one or the other. You’re able to call Java code with Kotlin and vise versa. So, don’t feel like you’re wasting time just because you’re learning Java.

Refactoring Java to Kotlin

I’m going to present some Java classes from my own personal projects, with the Kotlin counterpart following. The advantages Kotlin presents should be evident from simply looking at the code, but I’ll be sure to go through each.

SharedPreferences

Here’s an implementation of an interface used for managing a few SharedPreferences  values. The class is quite straight-forward, as far as preference managers go. Let’s take a look at the same class in Kotlin.

Immediately, you can already see the amount of code we need is less than that of the Java class. Not only is it less code, but it is much more concise and easier to read. You will notice we also take advantage of a few Kotlin specific features. Since we’re allowed to define our own custom setters and getters directly on class properties, we can go ahead and remove the individual set and get methods that we had in our Java code. In our changeStartingCountdown() function, we use a when expression – it is the Kotlin equivalent of a switch statement. Furthermore, we use a companion object to define our constants in. You can read more on companion objects here. Finally, we take advantage of an extension function when calling edit() on our SharedPreferences. In my project, this function comes from the Android ktx library.

Fragment

Here we have a standard Fragment class with some UI related methods. At the top of the class, you will notice the standard Butterknife annotations used to remove a lot of the findViewById() boilerplate code. I’ve also delegated all my view clicks to a single method, onViewClicked() which then calls the correct method depending on the id of the view. At the time I wrote this class, lambdas, without the use of a 3rd party library, were still unsupported in Android Studio (pre 3.0).

The biggest difference in our Kotlin equivalent class should be immediately apparent. Where are we defining and initializing our views? Thanks to the Kotlin Android Extensions plugin, we no longer have to do that. With synthetic properties, we can access our views by the exact id we give them in our layouts. The plugin is taking care of inflating and caching our views (for configuration changes)  under the hood. You may also notice I’ve removed the onViewClicked() method. Instead of a switch statement, I am now explicitly calling the presenter methods in lambdas. However, they look a bit strange don’t they? In Kotlin, if we are writing a lambda that takes one parameter, we can completely omit the use of -> – as you can see in the setOnClickListener() methods.

Model Objects

Here’s a standard model class I wrote in an older project. Notice the explicit use of writing our setters and getters in the Java code. Let’s see the Kotlin equivalent.

As standard in Kotlin, we can omit the use of  set and get methods. However, we still define them for custom behaviour as can be seen in populationColor and populationLevel. We also mark this class as a data class in Kotlin. Doing so provides our class with a number of features which can be seen here. It is worth noting that the use of the data keyword should only be reserved for model objects.

Wrapping up

If you’ve been on the fence with switching to Kotlin – I’d highly suggest you to give it a try. The language provides many great advantages over Java that make our lives as developers much easier. A good way to learn would be to refactor your older Java projects. I’d advise you start with the less complex classes and work your way up to the more involved ones such as Fragments, Activities or any code related fetching network data.