Kotlin in production, one year later
My feedback on daily using Kotlin for my Android apps, since its first stable version in Feb 2016 (article imported from ekito.fr)
I have been talking about Kotlin for a while now. As a Kotlin early adopters, at ekito I have successfully pushed in production several Android/Kotlin applications. Today, while in version 1.1.x of and recognized as “official” language for Android by Google, I want to share our after one year of daily development with Kotlin for production applications.
In the remarkable aspects of this JVM language, we can speak of its ease of project setup and its excellent Java interoperability (don’t throw away your Java knowledge). We have encountered almost no difficulties in injecting Kotlin into an existing Java project. Without such ease, it is impossible to start testing in a serious context, or to avoid the “big bang” effect in your project. To get started with it, it is therefore important to start introducing Kotlin with real and specific needs.
Jetbrains has made a great job on tools. You get the feeling that those tools are mature. Android studio is ready to setup your gradle project in one click. The real thing is to understand what Kotlin can bring you.
Successful projects upgrade
On our projects in conversion, we are now paying attention to some aspects. Here are a few typical situations.
The “magical” conversion of a Java class to the Kotlin class is often well done, but sometimes need to be reviewed. It is better to target small or simple Java classes at beginning. Don’t try to convert directly the hearth of your application. Each time you use the conversion shortcut, pause yourself a minute, reread and rewrite (if needed) your code. Quickly, you will be able to write things in simpler way.
While migrating our projects to Kotlin, we become easily aware of one thing: our APIs are not as secure as they should be! Optionals & Smartcasts help you manage objects nullity, and you will no longer need secured operators to work with these objects.
Kotlin’s tooling advise you to use immutable values when possible (val against var objects). If you use only variable types, you will have concurrent use problems warnings (which is too much quickly forgotten in Java). In Android, this also helps you to fight memory leaks. This way you will write applications that are less exposed to uncontrolled states, and your code becomes more easily testable.
One tricky thing to look for, is the use of frameworks that use proxy generation (Realm database for example). Kotlin classes are public and closed by default. Be careful to open needed classes and methods!
The default function arguments in the Kotlin is an extremely valuable feature, in terms of coherence and time gain. But once you go back to Java, you feel a bit naked. We can use this enough to calm the pain: the @JvmOverloads annotation.
Daily working with Kotlin
Daily Android development with Kotlin is a real breath of fresh air! We have now bunch of good practices. You can get rid of some regularly used frameworks. No need for Dagger as dependency injector (I will explain this in a further article) or Butter Knife to manage your widget instantiation! Also forget Retrolambda for those who want to write lambdas and functional code.
“Object” are singleton classes. Don’t hesitate to use them for component assembling and injection, and take care to not leak any Android context object.
The Kotlin Android Extensions allow you to inject any widget of your layout xml, with its Id. Check your imports to be sure to use widget injection and not its Id then 😉 (findViewById is not needed for your main usage). Note also that in a fragment, the plugin will not inflate directly widgets that comes from an activity. The injection will be available in onViewCreated() method.
The data classes are really nice to use. Things like json models are then very simple to write! Beware of the abuse of data class, those classes are sealed. If you are not careful, you may be stuck because you want to inherit or extend some properties. Kotlin 1.1 bring the capacity of “opening” data classes.
A question that I’m often asked is about the use of ‘object’ class: In which case use a companion object or object class? In Kotlin, we do not have static methods strictly speaking. I try to have this approach:
- companion object, for utility methods (factory, helper) for a dedicated class
- object, grouping a set of methods (often stateless functions) or whose purpose is to share the same singleton object
The Collection API in Kotlin is one of the things you’ll regret most quickly when you go back on a Java project 🙂 The API is easy to use (in my opinion, simpler than the Java 8 API stream) and you can easily play with lambdas. For large processing, you can go with “lazy” collections which is derived from the same API (the sequences API).
Anko is an interesting Android library that can help at several levels. The layout DSL didn’t inspire us much, and we didn’t have the need of use it. But I suggest to throw an eye on the Anko topics that can bring you improvements for your daily Android API usage (helpers for activity, fragments, intent, tasks….).
For me, RxJava + Kotlin is a great reactive stack on Android. Even if you can go with retrolambda, Kotlin brings you a real deal for working with functions. The experience is really quite different. Coupled with retrofit, you can face the any situations!
Last point, about one of the most important Kotlin’s feature :functions extensions. To avoid spreading extensions all over your code, the best thing is to arrange them in a dedicated file and package. When you extend an external class, recreate its package hierarchy and put your functions in a dedicated file.
Production Ready & Google Approved !
Kotlin is not just about writing your app with lesser lines. It is all about writing safer & better applications.
We clearly feel a gain in our projects quality and productivity, since we use Kotlin. Once you have worked a while with it, you begin to feel the limits of our good old Java. If you are not ready for some topics like functional programming, no worries. Kotlin remains agnostic about your style of development. You are free to come and look for the features you need, in due course.
From version 1.0, the releases were really well followed. We have regularly changed these version numbers in our gradle project and we never had broken projects (of course avoid beta versions for production).
Undeniably the community behind is growing well (Jetbrain’s official community support) and in android mailing lists, there is no week without an article about Kotlin. I think this is a very good sign! Version 1.1 bring stability & new language improvements (syntax, functions) as well as parallel programming features with coroutines.
I always believed in Kotlin. It was not easy to convince people to try it, and take the risk on their real apps. Now that it is Google Approved, you have no reason to not try it!
From my article originally published at www.ekito.fr on February 24, 2017.