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

related: b/63325506

we can probably tie this to WAL support.

So the title of this bug should be changed to "support multiple instances of RoomDatabase"?

When support this? i face the same problem, it multiple query and insert, it'll block

hopefully we'll have this in 2.1 . What is your use case, are you accessing the same database from different processes or are you creating 2 instance of the same RoomDatabase in the same process?

Create one instance of RoomDatabase, and use LiveData paging query the datas and when querying, i also use the db connect insert the data, the query always wait the insert end and return

BTW, other thread insert the data, or update the data

if you are in the same process, don't use multiple RoomDatabase instances.

Why the LiveData been blocked? the query always waiting for the insert end and return

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 41bbdfb46058e7ef3ea6aa21ac8d7a3c7642fa1d
Author: Yuichi Araki <yaraki@google.com>
Date:   Wed May 23 17:38:58 2018

    Multi-instance invalidation
   
    Developers can now sync observers for InvalidationTracker and LiveData
    between multiple RoomDatabase instances by
    RoomDatabase.Builder.enableMultiInstanceInvalidation(). This can also be
    used for database instances in other processes. All the instances have
    to be using the same database file.
   
    When multi-instance invalidation is turned on, all the tables are
    observed by an instance of MultiInstanceInvalidationClient, and
    invalidation detected in one instance is broadcast to other instances by
    remote procedure call.
   
    Test: MultiInstanceInvalidationTest
    Bug: 62334005
    Bug: 80464228
    Change-Id: I76033c5ac543ddaef735be06f828b7d7d607883a

M       room/integration-tests/testapp/build.gradle
A       room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/MultiInstanceInvalidationTest.java
M       room/integration-tests/testapp/src/main/AndroidManifest.xml
A       room/integration-tests/testapp/src/main/aidl/androidx/room/integration/testapp/ISampleDatabaseService.aidl
A       room/integration-tests/testapp/src/main/java/androidx/room/integration/testapp/SampleDatabaseService.java
M       room/integration-tests/testapp/src/main/java/androidx/room/integration/testapp/database/CustomerDao.java
A       room/integration-tests/testapp/src/main/java/androidx/room/integration/testapp/database/Product.java
A       room/integration-tests/testapp/src/main/java/androidx/room/integration/testapp/database/ProductDao.java
M       room/integration-tests/testapp/src/main/java/androidx/room/integration/testapp/database/SampleDatabase.java
M       room/runtime/api/current.txt
M       room/runtime/src/main/AndroidManifest.xml
A       room/runtime/src/main/aidl/androidx/room/IMultiInstanceInvalidationCallback.aidl
A       room/runtime/src/main/aidl/androidx/room/IMultiInstanceInvalidationService.aidl
M       room/runtime/src/main/java/androidx/room/DatabaseConfiguration.java
M       room/runtime/src/main/java/androidx/room/InvalidationTracker.java
A       room/runtime/src/main/java/androidx/room/MultiInstanceInvalidationClient.java
A       room/runtime/src/main/java/androidx/room/MultiInstanceInvalidationService.java
M       room/runtime/src/main/java/androidx/room/RoomDatabase.java
M       room/testing/src/main/java/androidx/room/testing/MigrationTestHelper.java

https://android-review.googlesource.com/720919
https://goto.google.com/android-sha1/41bbdfb46058e7ef3ea6aa21ac8d7a3c7642fa1d