Kotlin in production, one year later

| 8 Comments | 6 minutes read

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.

Optional types & smartcasts

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!

Opening class for Realm database

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.

Function with defaults arguments

Java function overloads generate by Kotlin

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 classesDon’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.

Kotlin extension usage (no more findViewById)

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!

Retrofit service interface

Use of retrofit service & lambdas

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.

Production Ready!

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)!

Arnaud Giuliani Author: Arnaud Giuliani

French Java Software Tech, create and run #java #server gears (distributed and other under the hood stuffs). Also like to make #android apps

Like it?  Share  it!

Share Button

8 Comments

  1. How did you manage to remove Dagger from your project with kotlin?

    • Arnaud Giuliani

      Well, you’re not the first one to ask for dependency injection in Kotlin. ‘Object’ class singletons can heavily help you build your dependency graph & components.
      I think this can be interesting that I write an article on this focus, and compare with Dagger cases.

  2. I’ve migrated my Android app to Kolin too and I’ve been very happy with the possibility to remove retrolambda, guava in particular. It’s much more concise and easy to write now.

    How did you replace Dagger with Kotlin though? I know you can replace Butterknife with some Kotlin tricks but what it has to do with DI?

    • Arnaud Giuliani

      As I said to Victor, ‘Object’ class singletons can heavily help you build your dependency graph & components.
      I think this can be interesting that I write an article on this focus, and compare with Dagger cases.

  3. I have been working on Kotlin for couple of weeks by converting the Activities of the android app I developed java to Kotlin. Kotlin seems and feels an easier language than java. The best thing about is that I could use Java and kotlin activities side by side. So I didn’t have to convert all my Activities to Kotlin before I could test it. However, my question is I read that Kotlin a cross platform app as in Android and iOS. How does that work?

What do  You  think? Write a comment!

Leave a Reply

Required fields are marked *.


CommentLuv badge