Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
ar...@physitrack.com <ar...@physitrack.com> #3
Thanks for the report!
ha...@gmail.com <ha...@gmail.com> #4
The release notes documentation has been edited to clarify this change in behavior for line height.
To support non-standard text sizes, we encourage users to follow the Material design system and use a different style = LocalTextStyle.current.copy(lineHeight = TextUnit.Unspecified)
, or create a custom Typography
entirely.
an...@sigma.software <an...@sigma.software> #5
deleted
ma...@google.com <ma...@google.com>
co...@google.com <co...@google.com>
ap...@google.com <ap...@google.com> #6
In my case, I have multiple font sizes in the same Text
(using SpanStyle
in AnnotatedString
). There are legitimate reasons for this. For example, when combining Chinese and English (phonetic) together (for language-learning purposes).
Description
I've been testing the new PullToRefresh implementation in M3 and finding a number of issues, both functional and API ergonomics.
1. No exit animation when
endRefresh()
is calledThis one is fairly straightforward and visible in the attached example. I would expect this to animate the progress indicator back to rest.
2. The indicator is always drawn above the content, including on top of other content
This is more serious bug, as it results in what looks like a floating artifact in the UI. The indicator implementation seems to assume that the container is always pushed up against the top of the display, and thus wouldn't worry about drawing the indicator. However, when used in even simple scaffolds with a top app bar of some sort, it will draw the indicator (even when not refreshing) on top of the app bar. This is visible in the attached examples as well.
3. The container intercepts upward scroll events in nested scrolling conditions
This is visible in the attachment as well. In a scaffold with a collapsing/moving top bar, the container will actively intercept upward scroll events in some cases and prevent expansion of the top app bar.
4. The API is awkward and a regression from the M2 implementation
The M2 implementation offered an
onRefresh: () -> Unit
callback that made using this dead simple. It also better aligned with what this UI ultimately is - a glorified refresh button implemented as a gesture. In the new M3 API, there is no such hook. Instead, one has to directly observe theisRefreshing
boolean state. In simple cases (such as the samples) where the UI is directly suspending/blocking on some refresh call to the data layer, this works ok. However, it quickly breaks down when interacting with more real-world cases where a refresh event is signaled to the data layer (such as viaLazyPagingItems.refresh()
) and awaiting an updated load state.The result is that the user has to manually implement this synchronization of states. If it's refreshing but the pager load state isn't loading, you now have to independently track if
I've attached a screenshot example of what this synchronization tedium looks like in practice