At work we’ve been employing RxJava across our codebase. This means that most methods we write, especially those involving database or network calls, will return an Rx type (e.g. Observable, Single, Completable).
For example, there’s an operation to delete a credit card from a user’s virtual wallet. This requires sending a request to our server to delete the card. As a side effect, we also want to delete this card locally from our database when the network call completes successfully.
I posted an article a few months back explaining some of the issues of using Parcelable and how leveraging a library can help mitigate them. I’ve since come to the realization that these issues should have never really arisen in the first place. The real issue was that I was using Parcelable the wrong way.
It might seem easy, and even appropriate, to generate a Parcelable implementation for most of your data objects. The ones that get used by your views may need to get passed to an Intent or Bundle in order to be available to another Activity or Fragment.
As an Android developer you’ve probably used Parcelable for one thing or another: whether it’s storing an object in an Intent or passing arguments to a Fragment. While there are ways to avoid using Parcelable, it can often be the simplest and quickest way of passing data around.
Implementing Parcelable is pretty straightforward. In fact, Android Studio can auto generate the code for you when you add the interface to your class.