twitter/Serial

Serial vs Parcelable

Opened this issue · 5 comments

I didn't see Parcelable mentioned anywhere in your blog post. How is this different/better than Android's Parcelable?

I have the same question, why not use Parcelable to solve your serialized problem?

Parcel/Parcelable is not meant to be used for serialization on a persistent storage (check the Parcel javadoc). Try to update the structure of a Parcelable object, then parse the content of old ones.. it will not work, and it will be impossible to debug. They are designed for inter-process communication first.
This library instead seems to handle it, if you check https://github.com/twitter/serial#updating-serializers
I think they just simply chose a similar API to Parcelable, which makes sense because Android developers are used to it.
What will be interesting is a comparison of this library with google protocol buffers.

Thank etibaldi, if u want to persist some binary data on storage. Serial is a better choice.

Thanks for your answer, @etibaldi. Here are some aspects in which Serial differs from Parcelable:

  • As mentioned above, Serial is meant for persistent storage, while Parcelable is not, since its binary format is not guaranteed to be stable across versions of Android. Applications end up implementing both Parcelable and other serialization protocols in their model objects.
  • Serial has powerful support for debugging, which is critical for persistent storage. Serial detects issues in the input stream as soon as it comes across a field with the wrong type, and throws an exception describing the structure of the object, the mismatched field and the expected field type. In contract, the behavior of Parcelable with invalid input is undefined - it typically crashes the application, but it may just return invalid data.
  • Serial adds minimal metadata to the output stream to support backwards compatibility, either through version numbers in all objects or peek of the next field in the stream. Parcelable does not include any extra metadata or support for changes.
  • Parcelable requires implementing the Parcelable interface, which is only possible in objects you own. Also, it forces you to couple your model objects with specific serialization schemes, while serializers can be defined separately.
  • Last time I checked, Serial is faster than Parcelable in Lollipop and above, since Art precompiles dex files, while Parcelable requires frequent context switching through JNI into the native layer.

@afauci goes into some detail in her post: https://blog.twitter.com/engineering/en_us/topics/open-source/2017/introducing-serial.html.

Ali, what do you think about adding this comparison at the bottom of the readme file?