Status Update
No update yet.
Comments
du...@google.com
the same issue for SmallTopAppBar:
ia...@gmail.com
Branch: androidx-main
commit 46c69840b7e4462f71a2289213f2771ae7702c9f
Author: Shalom Gibly <sgibly@google.com>
Date: Wed Oct 12 16:05:59 2022
Updates medium and large top app bar background
Updates to apply the same background color to both part of the Medium or
Large top app bar.
This change also allows such a top app bar to be made transparent.
Bug: 249688556
Bug: 250838918
Test: AppBarTest passing
Relnote: "Updates Material3 Medium and Large top app bars to apply the
same background color across their entire surface, and to allow setting
overriding the default colors with transparent color values."
Change-Id: I67659d8754b953165a5b2fa3c7a5720a0976665e
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/AppBar.kt
va...@gmail.com
ap...@google.com
This is my workaround for this issue
MaterialTheme(
colorScheme = MaterialTheme.colorScheme.copy(
//The color you want for the second top app bar
surface = MaterialTheme.colorScheme.primary
),
typography = MaterialTheme.typography
) {
LargeTopAppBar(
modifier = Modifier.background(MaterialTheme.colorScheme.primary),
title = {
Text("Wednesday")
},
)
}
yb...@google.com
lu...@gmail.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.0.1androidx.compose.material3:material3:1.1.0-alpha02
du...@google.com
This issue is still present in material3:1.0.1 - moving to 1.1.0-beta01 fixed it for me.
ch...@gmail.com
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: