[kevb]

She mentions that we should think of the android apis as a "system framework", and I remember a different Google Android engineer saying something similar about the RecyclerView, that right now the focus is on making the technical functionality and API solid and stable, even if not so developer friendly. Someone else, or future Google, can make a more developer friendly API on top of the awkward RecyclerView API. The problem with designing APIs that aren't really meant for app developers, but instead for higher level framework developers, is that those higher level frameworks don't actually exist, and even if they did, there's no clear message for developers to follow. Less choices, or at least a "recommended" approach, would be valuable.

[christop]

Unfortunately, 18 months since its release, I'm not sure if anybody (certainly not Google) has come up with some nicer abstractions on top of RecyclerView.

It works well for basic lists, but out of the box it comes with very little — not even a click listener for items in the view.

Having written a custom LayoutManager for RecyclerView a year ago (and then a matching ItemDecorator), it was probably the most difficult (and frustrating) thing I've had to do in Android development.

At the time there were certainly zero code samples that correctly implemented a layout manager that worked in all cases. Indeed, I gave up on supporting various parts of the API. I don't imagine that has since changed.

[HillaryBriss]

Probably because the RecyclerView is so frikkin' complicated, as Chet Haase and Yigit Boyar explain here: https://youtu.be/imsr8NrIAMs

After watching this for five or ten minutes, I gave up. It didn't seem like it offered a good return on time invested.