Kotlin: How to Get Rid of Java in Your Android Application in 5 Easy Steps

We all know Kotlin is great, right? There are more than enough posts about why Kotlin blows Java out of the water. So let’s skip this part. We also know, our next project will be written in Kotlin— But what about our projects that are in active development? Can we migrate them on the fly?

As a project house we want to keep our customers happy–and luckily our customers want us to be happy, too, so it’s very easy to convince product owners of Kotlin. We’ve seen the difficulties iOS legacy projects written in Objetive-C can cause to our customers first hand, which reinforces our argument: This should not happen to our Android projects.

Some things about code conversion

Within Android Studio you can easily convert existing Java code to Kotlin code.

While this is neat I made the experience that it’s better to create a new Kotlin class and paste the Java code to this class, so you have a backup and you’re also able to compare the converted code with the working Java code. You can easily delete the old code when you’re happy with the Kotlin code.

Please take a look at the converted code for possible flaws, especially within your method parameters, the corresponding calls and further improvements. For example check your code for nullability issues to get rid of  !! calls.

Disclaimer

Depending on the project size and setup the complete process of migrating to Kotlin can take multiple days and should–of course–be done on a seperate branch. UI tests and tests in general will save you some time and will make you feel safe while migrating your project, because you probably will receive a couple of runtime errors. (For example supplying null to a String field/parameter will result in a crash)

The migration itself can be an incremental process but at some point you have to aim for 100% . We’ll get to that in Step 5.

Lets do this.

Step 1: Test Code

You can easily start converting code in your Test Projects. It won’t affect your productive build at all and you can take a first look at the code conversion in Android Studio and get used to the quick tips Android Studio will provide you.

Step 2: POJO Classes

When we’re happy with our Kotlin test code, we can go ahead and convert existing POJO classes to Kotlin. POJO classes representing your Models shouldn’t contain much logic, so it’s very easy to convert them to Kotlin.

We all know the boilerplate code which is needed for a simple POJO class written in Java. We have our fields, getter, setter, constructor(s). But this is not all, you might need to implement toString() and/or equals() and hashCode() in some cases which can result in even more lines of code. With your Kotlin POJO you’ll aim for something like that:

If you have functions like isOldEnough() in your POJO, you’ll be happy to write some extension methods.

Working with an API you should really know your API well. You should know which fields are nullable and which are not. For example, with Java you were able to set your String variable to null. With Kotlin, you have to declare your field accordingly, otherwise you’ll receive a crash during runtime. (String vs. String?)

You should also take a look at your field names. We experienced an incorrect naming of boolean parameters while converting code.

Step 3: Helper / Static Classes

Classes which hold functionality to keep your code clean should be your next step. Nothing special here, your static functionality should be converted just fine. Even the required annotations like @JvmStatic should be there. Your code and build process should work fine by now. Maybe you want to get rid of these classes anyway and replace static functionality with extension methods?

Step 4: Business Logic

Your MVP/MVVM Classes which contain most of the functionality for your app should be converted next. Keep your tests ready! Dagger should still work and inject your dependencies correctly.

Step 5: The good, the better & the ugly (UI Code)

We haven’t reached our goal of 100% Kotlin yet. Some of our code is still in Java: We still have our Activities, Fragments, Custom Views and probably some Dagger code. In most projects we faced multiple, unsolvable issues using Dagger together with Java and Kotlin ( e.g. Annotation Processor vs. Kotlin Annotationprocessor). So at this point we have to convert all the missing code – ending up with a broken build.

While every project is (kind of) individual you probably want to convert the code starting from easy working your way up to hard, so we suggest the following order:

1. Interfaces

2. Presenter, Use Cases & Services

3. Dagger-related classes (Modules, Provider etc.)

4. Custom Views

5. Activities and Fragments

You will probably run into multiple problems while doing this. Nothing specific—but especially with Dagger things can be difficult.

Butterknife?

While we’re on the subject of doing cool things, wouldn’t it be cool to decrease the APK size a bit? In the olden days ButterKnife was very useful and back then every single Android developer should have used it. But with Kotlin we want to get rid of it. Why? Because we have kotlin-android-extensions which is a plugin for the Kotlin compiler. It’s good for two things:

1. It adds a hidden caching functionality and a field inside each Kotlin Activity/Fragment which is very small and doesn’t really increase the size of the APK.
2. It replaces each synthetic property call with a function call.

This works by invoking the caching function whenever a synthetic property is invoked, where the receiver is a Kotlin Activity/Fragment class that is in module sources.

AndroidX?

With SDK Level 28 (?) the Android Support Library was replaced with AndroidX and Android Studio can help you to migrate to the new libraries.

We didn’t run into any problems with this—just keep in mind: Your 3rd party libraries have to support AndroidX. When some of your dependencies are abandoned and won’t receive any updates … well, fork them or get rid of them.

Join us!

Whether you’re interested in Android development or mobile development in general, take a look at our current job offers and find what best suits your interests. Join us and implement cutting edge technology in production level projects with our broad selection of customers!