We have been talking about Kotlin for a while now on this blog. As Kotlin early adopters, at ekito we have successfully pushed in production Kotlin applications. Today, while version 1.1 of the JetBrains’ language should be soon released, I want to share our feedbacks 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 (I already have made some presentations about it, past year for ekito’s geek breakfast and devfest toulouse).
Successful projects upgrade
On our projects in conversion, we are now paying attention to some aspects. Here are a few typical situations.
The “magic” 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 push 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 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 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, Kotlin-Extension will not inflate directly widgets that comes from an activity. You will have to do it by hand.
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. You’ll have to wait Kotlin 1.1 to have more “open” 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 advanced topics that can bring you small improvements for your daily Android API usage (helpers for activity, fragments, intent, tasks….).
For me, RxJava + Kotlin is my perfect 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 functions extensions. To avoid spreading extensions all over your code, the best 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.
Kotlin is not just about writing your app with lesser lines. It is all about writing safer & better applications.
“Your adoption of Kotlin must be justified,
not for the hype.”
We clearly felt a gain in our projects quality and productivity. Once you have worked a while with it, you begin to feel the limits of our good old Java. But your approach to adopt Kotlin must be justified, not just go there for the “hype”. You have to be clearly aware of what is the gain… “I really need it for this or that.” 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 promises us new language improvements (syntax, functions) as well as parallel programming features with coroutines. We’ll keep you in touch on what it’s worth 😉
For the next few weeks we are preparing workshops, in order to help discover and test Kotlin in a real situation (DevoxxFR 2017 @ Paris, ekito Morning Tech @ Toulouse…). All examples above will be available in our github repository. You will be notified soon (check our twitter)!Google+