What Comes in Kotlin 1.1 for Android Developers?

Kotlin 1.1 release is planned for Q1 2017

The final release of Kotlin language in version 1.1 is planned for Q1 2017. Currently we are expecting a Release Candidate version after recent Beta. Kotlin 1.1 comes with many new language features held and discussed in the KEEP repository. I decided to research the upcoming changes released in past four EAP milestones and go through those that might impact Android Development.

Coroutines

One of the hottest features introduced in the first milestone of version 1.1 and redesigned in next ones are coroutines. It’s a mechanism that provides ability to improve asynchronous programming in Kotlin. The aim is to eliminate a well-known callback hell with suspended computation.

Concurrency is a very important part of Android, because we often need to perform many operations at the same time and we constantly care about single threaded UI suffering from long-running operations. Do you remember AsyncTask? I hope you would prefer to forget about that class from Android API. Three type arguments and a lot of boilerplate code needed just to perform a simple background operation with a result published on the main thread.

Here is how long asynchronous operations can be executed with external kotlinx-coroutines-async library:

It is so clean, isn’t it?

What’s more, under the hood async and await are not reserved keywords (like in other languages such as C#). They are regular functions. For now, this methods are built upon CompletableFuture class and require minimum SDK version of Android app set to API level 24 as it uses Java 8 Language Features. However, there are some implementations that do not require JDK 8, e.g. in Kovenant promises.

Possible concern of RxJava fans might be that in many cases coroutines can replace their favourite framework. After a quick investigation of that case I have a good news for you. Look at prototyped kotlinx-coroutines-rx library to understand that Rx and coroutines can actually cooperate.

Type Aliases

Aliasing types was a long-awaited feature for Kotlin developers. The key benefit is a possibility to reduce repetitions and complexity of long type names. It applies mainly to function and generic types. In Android applications development it’s becoming very useful when defining common UI actions.

How many times have you needed to add or remove parameters in a lambda and then continue refactoring in different places?

As an example, suppose that you need to create a ViewHolder and pass a nullable lambda as an argument to the constructor to optionally easily listen for click events on the item view:

Shortly you decide to open your ViewHolder class and add few subclasses to receive final hierarchy as below:

After a while it turns out that you must implement a new feature in your app. To achieve it you have a plan to listen to item view state changes. You decide to extend your lambda with new parameters (Int and Boolean) to avoid a mess in your model class. Unfortunately, you have to perform a refactoring in all signatures containing this function type.

At this point, it is getting much easier with type aliases. Let’s see how our code would look like if we defined an ItemAction type alias and replaced lambdas with it:

As you can see there is now only one place to perform a refactoring when you need to change lambda parameters. With type aliases refactoring is necessary only in alias definition. That’s it!

Inlining Property Accessors

In Kotlin 1.0 we could already create inline functions. Modifying property accessors with inline keyword might be considered as an abuse and quite strange for the first time. However, you should know that inlining is a powerful weapon against increasing methods count in DEX files, what in Android really matters.

This feature might be used in conjunction with another one (from Kotlin 1.1) that enables inferring property type from getter:

Remember that you can also define this property as below, because inline modifier might be applied to specific accessor as well:

Note that this feature enables reified type parameters in property accessors as well. Examine the following extension:

Less Restrictive Inheritance

The next big changes concern inheritance in Kotlin. Firstly, until Kotlin 1.1 it was impossible to declare a subclass of a class with sealed modifier outside of the sealed class declaration. Now this limitation does not exist anymore (excluding non top-level classes). We are only limited to declare subclasses in the same file as sealed class like below:

Thereby subclasses do not need to have that complex names. You can import A class with import A instead of import S.A.

Incoming release unlocks also an inheritance for data classes. Yes, we can now inherit them from other non-final classes! According to that, now data classes can be also declared in sealed hierarchy. Let’s examine a following declaration:

Why it is so useful apart from common advantages of ability to declare a base class for data classes? Notice, that else clause inside when expression is not needed as long as data class remains in sealed hierarchy, because all cases are verified:

Destructuring and Underscores

Kotlin 1.1 comes with many syntax cosmetics to eliminate any boilerplate code. Destructuring declarations in lambda parameters is one of that features. That eliminates such manual destructing from our code:

Here is how unpacking a composite value passed to lambda looks like:

In the code above you could also spot another new language feature. It is an underscore character (_) used to remove unused parameters from destructing declaration. We are not using an uuid parameter so its name can be easily omitted.

With new release underscore characters can be also used in numeric literals to separate digit groups and improve readability of large numbers.

Methods Count

At the end I decided to compare two classes.dex files of a sample app compiled with recent Kotlin standard libraries. I used the APK Analyzer built in IntelliJ IDEA and Android Studio. Here are the results:

• Kotlin 1.0.6: 5097 referenced methods
• Kotlin 1.1.0-beta-17: 5667 referenced methods

Is additional 570 referenced methods a big problem? Counting all the new features that we will get in the upcoming release — No. I still consider kotlin-stdlib a very lightweight library comparing it e.g. to Google Play services.

Looking for Experienced Android Developers?

What’s Next ?

It is hard to discuss all the changes that will improve our productivity after switching to Kotlin 1.1. I didn’t mention bound callable references or local delegated properties. There are also many improvements in the standard library and tooling support.

Personally, I am very pleased with current Kotlin roadmap. I recommend you to listen to this chat with Andrey Breslav to hear about a history, now and nearest future of Kotlin. There are still many challenges to overcome. We are still waiting for working incremental compilation and stable Kotlin annotation processing tool. Nowadays, I can’t find a better alternative to Kotlin language for Android development. Possible reasons are high priority of Android support and growing Kotlin community with many open-source contributors.

Tap the ❤ button if you found this article useful!

About the Author
Paweł is Android Developer at EL Passion. You can find him on Twitter.

Find EL Passion on Facebook, Twitter and Instagram.