Initial migration to Kotlin

It’s not as easy as Bad Android Advice put it, but it’s a good starting point.

Steps 1 and 2 are kind of valid for getting started with Kotlin.

I’ll figure out how that 3rd step will play out, though.

For Topeka the route was more like this:

Read up on the basic syntax of Kotlin Go through the Koans to gain basic familiarity with the language Convert files, one by one, via “⌥⇧⌘K”, make sure tests still pass Go over the Kotlin files and make them more idiomatic Repeat step 4 until you and your code reviewers are happy Ship it

Interoperability

Going step by step is a sensible approach.

Kotlin compiles down to Java byte code and the two languages are interoperable. Also it’s possible to have both languages within the same project. So it’s not necessary to migrate all code to another language.

But if that’s your goal, it makes sense to do so iteratively. This way it’s more feasible to maintain a stable application throughout the migration process and learn as you go along.

Tests ease your mind

Having a suite of unit and integration tests has many benefits.

In most cases they are there to provide confidence that changes have not broken existing behaviour.

Starting off with the less complex data classes was the clear choice for me.

They are being used throughout the project, yet their complexity is comparatively low. This makes them an ideal starting point to set off the journey into a new language.

After migrating some of these using the Kotlin code converter, which is built into Android Studio, executing tests and making them pass, I worked my way up until eventually ending up migrating the tests themselves to Kotlin.

Without tests, I would have been required to go through the touched features after each change, and manually verify them.

By having this automated it was a lot quicker and easier to move through the codebase, migrating code as I went along.

So, if you don’t have your app tested properly yet, there’s one more reason to do so right here. 👆

Generated code is not always nice to look at ‼️

After an initial round of mostly automated migration, I went on to read up on the Kotlin style guide. This page made it clear to me that there’s still a long way ahead.

The converter does a good job, overall. There are a lot of language idioms and features which are not being taken into account during the automated process, though. Which is probably for the better, since translating is tricky. Especially if one language contains more features or achieves similar things in a different way.

For further reading on the Kotlin converter, Benjamin Baxter has written about his experience:

‼️ ⁉

After the automatic conversion I ended up with a lot of ? and !! .

These are used to make a value nullable and assert that something is not null. Which in turn can lead to a NullPointerException .

And I couldn’t help but think of a very fitting quote:

‘Multiple exclamation marks,’ he went on, shaking his head, ‘are a sure sign of a diseased mind. — Terry Pratchett

In many cases a value doesn’t have to be nullable, so null checks can be removed. It’s not even necessary to initialise all values directly within a constructor. Instead lateinit or delegate initialisation can be used.

This doesn’t work for everything though:

Sometimes vars have to be nullable nonetheless

So I had to go back and make my view members nullable.

In these and other cases you will still have to check, whether something is null . Using supportActionBar?.setDisplayShowTitleEnabled(false) only executes the part after the question mark if there is a supportActionBar .

This means a lot less if statement based null checks. 🔥

Also executing code with some of the stdlib functions directly on the non-null variable can be handy: