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.
In Android, a layout is composed from a hierarchy of views. Each view has a parent (up until the root view) and a ViewGroup can have child views. When a layout gets inflated at runtime, the framework measures each view according to its attributes about sizing and spacing. The result of a view’s measurements is also dependent on its parent and any sibling views.
RecyclerView is like most views in this respect but has some peculiarities. This comes down to a few reasons. RecyclerView sees regular updates by the Android team and sometimes its behavior with how it’s measured changes. And while it is a ViewGroup, its child views are provided indirectly through an adapter and managed by a LayoutManager. Lastly, its behavior to scroll sets it apart from most static views.
Rob Napier recently gave a gentle introduction to functional programming in Swift. Even for experienced functional programmers it’s a short but enjoyable talk to watch. The talk was trending on Hacker News a few weeks back and there was some interesting discussion around functional code not always being easier to read than its imperative counterpart, albeit usually being shorter.