Create an abstract PagingSourceFactory class, which tracks emitted PagingSources for .invalidate calls [160716447]

Fixed

Feature Request

[AOSP] assigned

NeedsInfo

androidx-bug-bounty

Status Update

No update yet.

Description

em...@monzo.com

created issue #1

Jul 8, 2020 09:58AM

Artifact used: androidx.paging:paging-runtime & rxjava2 Version used: 3.0.0-alpha02

In order to call pagingSource.invalidate() to deal with the user of my app deleting a row from the paged RV they're looking at, I had to do the following in my ViewModel:

    private var pagingSource: PagingSource<Int, FeedItem>? = null
    private val feedPagerObservable by lazy {
        Pager(
                config = PagingConfig(pageSize = 20),
                pagingSourceFactory = { pagingSourceFactory.create(...).also { pagingSource = it } }
        ).observable
    }

Then, elsewhere in the VM I have a reference to the source to call invalidate. This feels really, really ugly. I'm aware that I have to pass a factory into Pager because it can get recreated, but this feels like it's not something I should really have to worry about.

It's hard to say what I would prefer, which is why I imagine it's like this!

Keeping a reference to the Pager feels less gross than it does for PagingSource. Perhaps Pager could internally keep a reference to the existing PagingSource so I could just call Pager.invalidate() and it would do a similar hack internally?

Very happy for better or other suggestions. Currently it feels very awkward, and it was super hard to discover that the .invalidate() method even existed to call!

Comments

vi...@google.com <vi...@google.com> #2Jul 9, 2020 08:51AM

Assigned to cc...@google.com.

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

commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019

Change the way to detect mismatch between POJO and query

This fixes cursor mismatch warnings with expandProjection.

Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8

M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt

https://android-review.googlesource.com/1123258

https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1

cc...@google.com <cc...@google.com> #3Jul 9, 2020 04:44PM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
Created: 2019-10-14 17:23:42.610596+00:00
Changes: aosp/1123258

du...@google.com <du...@google.com> #4Jul 9, 2020 07:29PM

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

commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020

Re-factor how errors are dismissed when query is re-written

This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (

b/140759491

).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.

This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.

Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f

M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt

https://android-review.googlesource.com/1288456

an...@gmail.com <an...@gmail.com> #5Aug 15, 2020 08:55PM

Whil I understand your idea of internal invalidates of PagingSources, I can provide you an example where it is not possible.
Assuming I have different data sources, which I have to merge before providing the result to UI. Whenever one datasource is changed, I have to invalidate the other one, to refresh the data and perform mapping from <dataSource1> results to <dataSource1 + dataSource2> results.
For example, it can be an application, which uses public API to get e.g. movies list, but stores information about favorite films locally. In this case, whenever "favorite" flag is changed, movies list data source should be invalidated. And it can not be done from UI. For such situation should be a possibility to invalidate data source e.g. via Pager object or something.

du...@google.com <du...@google.com> #6Aug 17, 2020 04:43PM

Whil I understand your idea of internal invalidates of PagingSources, I can provide you an example where it is not possible. Assuming I have different data sources, which I have to merge before providing the result to UI. Whenever one datasource is changed, I have to invalidate the other one, to refresh the data and perform mapping from <dataSource1> results to <dataSource1 + dataSource2> results.

This sounds like something that the .map transform operator on PagingData would help with.

For example, it can be an application, which uses public API to get e.g. movies list, but stores information about favorite films locally. In this case, whenever "favorite" flag is changed, movies list data source should be invalidated. And it can not be done from UI. For such situation should be a possibility to invalidate data source e.g. via Pager object or something.

It doesn't make sense for the UI / Presentation layer to handle invalidation, it already does this via .refresh(). Invalidation is simply a signal for PagingSource updates. I'm not sure that a favorite flag should warrant multiple layers of PagingSource, but I think I'm not really understanding what's preventing you from hooking up multiple sources of invalidation.

In this case I would recommend to have one DB table / local cache that PagingSource loads directly from, and any updates from the API or from favorite flag flipping would get written to the cache and also invalidate PagingSource. This way you only need to hook up invalidate callbacks from a single source, and you can have independent components writing to the same place.

cl...@gmail.com <cl...@gmail.com> #7Sep 9, 2020 03:33AM

Hi, I'd like to give this a shot if that's okay.

du...@google.com <du...@google.com> #8Sep 9, 2020 09:33PM

Reassigned to cl...@gmail.com.

Sounds good! Just noting for posterity, my prototype will need to kick out invalidated pagingSources to minimize memory pressure.

cl...@gmail.com <cl...@gmail.com> #9Sep 9, 2020 11:58PM

Got it! Thanks.

ap...@google.com <ap...@google.com> #10Nov 20, 2020 06:07PM

Marked as fixed.

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

commit 5ac03b4d8c4a234d8c91aecb03361d8d1b856ad3
Author: Clara F <clarafok3@gmail.com>
Date: Thu Nov 19 21:07:43 2020

[GH] A PagingSource Factory that can be invalidated

## Proposed Changes

A PagingSource Factory that stores references to PagingSources for PagingSource invalidation

## Testing

Test: ./gradlew paging:paging-common:test

This is an imported pull request from

https://github.com/androidx/androidx/pull/98.

Resolves #98
Github-Pr-Head-Sha: 63d2bc166414d4b5134ba1dd5998a2a175ccbe25
GitOrigin-RevId: 037f4fe9037bd1aa255a212091f5b955fe9e4693
Fixes: 160716447
Relnote: "A new abstract class InvalidatingPagingSourceFactory has been added
with an `.invalidate()` API that forwards invalidate to all of the PagingSources
it emits"
Change-Id: Ie71fc1cc974dbc72f42572234ea9053e31b44039

M paging/common/api/current.txt
M paging/common/api/public_plus_experimental_current.txt
M paging/common/api/restricted_current.txt
A paging/common/src/main/kotlin/androidx/paging/InvalidatingPagingSourceFactory.kt
A paging/common/src/test/kotlin/androidx/paging/InvalidatingPagingSourceFactoryTest.kt

https://android-review.googlesource.com/1506419