Back

Why We Decided to Give Kotlin a Try

Down

Dec 26, 2017

Applikey Team

Author

The Problem

At Applikey, we are always searching for ways to help us produce great work at great value for money for our customers. As we mostly develop the applications for start-ups, finding and exploiting the most efficient technologies means we can reduce the amount of code we write, which in turn means we spend less time debugging and testing which means we can release the product faster and decrease the development cost.

We primarily use Java in our Android development. It’s a widely-used programming language with a long history. But that can be a double-edged sword; because Java is such a mature language, there’s a large amount of boilerplate code, components, and outdated constructions. These constructions are the “legacy” of the past, and they will never be removed from Java and as new concepts are introduced it only adds to that problem.

As we generally use Java for Android development where the average project is short, it’s not a good thing.

There is the solution which we were keen to investigate called Kotlin.

Kotlin?

Of course, there’s a lot of information around the Java language already, however, there are still are some people who have not yet managed to try it so this article aims to share our experiences of trying Kotlin.

As the product website says, Kotlin is a “Statically typed programming language for the JVM, Android and the browser, 100% interoperable with Java”. There seemed little down-side to trying it as we could still use our favorite Java solutions, and, if we failed at any point using Kotlin, we can just write Java code in it without or almost without any issues. Sounds very good, doesn’t it?

Why use Kotlin?

Let’s start by taking a look at some of the claims made on their official website.

“Concise — Drastically reduce the amount of boilerplate code you need to write”. Boilerplate code is a problem so any way of reducing it is welcome because we don’t like reinventing the wheel and writing the same code over and over again.
“Safe — Avoid entire classes of errors, such as null pointer exceptions”. Introducing null was, as its inventor famously said, “a billion-dollar mistake”. Feel free to read about it in the appropriate blog post. As plenty has already been written about this we will not dwell on it any further here other to say that this would be a huge benefit.
“Versatile — Build server-side applications, Android apps or frontend code running in the browser”. We were principally interested in Kotlin to aid our Android development, but if you use Java for web-development this would still likely be a big advantage. Or you can use your Android development experience to lower the entry barrier for web-development. And, due to its broad technology scope, Kotlin has a nicer perspective so we believe the chances of it spreading widely are very high.
“Interoperable — Leverage existing frameworks and libraries of the JVM with 100% Java interoperability”. This means that we can reuse our favorite frameworks while working in a new environment so we don’t have to leave all the fancy stuff we developed which is a huge bonus.
“Tooling — Command Line Compiler or First Class IDE Support. Freedom to choose”. Of course, we love our IDEs, but externalized tools allow us to be more flexible, and even work in the cloud. We do not want to concentrate on this feature within the scope of this post, but, for example, Kotlin already has a nice CI support, or even code coverage tools support.

Kotlin allowed us to migrate without a great deal of pain, and it’s easy for developers who already have a good background in plain Java Android development to adopt.

Finally, it’s an alternative to Java in the Android development marketplace and choice increases competition and competition in turn increases innovation and quality which is always welcome. The hope is that if Kotlin increases in popularity, we’ll maybe see some new features or tools in Java and Android itself.

What might be the downsides?

First of all, Kotlin may build slower. See this article for details. Although it may build in broadly the same time, the forecasted worse-case scenario is an increase of up to 20%.

The second problem is the number of methods Kotlin already has. It’s about 5K entries. As we all know, the default dex table allows us to use only 65K methods, so we instantly lower the available amount, and will more probably have to use multi-dexing. Multidex lies beyond the scope of this post, but in brief, it can also slow down the build time by a lot. That said, the Play Services, for example, have about 100K methods in total, so by comparison, 5K doesn’t look that bad.

Lastly, it’s easy to call Java from Kotlin, but calling Kotlin from Java is not that simple.

Practice

Talk is cheap, show me the code, right?

Null Pointer safety

Java

Kotlin

setSupportActionBar(toolbar);

ActionBar actionBar =

getSupportActionBar();

if (actionBar != null) {

getActionBar().setTitle("Toolbar

title");

getActionBar().setSubtitle("Toolbar

subtitle");

}

setSupportActionBar(toolbar)

supportActionBar?.title = "Toolbar

title"

supportActionBar?.subtitle = "Toolbar

subtitle"

As you can see, Kotlin provides fancy null checks out of the box and reduces the boilerplate.

Extension Methods

Java	Kotlin
abstract class BaseFragment extends Fragment { void setTitle(String title) { ((AppCompatActivity) getActivity()).setTitle(title); } }	fun Fragment.setTitle(title: String) { activity.title = title }

All collections are immutable by default.

Java	Kotlin
We have to use Guava or write out our own immutable collections	List<>... MutableList<>...

Functional methods (for example, Stream API)

Java	Kotlin
List<items>items; Stream.of(items).map(item-> item.getMessage()).forEach(message-> Log.d(TAG, message));	val array = arrayOf(); array.map{it.getMessage()}.forEach{ Log.d(TAG, message)}

Default overrides

Java	Kotlin
void sum(int a, int b, int c) { //action... } void sum(int a, int b) { //action... } void sum(int a) { //action... }	fun sum(a:Int=0, b:Int=0, c:Int=0){ //action.. }

Kotlin provides us with an ability to write far less code here. You can see the example with default values for parameters. And, if you are still not convinced, feel the difference between switch statements.

Java

Kotlin

Fragment getFragment(int pos) {

Fragment fragment;

switch (pos) {

case 0:

fragment = new Fragment();

break;

case 1:

fragment = new Fragment();

break;

case 2:

fragment = new Fragment();

break;

default: throw new

RuntimeException("unknown

position");

}

return fragment;

}

val fragment: Fragment

when (pos) {

0 -> fragment = Fragment()

1 -> fragment = Fragment()

2 -> fragment = Fragment()

else -> throw RuntimeException

("unknown position")

}

return fragment

}

Or even

val fragment: Fragment

return when (pos) {

0 -> fragment = Fragment()

1 -> fragment = Fragment()

2 -> fragment = Fragment()

else -> throw RuntimeException

("unknown position")

}

Looks shorter, isn’t it?

There are even more cool features Kotlin brings us; it supports lambdas and Rx by default, allows us to quit using ButterKnife as it can automatically bind resources to variables by their names, and lots of other useful features that greatly reduce the amount of time we spend on actual coding which is time we can use thinking.

How to start

First off, read the official reference. You’ll get all the necessary information about language constructions, API, and will be ready to start using Kotlin.

Second, you may read the Kotlin for Android Developers book. It shows the examples of building an Android application from scratch using Kotlin and will give you some practical experience and tips.

And the last step I can suggest — use it. Practice builds knowledge and skill. Start with a pet project and search for an opportunity to apply Kotlin in a production setting. You might want to, for example, start by writing test scripts — it won’t affect any components of the system, and won’t even affect other tests, so it will be a good starting point.

Conclusion

Based on our experience, we would certainly recommend you give Kotlin a try in in your next small project. It brings a lot of fancy features and makes the development process a bit easier. And even if you fail, you can continue writing your code in Java almost without drawbacks.

Using Kotlin, we can develop faster because it does a lot of stuff for us. We can use modern technologies and techniques. A lot of things we already use now (Rx, codegen) are supported out of the box.