Reducing Parcelable boilerplate code using Kotlin

Update (november 2019): I published a detailed new article about how to use Parcelize to have your Parcelable boilerplate code generated automatically by a Kotlin plugin. This is the preferred method to implement Parcelable in Kotlin today, even if there are still exceptional cases for which you want to write this code manually in Kotlin. The following article will help you for those cases.

Implementing the Parcelable interface and maintaining this code remains a painful day-to-day task for Android developers. Surely, Android Studio can now automatically generate most of the boilerplate code, but this doesn’t work for all member types and most importantly, the result is quite verbose and clutters classes, decreasing their readability.

About Parcelable libraries

Annotation processor libraries like PaperParcel are able to automatically generate Parcelable implementations and get rid of some of the boilerplate code. This is fine, but I don’t use these solutions because I like to have full control over the serialization process. These libraries come with their limitations. For example:

  • Most of these libraries serialize types like Enum<T> or BigDecimal using Parcel.writeSerializable() or transform them to Strings which is not the fastest implementation nor most compact representation. Some provide support for non-Parcelable types through custom adapters, but you still need to specify the adapter class in every place where you want to use it.
  • These libraries usually serialize Parcelable members inside Parcelable classes using Parcel.writeParcelable() which is less efficient to deserialize than using Parcel.writeTypedObject() when the concrete type is known.
    This is because Parcel.readParcelable() first reads the full class name in order to retrieve the corresponding Parcelable.Creator via reflection, while Parcelable.readTypedObject() uses the provided Parcelable.Creator directly.
  • In some cases, I want the Parcelable.Creator to act like a factory method determining which concrete sub-type will be created. Again, this is more efficient than using Parcel.readParcelable(). I can’t do this if the Parcelable.Creator is generated automatically.
  • I like child classes to reuse Parcelable code from their parent to avoid redundancy. This is not what most libraries do.
  • Finally, almost all libraries slightly increase the methods count of your APK file, because they bundle their own small runtime into your app and generate a few extra methods for each Parcelable class.

If you want to learn more about Parcelable libraries and their differences, I recommend this excellent article from Brad Campbell.

Kotlin for Parcelables

Simply converting classes to the Kotlin programming language without any additional trick already makes them more readable than their Java equivalent.

Consider the following example class written in Kotlin.

By using the built-in Android Studio contextual action to generate a Parcelable implementation automatically, we get the following code:

The result is 25 lines long.

While the code quality is decent, you’ll notice that the CREATOR static field has been implemented as the companion object of that class. This is technically working, but since a class is only allowed to have a single companion object, it means you’ll have to add your class custom fields (like constants) directly into that CREATOR object:

In addition, the Creator methods will be exposed as members of the Person class, polluting its API. This definitely doesn’t feel right and harms readability, so you’ll probably want to change the code to the recommended pattern which is to move the CREATOR field inside the companion object, and annotate it with @JvmField so it will be compiled to a static Java field:

We can also make the code a bit shorter by using single-expression functions.

Finally, I like to use named arguments for more clarity when calling the primary constructor from the Parcel secondary constructor and make this constructor private or protected since only the CREATOR and child classes will invoke it.

We end up with the class looking like this:

It’s now 21 lines long.

Like Java 8, Kotlin allows to add default implementations to interfaces. We can create an interface using this feature to provide the default implementation of the describeContents() method, which in 99.99% of cases should simply return 0 (and the cases where it should return another value are badly documented anyway). Now we won’t have to write that useless method ever again.

We’ll also override the signature of the writeToParcel() method to force its Parcel argument to be non-null, because it’s actually never null and you shouldn’t bother using the safe call operator on it.

From now on, we’ll simply make our objects implement KParcelable instead of Parcelable.

It’s time to leverage one of the most powerful features of the Kotlin language: higher order inline functions, which can be used like macros for code generation. In this case, we will write a function that generates implementations of these Parcelable.Creator objects that always look the same.

This is a modified version of the function provided by Juan Ignacio Saravia in his instructive article about Parcelables in Kotlin.

Thanks to reified generic type parameters, the arrayOfNulls() function is able to create an array of the proper concrete type at compile time. This would not have been possible to achieve in Java without using reflection at runtime.

parcelableCreator() takes a single argument: a function returning a new instance of the target class from a non-null Parcel. This argument can be a lambda, but it can also simply be a reference to a function like the class secondary constructor which takes a Parcelable as argument:

In addition, we can write a similar function to generate instances of Parcelable.ClassLoaderCreator for cases where we need access to the ClassLoader.

Our final class has now been reduced to just 15 lines of code and is way more readable:

Parcel only supports a handful of types to serialize. What if we could extend it to support more types, so that writing an Enum to a Parcel would be as simple and as efficient as writing an Int ? That’s exactly what Kotlin extension functions are made for.

We can now write an Enum to a Parcel using this syntax:

Note how these extension functions use nullable types, so they can be used with both nullable and non-null class members. The only compromise of this solution is that it forces you to use the !! operator when reading back a non-null value to a non-null member:

This is safe since you know that the value written to the Parcel was non-null in the first place. If somehow you get a null value here, it means that you made a huge mistake in your serializing code and the NullPointerException is deserved.

Another pair of useful Parcel methods I mentioned earlier is Parcel.readTypedObject() and Parcel.writeTypedObject() that should be preferred for reading or writing Parcelable members when their concrete type is known. These methods are only available since API 23 and not yet part of the support library, but their implementation is straightforward. We can create compatibility versions working on any Android release using simple Kotlin extension functions:

Note that I extracted the null handling parts of the code to external inline functions readNullable() and writeNullable() so they can be reused by other utility functions.

You can find a complete set of useful extension functions for Parcel in the full source code listing at the end of this article.

As a last example, these function calls can be grouped with apply(), run() or with() to reduce the verbosity to a minimum:

The Kotlin language itself is a powerful tool to reduce boilerplate code in Parcelable classes. For those who want full control over the serialization process with minimum overhead while keeping the code as readable as possible, this set of Kotlin utilities and best practices is a good alternative to Parcelable libraries.

As always, please share if you like. Thank you for reading!

Android developer from Belgium, blogging about advanced programming topics.