Kotlin / Parcelize


A Parcel is an optimised serialisation format for Android which is designed to enable us to transfer data between processes. This is something that most Android developers need to do occasionally, but not that often. Making a class Pareclizable actually requires a little bit of effort, but there’s a Kotlin extension that simplifies things enormously. In this post we’ll look at @Parcelize and how it can make our lives easier.

I am sure that I’m not alone when every time I need to implement a Parcelable I slightly despair because I know that I need to write some boilerplate code, and I’ll need to look up the docs to remind me how to do it because it is something that I don’t do regularly. Kotlin to the rescue!

Typically the kind of data that we need to pass between processes can be encapsulated within a data class. If the data class implements Parcelable we typically need to include a few methods:

Thankfully, IntelliJ IDEA and Android Studio contain helpers to generate this code automatically, but it is still adding cruft to our data class. The @Parcelize annotation is our friend! It is still in experimental state, but has been around for a little while so we can hope that it becomes stable soon. Many thanks to Olivier Genez for pointing out that @Parcelize made it out of experimental in Kotlin 1.3.40 (this article was originally written before that was released). To use @Parcelize in a version of Kotlin prior to 1.3.40 we need to turn on experimental Android extensions:

With @Parcelize can now simplify our data class quite enormously:

While this might appear to be the shortest post in Styling Android history, it’s not quite that simple. Let’s look at a slightly more complex example:

If you like a puzzle, then please study that snippet and see if you can work out what doesn’t quite work as expected.

At first glance one might consider that including a field of type SimpleDataClass might cause a problem, but this is actually fine because it is already a Parcelable and we can use any Parcelable class as a field. The issue is actually with the transientString field, and it’s not quite a simple as it seems. Reading the code, one would understandably assume that the receiver of this would get an empty string in the transientString field, but this doesn’t happen. The problem is actually twofold: Firstly, the Android framework only serialises a Parcelable when it has to; And secondly, @Parcelize doesn’t respect the @Transient annotation.

To demonstrate the first of these, look at the following Fragment:

if we call this as follows we might expect different behaviour than actually happens:

Although the highlighted line in the newInstance() method of MainFragment shows that we’re adding a Parcelable to the Bundle, it only gets flattened if the Android framework needs to flatten it across a process boundary. In this context, where it’s being passed within the same Activity there is no reason the flatten it, so the same instance of the CompoundDataClass is retrieved in the highlighted line in the onCreate() method.

We can simulate flattening of the Parcel by adding a couple of extension functions which mimic how the Android framework will flatten and expand Parcels:

We can then invoke these to forcefully flatten the data class, and expand it again (this really isn’t something that anyone would need to do in real world scenarios, so please heed the comments on the code):

Even if we do that, we still get the value of “Transient” in the ARG_COMPOUND value that we get from the Fragment arguments in the onCreate() method of MainFragment. As I mentioned previously this is because the bytecode generated by @Parcelize will persist all fields including those marked as @Transient this is slightly inconsistent with how transient fields are usually treated during persistence, but we can prove this by looking at a decompilation of the Kotlin bytecode:

The field named transientString gets serialised to and from the Parcel despite being declared using the Java transient keyword. If we want to have transience for this field we have to do things manually. It is actually worth covering this because we may also need to do this if we have fields which are third-party objects which are not Parcelable and we need to implement a custom mechanism for storing sufficient data to the Parcel to allow us to re-instantiate a specific object when the Parcel is expanded back to object instances:

Having a Parceler companion object which implements the create() and CompoundDataClass.write() methods enables us to customise what is persisted to the Parcel and, in this case, allows us to omit the transientString field. Although the @Transient annotation achieves no direct purpose here, I think it is good to leave it here because it make it much clearer to anyone reading the code that the field will not be persisted. Our code is easier to maintain and understand as a result.

While it might be argued that having to implement these methods to perform the parcelization is back to where we were at the beginning (i.e. having to do things manually). However, if you compare this to the very first code snippet, still much of the boilerplate code is still generated for us, and there is still much less cruft as a result of using Parcelize.

The source code for this article is available here.

© 2019, Mark Allison. All rights reserved.

Copyright © 2019 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.