IssueTracker

Hmm maybe. I would need that lambda to run before the updates are dispatched to the RV adapter because (conforming to this example) I'm using the title inside the RV items.

My actual example is here: https://github.com/JakeWharton/SdkSearch/blob/35ecf5c5c17edd60da3498eb38eab13786623548/frontend/android/src/main/java/com/jakewharton/sdksearch/ui/ItemAdapter.kt

I have a query term and a list of results. The view holders bold the query term inside the result. Not sure how common it is to use non-list data inside the list items like this. I could make a composite object of query+item and have a list of those, I suppose...

I think running the lambda first is very reasonable.

I'm assuming we'll still need to run those lambdas in the rare case a diff is dropped when too many lists are pushed. Would be nice to avoid any extra bind work (e.g. in the setTitle) case, but it would be surprising to have some of those lambdas never run.

The problem with running the lambda first is that you can't touch the RecyclerView state in many ways, e.g. asking it to scroll to specific content.

May want to differentiate between pre-swap and post swap callbacks.

When talking about when to run the lambda, I entirely forgot - RecyclerView update notifications (e.g. from DiffUtil.Result or Adapter.notifyItem*) are always deferred.

RecyclerView posts before doing any bind work after dispatching any sort of notifyItem*** signals to coalesce changes. This means it's safe to update data you'll display in the callback, even if it's dispatched after the swap. See triggerUpdateProcessor - https://cs.corp.google.com/android/frameworks/base/core/java/com/android/internal/widget/RecyclerView.java?q=triggerUpdateProcessor&sq=package:%5Eandroid$&g=0&l=4919

I added the requested API, and just have it running after the swap. Also manually verified callback can be used to update adapter state displayed.

Fixed with https://android-review.googlesource.com/c/platform/frameworks/support/+/730779 - will go out with next feature release (Paging 2.1)

Released with Paging 2.1.0-alpha01

https://android-review.googlesource.com/846338 adds a setFallbackOnNavigateUpListener method on AppBarConfiguration that allows you to register an OnNavigateUpListener to handle cases where navController.navigateUp() return false.

This allows you to call onSupportNavigateUp() (or super.onSupportNavigateUp() if you're using an ActionBar) from that method to have your Up button transition between activities.

This will be available in 1.0.0-alpha09.

There is Jarks when implementing this way to navigate up between activities.