Upgrade Android Client To Use Modern Language Features with Kotlin

Tags: #<Tag:0x00007fe2e7981c10> #<Tag:0x00007fe2e7981aa8> #<Tag:0x00007fe2e79817b0>

Hello all. I’m fairly new to the OpenMRS community, (I joined around the onset of GCI 2017, but I have been developing for Android outside of OpenMRS for about 6 years). I have a somewhat major suggestion for the Android client that I would like to bring up to the community.

Simply put, I think the Android Client should be upgraded to use the Kotlin language alongside with or as a replacement for the existing Java code.

This may seem like a really unnecessary major change, but hear me out first. :wink:

First of all, what is Kotlin?

Kotlin is a language developed by JetBrains that compiles to the JVM and contains some powerful advanced language features. If you are interested in a more syntaxical introduction to Kotlin, check out Kotlin Koans.


Here are some major advantages of using Kotlin over or with Java:

Kotlin is 100% compatible with Java

It was developed by Jetbrains and is officially supported in Android Studio as well (and now supported as an official language of Android by Google). This interoperability means that we could make this transition a file at a time and have no issues with our existing codebase. The new Kotlin files could call methods and even inherit Java classes with no issues as well.


Kotlin provides advanced language features

Kotlin provides advanced language features that Java is only now receiving or may never receive. A good example is lambdas. I’ve noticed you are using me.tatarka.retrolambda in the Android project. Kotlin would provide native support for lambdas. Simply put, Kotlin can just do things that Kotlin can’t.


Code Maintainability and Readability Would Increase

Another major issue that could be improved by making the switch to Kotlin is code maintainability and readability. The codebase would shrink as well, and as every developer knows, less code means less bugs. Here is a quick Java vs. Kotlin code snippet that highlights the power of Kotlin’s concise syntax:

A common occurence in Android Java:

findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {
        ///Handle button click here
    }
}

Exact same snippet in Kotlin:

button.setOnClickListener { view ->
    //Handle button click here. (Note that `button` is the id of the view. Kotlin has android extensions that allow you to completely remove View binding!)
}

Or, as most Android Kotlin developers do, you can create extension functions that make the above example even more concise!

button.onClick {
    //Handle button click here.
}

This is just one example, but hundreds of lines of code could be removed, making the code more readable and maintainable.


Other notable features:

Great support for Rx and http third party libraries and

Due to Kotlin’s ability to use lambdas, callbacks and specifically reactive programming become a breeze. Also, due to sealed classes and the when statement in Kotlin, http requests can become super simple but powerful.

Supported Major IDEs

Kotlin is officially supported in IntelliJ and Android Studio, and is supported via a plugin in Eclipse.

No more NullPointerExceptions!

A smaller advantage, but one that may be well received, is that Kotlin removes Java’s silly NullPointerExceptions. That means no more issues like this one :smile:: https://issues.openmrs.org/browse/AC-71 (But don’t worry, they still exist, they just don’t come unless invited).

Disadvantages

  1. Kotlin may take slightly longer to perform a clean build. (It is a pretty trivial time difference in my opinion)
  2. About 800 kilobytes may be added to the app. This is probably trivial compared to the current app’s size.
  3. Simply that Kotlin is a different language, so you may have to do a little bit of learning while you develop, but I promise Kotlin will be a helpful language to learn.

One last note

Kotlin lends itself really well to an MVVM architecture, so we may also want to consider making that switch at a future date, but it will have absolutely no problems with the existing MVP architecture and probably make it even easier to implement.


Resources

If you are unfamiliar with the Kotlin language, first check out https://kotlinlang.org for tutorials and documentation

For specifically Android Kotlin, check out http://kotlinlang.org/docs/reference/android-overview.html for some more advantages of Kotlin and other resources.



Conclusion

Kotlin has some clear advantages when it comes down to it. I haven’t even begun to cover them all. I personally think we should make the switch (even if it is just with just one or two files at first). What do you guys think?

1 Like

Also note, I have quite a bit of experience when it comes to Kotlin, so I can do quite a bit of the work if we do choose to convert any files. I would also be glad to show more examples or convert one of the existing Android files to Kotlin to show what the change might look like.

Thank you so much @matthewwhitaker for sharing this with the community! :slight_smile:

Indeed Kotlin is a more modern language than Java. But it being new, i would embrace it with caution, as i continue to monitor its progress in terms of support and other companies or organizations switching to it.

Instead of moving existing files to it, how about reserving it only for new files/functionality? At least for now as we watch the trend?

That way, we take advantage of your time and expertise to actually add new features to the application that will impact the end users. Instead of just a language switch that may not yield immediate results to them.

I like the fact that the two can exist together. That way, those who may want to contribute, but without experience in Kotlin, will still keep doing so in Java.

Time will definitely tell us where to go. Even if it will mean completely switching to Kotlin! :smile:

1 Like

@dkayiwa, how do you feel about me opening an issue where I add support for Kotlin to the build.gradle?

That would be awesome! :slight_smile:

I have created the issue at https://issues.openmrs.org/browse/AC-436 Can I get assigned to the issue as well @dkayiwa?

Go ahead and claim it.

@dkayiwa I have also created two related issues that may affect future Kotlin development: https://issues.openmrs.org/browse/AC-437 and https://issues.openmrs.org/browse/AC-438

Good Initiative @matthewwhitaker . This is the time to invest more in Kotlin :smile:

1 Like

Thanks! Just made them ready for work.