User:DBrant (WMF)/Kotlin

Getting serious about Kotlin
This is a collection of guidelines and best practices for development using Kotlin and its various affordances, specifically as it relates to building clean and performant Android apps.

General thoughts
As we all know, the Android platform gives us a hundred different ways of doing the same thing, so we have to be very mindful and careful about picking a single way and remaining consistent throughout our code.

View bindings
Currently our code uses several distinct ways to bind views at runtime:


 * ButterKnife, which creates binding classes at compile time and requires us to hook into them at runtime.
 * Plain old findViewById in certain cases.
 * Kotlin synthetics, which are convenient for our purposes, but are now deprecated!

So then, the new One True Way of binding views seems to be the View Binding library of the Jetpack suite. Let's work towards updating all of our layouts to use these bindings, and remove the usage of ButterKnife and synthetics. This will have the benefit of using fewer dependencies, and probably fewer total methods and cleaner code.

Parcelables
There are many cases where we have to exchange information between activities. In the cases where the information is a complex object, we usually resort to serializing it to JSON, and then deserializing it from JSON in the destination activity. This is a pretty expensive operation.

Android provides the "Parcelable" interface which is supposed to solve this issue, but the problem is that it requires a lot of boilerplate code to make a class be Parcelable. Fortunately Kotlin now offers the Parcelize annotation which supposedly auto-generates all the necessary boilerplate.

Let's investigate the Parcelize annotation and use it whenever we transfer complex objects between activities.

Use lateinit liberally
If you have an Activity that contains fields that are initialized in onCreate, make sure they are defined as. In other words, avoid using nullable types as much as possible.

Use 'by lazy' sparingly
The  annotation allows you to lazily initialize a field, but beware: this comes at a nonzero cost. The  annotation itself will become an object that will "contain" the lazy initialization code and run it in a thread-safe way when it's first requested. Therefore only objects that are truly heavy and expensive should be initialized this way.