That Missing Guide To Kotlin

In 2017 Kotlin began taking the Android community by storm.  Google adopted it as a first class language, and shortly afterwards developers everywhere renounced Java in favor of the newer, sleeker language.  That change isn’t going away.

I won’t lie, when I first was exposed I didn’t see what all the fuss was about. There were tons of articles that talked about how revolutionary Kotlin was compared to Java, but other than avoiding NullPointerExceptions they didn’t seem to go in depth at all. Because of this all I saw was slightly different syntax.  Boy was I wrong.

Kotlin is not perfect, but it does have a lot to offer that you don’t really notice until you start writing code with it.  This is part 1 of a 3-part piece will dive deeper into some of the things Kotlin has to offer.  Ideally after reading these posts you’ll have a better idea of how Kotlin can make your codebase shorter, more efficient, and easier to read.

Let’s start with the basics

Before we get into anything fancy, let’s explore a very basic concept that Kotlin offers: type inference.  In Java when you’re declaring a variable you have to do two things.  First you have to say what type your value is going to be (String, int, byte, etc.).  Second you have to name your variable.  Additionally you can set the variable to a value, or if it’s a member variable you can let it default to null, 0, or false depending on its type.

Kotlin tries to alleviate this (even if it’s not that painful) with type inference.  The compiler is smart enough to know what kind of value you’re working with based on what you set it to. Instead of writing

You can write

var is the generic term for variable in Kotlin, and the compiler knows that we’re dealing with a String because the value “hello” is a string.  Ok, that’s really not very cool. But compare these three lines in Java and Kotlin:

A small difference, but once you start writing with it you’ll be surprised how nice it is to not have to give that split second to declaring the right type.  The var keyword will work for any type that we attempt to put in it, even customized classes.  The keyword val functions the same way except its value is final.  In fact, everything in Kotlin is declared final by default unless otherwise specified (more on that later).

Saving Space

Ok, so we can replace a type declaration with the words var or val.  That doesn’t really save us a ton of time or space in our code.  Let’s look at something a little more impressive: Constructors.

Let’s say the app your building has a database that you need to get into to provide users with information.  To manage this data you’ve built the class DataManager.  Here it is in Java:

And here it is in Kotlin.

What’s happening here?  Well we’re declaring the class the same way with the words “class DataManager”, but Kotlin allows for an inline constructor.  This means we can create our constructor inside of the class declaration by adding our parameters “variable1” and “varaible2”.  Notice that we had to declare the types of each of these two variables along with the word val.

But…Type Inference

This seems to go against what we just learned about type inference, but don’t worry its not.  Along with the type inference we’ve seen so far you can declare the type.  There are some situations where both are necessary/appropriate (such as an inline constructor).  What this code is doing is saying that our class will have two var’s that are Strings, but since we haven’t actually created an instance of the class yet there’s no way our compiler would be able to know the values are Strings unless we explicitly declare them to be.

By including val before each parameter we ask Kotlin to both use it as a constructor argument as well as declare it as a member variable for the class.  And Kotlin classes also take care of getters/setters for us automatically, so we don’t need to write those.

From 20 to 2

So by declaring my two member variables inline I’ve knocked my code down from 20 lines to 2.  Yes, 10 times less code.  Obviously not everything changes this drastically, but this is a great example of how Kotlin can both speed up your coding as well as make it neater.  And really by no means does the readability suffer here.  Reading this Kotlin code we can see clearly that DataManager takes 2 parameters in its constructor, and unless we specify otherwise, Kotlin will always take care of our getters and setters.

Again, this is just one instance where Kotlin saves code, but we could take this example even farther by overloading our constructor with default values.  That’s an example for another Kotlin post down the road, but hopefully even this one gives you a taste of how your codebase can shrink when you convert it.

If you want to go DEEP down the Kotlin rabbit hole, then Phonlab offers classes on it in the Android App Development course.  I’d highly recommend you check it out, as well as stay tuned for part #2 of this!