Status Update
No update yet.
Comments
no...@gmail.com
With paging2 and the PagedListAdapter, I was simply checking if the list was empty before sending it to the adapter so I wasn't handle it with the adapter (which is probably wrong).
I tried to migrate to paging3 but I couldn't because I don't know how to check if the list is empty, as the PagingData that we send to the new adapter doesn't expose the list or an isEmpty method.
du...@google.com
Thanks for this, this is something we are definitely interested in! As a workaround, you can check adapter.itemCount.
b9...@gmail.com
We have a sample snippet showing how to use adapter.itemCount in this way, but forgot to link it in KDocs (whoops):
Will fix.
du...@google.com
To be clear, adapter.itemCount will only work if placeholdersEnabled is false.
We held off on this change because we wanted to take some time to properly explore what it would look like to provide a public API to view the PagingState or the internal PageEvent stream, but it's clear there's immediate need for this.
In the meantime, here's an idea for a CL which adds a Boolean to dataRefreshFlow, which we could merge for alpha02:
du...@google.com
Branch: androidx-master-dev
commit 0deeb4e05177350b8c2b444e6db418b9fc7aa66b
Author: Chris Craik <ccraik@google.com>
Date: Tue Jun 16 08:26:09 2020
Actually link addLoadStateListenerSample in kdocs
Bug: 159054196
Test: Ctrl-Q in Studio
Change-Id: Ieabb25de3625a22f8107f1192af54e986a50d1d3
M paging/runtime/src/main/java/androidx/paging/PagingDataAdapter.kt
b9...@gmail.com
Branch: androidx-master-dev
commit 38a9eb05e73e822f70348aa22264b36e6790dba8
Author: Dustin Lam <dustinlam@google.com>
Date: Tue Jun 16 09:24:15 2020
Add isEmpty param to dataRefreshFlow / listener
RelNote: "The adapter APIs, dataRefreshFlow and dataRefreshListener
now pass a Boolean to signal whether a PagingData is empty"
Fixes: 159054196
Test: ./gradlew paging:paging-runtime:cC
Change-Id: I6e37e844cf9f947aeefaaa99d22b2672e04f207d
M paging/common/src/main/kotlin/androidx/paging/PagingDataDiffer.kt
M paging/common/src/test/kotlin/androidx/paging/PagingDataDifferTest.kt
M paging/runtime/api/3.0.0-alpha02.txt
M paging/runtime/api/current.txt
M paging/runtime/api/public_plus_experimental_3.0.0-alpha02.txt
M paging/runtime/api/public_plus_experimental_current.txt
M paging/runtime/api/restricted_3.0.0-alpha02.txt
M paging/runtime/api/restricted_current.txt
M paging/runtime/src/main/java/androidx/paging/AsyncPagingDataDiffer.kt
M paging/runtime/src/main/java/androidx/paging/PagingDataAdapter.kt
du...@google.com
To be clear the above sample is a workaround a deeper issue in Paging which isn't handling cancellation gracefully due to Remote REFRESH errors not blocking remote PREPEND / APPEND.
b9...@gmail.com
I found that if using fragment.lifecycleScope.launchWhenResume to collect each page data then it will work normally. ViewPager2 FragmentStatePager will move fragment to onResume/onPause.
du...@google.com
Good to hear, I think we can still do a better job of handling cancellation and propagating remote state, e.g., if you have many pages in viewpager and flip back and forth I think you'll still eventually get stuck, since the collector on PagingData will get canceled and there's no invalidate signal to restart it without manually calling adapter.refresh().
yb...@google.com
ap...@google.com
Branch: androidx-master-dev
commit c97e21810e49b3f8043c8d7c3951b16e8b38e6db
Author: Yigit Boyar <yboyar@google.com>
Date: Fri Oct 16 10:39:22 2020
Add priority to single runner
This CL adds ability to accept priority to SingleRunner.
It will be necessary for the new remote mediator implementation
where it will rely on single runner to cancel lower priority
requests.
Bug: 162252536
Test: SingleRunnerTest
Change-Id: I01351ac385b252f80ab6079d42f2cf0edf8d6667
M paging/common/src/main/kotlin/androidx/paging/SingleRunner.kt
M paging/common/src/test/kotlin/androidx/paging/SingleRunnerTest.kt
ap...@google.com
Branch: androidx-master-dev
commit f86129d60bb33243d06837291f0e2bd0f26f4bd3
Author: Yigit Boyar <yboyar@google.com>
Date: Fri Oct 09 11:34:07 2020
RemoteMediatorAccessor Refactor
This CL changes how remote mediator and snapshots interact.
Previously, all calls to remote mediator were done in a
snapshot's scope and snapshot was also responsible to track
load states.
It created a problem where remote mediator calls would be
cancelled when snapshot is replaced by a newer one. It also
made the load state logic fairly complicated in PageFetcherSnapshot.
This CL de-couples the two as much as possible.
With this change, RemoteMediatorAcccessor uses the scope of
the `Pager.flow` collection instead of the scope from the
PageFetcherSnapshot. PageFetcherSnapshot is now only responsible
to send events to the accessor when it needs more data.
RemoteMediatorAccessor manages its own loading state.
We still need some syncronization between the two to ensure certain
load events are not dispatched before data is loaded (e.g. after a
pull to refresh, you don't want refresh state to go idle before the
new local data is loaded for UI consistency). This logic is now
handled by the PageFetcher where it appends the load states to each
insert page and for other events (loading, error), directly sends them
to the downstream.
Bug: 162252536
Test: RemoteMediatorAccessorTest, PageFetcherSnapshotTest
Relnote: "Paging will no longer cancel a `RemoteMediator#load` call
due to a page invalidation. It will also no longer make an
append/prepend load request, *if REFRESH is required*, until REFRESH
request completes successfully."
Change-Id: I6390be0c0c1073005456f928a2a8afa81c16d3ef
M paging/common/api/current.txt
M paging/common/api/public_plus_experimental_current.txt
M paging/common/api/restricted_current.txt
M paging/common/src/main/kotlin/androidx/paging/CachedPageEventFlow.kt
M paging/common/src/main/kotlin/androidx/paging/LoadStates.kt
M paging/common/src/main/kotlin/androidx/paging/MutableLoadStateCollection.kt
M paging/common/src/main/kotlin/androidx/paging/PageEvent.kt
M paging/common/src/main/kotlin/androidx/paging/PageFetcher.kt
M paging/common/src/main/kotlin/androidx/paging/PageFetcherSnapshot.kt
M paging/common/src/main/kotlin/androidx/paging/PageFetcherSnapshotState.kt
M paging/common/src/main/kotlin/androidx/paging/PagingDataDiffer.kt
M paging/common/src/main/kotlin/androidx/paging/RemoteMediator.kt
M paging/common/src/main/kotlin/androidx/paging/RemoteMediatorAccessor.kt
M paging/common/src/test/kotlin/androidx/paging/PageEventTest.kt
M paging/common/src/test/kotlin/androidx/paging/PageFetcherSnapshotStateTest.kt
M paging/common/src/test/kotlin/androidx/paging/PageFetcherSnapshotTest.kt
M paging/common/src/test/kotlin/androidx/paging/RemoteMediatorAccessorTest.kt
M testutils/testutils-paging/src/main/java/androidx/paging/RemoteMediatorMock.kt
Description
Version used: Paging-3.0.0-alpha03, ViewPager2-1.0.0, Material-1.2.0-rc01
Devices/Android versions reproduced on: Samsung M40(SM-M405F) running Android 10
I am using PagingDataAdapter for my recyclerview in the fragment inside a viewpager. I am following Page from network and database as instructed in
Whenever I load my fragment, load() function with loadtype REFRESH triggers but in the middle of it, the suspend function gets cancelled. I am unable to find out which function is calling cancel(). Even though loadtype REFRESH get cancelled, subsequent PREPEND and APPEND loads are not cancelled. And its causing me a issue that remote keys are not stored in the database when in REFRESH.
And this issue is reproducing only in alpha03 not in alpha02.
I attached the sample project with this issue, Actually its an update over the PagingWithNetwork Sample with a new activity for ViewPager. Checkout the implementation in PagerActivity.
PagerActivity calls ViewPagerFragment onCreate() which contains TabLayout and ViewPager2. And I added two fragments with different subredditName for demo purpose, first is with subreddit "androiddev" and later is "Kotlin". I added delay and yield for only "androiddev" in RemoteMediator to demonstrate cancelling of suspend function.