Status Update
No update yet.
Comments
du...@google.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.
ia...@gmail.com
Thanks for this, this is something we are definitely interested in! As a workaround, you can check adapter.itemCount.
va...@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.
ap...@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:
yb...@google.com
lu...@gmail.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
du...@google.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
ch...@gmail.com
pagerFlow
.combine(removedItemsFlow) { pagingData, removed ->
pagingData.filter { (it as CollectEntity).id !in removed }
}
.cachedIn(viewmodel.viewModelScope)
.collectLatest {
****
}
i found the same error , if cachedIn is after combine, it will broke up, but it is normal when cachedIn call twice , such as cachedIn().combine().cachedIn() , but it will not cache the combine data, because i want to cache the data after filter
du...@google.com
It's expected to need to call .cachedIn twice there as you've done since re-collection is unsupported on pagingData, operators like combine cause re-collection so without cachedIn you would be expecting to reload the data from scratch any time a new value is emitted to removedItemsFlow
In your example you are correctly caching the filtered data.
After .cachedIn for you (presumably in alpha03).
ch...@gmail.com
In my example i call .cachedIn twice, but actually it doesn't caching the filtered data, so i have to keep the whole remove data and it will filter all remove data in source data every time.
Such as i want to remove data which id is 1， then i remove id 2 ,but when i remove 2,i have to filter 1 again, so i have to save all remove data, so i think the re-collection doesn't work event i call .cachedIn twice
du...@google.com
In my example i call .cachedIn twice, but actually it doesn't caching the filtered data, so i have to keep the whole remove data and it will filter all remove data in source data every time.
Such as i want to remove data which id is 1， then i remove id 2 ,but when i remove 2,i have to filter 1 again, so i have to save all remove data, so i think the re-collection doesn't work event i call .cachedIn twice
Sorry - I'm not sure I entirely understand what you're doing here. .cachedIn doesn't affect what REFRESH returns, it simply prevents repeated work on recollection within the specified scope (for example if you change from landscape to portrait).
However on each new instance of PagingData due to invalidation, you would still need to filter the entire stream of events, since it's a new stream.
ch...@gmail.com
I want to do something like notifyItemRemoved , for example there is a collect list ,i want to uncollect the item1, then uncollect the item2, so when i uncollcet item2 i have to filter item1 again ,
I don’t know if you can understand this example, because i think it's useless when call the .cachedIn after filter, because it can't caching the new filter data , so if i want to remove data,i have to keep all item i want to remove even the data already removed.
du...@google.com
In this case it's recommended to update the backing dataset directly and call invalidate(). We're investigating a page-level flow api that will allow you to control the items themselves without invalidation which you can track in #9.
Calling .cachedIn after .filter prevents your .filter from needing to run again on the same list. For example on configuration change or when navigating between fragments. It has nothing to do with making your filter operation incremental.
ch...@gmail.com
Thank you for your reply,I hope you can proceed smoothly and have more powerful api.
Description
Component used: Paging Version used: 3.0.0-alpha01
I was moving my app over to Paging 3.0.0-alpha01. It uses Room 2.3.0-alpha01 for support for
PagingSource.Dao:
ViewModel:
UI:
Steps to reproduce:
Expected behavior: The new images are seamlessly added
Actual behavior: I received the following exception: