Status Update
Comments
al...@google.com <al...@google.com> #2
ap...@google.com <ap...@google.com> #3
Thanks for the report!
pe...@google.com <pe...@google.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.
pe...@google.com <pe...@google.com> #5
el...@google.com <el...@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).
al...@google.com <al...@google.com> #7
It's a non-atomic group, so the contained artifacts are versioned (mostly) separately. We version and release the core
artifact with core-ktx
and core-testing
.
Whats the process for rolling out changes to
androidx.core:core
?
Make the changes, then either request a release on go/jetpad or let me know when you want a release. Generally speaking, core
releases whenever contributors (or dependent libraries) need it released. If you need this to go to stable soon, you can file a bug against the core component along the lines of "Release core 1.x.0 to stable" and I'll churn through the process of beta/rc/stable.
pe...@google.com <pe...@google.com> #8
We have some experimental APIs that could do with using this interface. As they're experimental, to not block the library from otherwise progressing through the release train, I assume we need these changes to be in stable?
Filed
Description
See API council conversation here:https://chat.google.com/room/AAAATnZMo34/VJnRMh_50Z8
For Java APIs in AndroidX, there isn't a standard way to deliver an async result that could fail. For Kotlin you'd use a OutcomeReceiver , which was added in API 31.
suspend fun
(which can throw) and for Java APIs in the platform you'd use anFor context, we (
androidx.webkit
) are designing an API that would benefit from being able to useOutcomeReceiver
and we'd prefer to use a standard approach rather than writing our own.I assume that
androidx.core.os
would be the right place for this to live.