A modern programming language that makes developers happier.

kotlinlang

Hi guys! A question: what solution do you recommend me to use `Parcelable` in a non-Android module? :bugdroid: I have modules with domain classes, but I need to pass them through bundle

or define your domain classes as protobufs

9 times out of 10 it's better to parcel some sort of identifier for your domain objects rather than the domain objects themselves, and reload the domain objects from a persistent source of truth based on those identifiers

<@UJBKXD0HH>, when do you prefer using Serializable/Parcelable then?

Serializable: absolutely never on Android. Parcelable: when I need to do IPC with another process or save what is essentially navigational state for the UI for savedInstanceState - what screen I'm looking at, the item ID for the detail screen I'm looking at that I can use to reload from db/network/etc, scroll positions...

<@UJBKXD0HH> May I ask why are you against using @Serializable on Android?
This marker interface is much more familiar to Java developers and easier to use.
If we talk about the performance aspect, then after Android 7, when ART runtime comes with Java 8 and Unsafe appeared, Serializable began to work much faster, practically not inferior to Parcelable. Which, by the way, without code generation(Kotlin Parcelize) is much more verbose and prone to errors.
Typically, serialization speed is a very, very rare bottleneck. And putting a single model into a bundle or sending it over IPC will almost never be a performance problem.

Thanks. :slightly_smiling_face:

I can imagine only one case when the Parcelable will be faster, when we will serialize tens of thousands of objects per unit of time, but this is more laboratory tests than real code.

it's still slower for performance - _significantly_ so in the last benchmarks I saw - and it invites pulling a lot of additional data along for the ride as the object graph grows. Pretty much any other serialization mechanism you can choose has better properties. And hard disagree on this being a lab only, theoretical issue. As recently as a month ago I've seen cases where moving from Serializable to Parcelable or other solutions tangibly improved performance in user-visible ways.

Serializable is very error prone way of serialization, it's very easy to add non-setializable property to serializable class and get runtime error, you never has this with Parcelable and kotlinx.serialization, for example if you define any property as Map&lt;K, V&gt; which is not serializable, you can store non-setializable implementation which will blow up on runtime, but it's not the case for Parcelable, kotlinx, it will check it on compile time

Also serializable doesn't work well with Kotlin nullable, same as any reflection based serialization

Though, I would always prefer kotlinx.serilization over Parcelable, if I would choose