Fixed
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
We started noticing this on Android 8 and 8.1 devices after we upgraded appcompat library from 1.3.1 to 1.4.0. Seems like that the newest library is using a different/newer classes for handling emojis.
fl...@google.com
da...@google.com
ap...@google.com
Thanks for the report, this is a combination we didn't predict and need to resolve.
In the current version of the libraries, precomputed text won't work with the presence of emoji in 1.4.0. There is no workaround using precomputed text in the current library, so the best solution is to `setText` as proposed.
Notes for resolution (options discussed):
1. Disabling emoji processing for precomputed text from InputFilter etc
2. Integrate emoji into PrecomputedTextCompat to apply emoji processing prior to precomputation (needs research)
In the current version of the libraries, precomputed text won't work with the presence of emoji in 1.4.0. There is no workaround using precomputed text in the current library, so the best solution is to `setText` as proposed.
Notes for resolution (options discussed):
1. Disabling emoji processing for precomputed text from InputFilter etc
2. Integrate emoji into PrecomputedTextCompat to apply emoji processing prior to precomputation (needs research)
[Deleted User] <[Deleted User]>
Going live in next release.
In current release I would recommend one of
- disabling emoji2 on TextViews with precomputed text
- disabling precomputed text if EmojiCompat.process(source) adds any Spans (this may be done/checked on background thread)
To resolve this, precomputed text will be discarded iff an EmojiSpan is being added. This cost will only be incurred if the text requires a replacement span due to platform missing an emoji.
da...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit db5061885534c4b23d4ab3a9246ee9cace4119d8
Author: Sean McQuillan <seanmcq@google.com>
Date: Tue Mar 08 14:47:07 2022
Unprecompute text when adding emoji
Emoji2 will now unwrap PrecomputedText to add emoji automatically. This
has the effect of discarding precomputed text when emoji spans are added.
Apps wishing to optimize this may call EmojiCompat.procss manually, then
avoid the PrecomutedText path if any spans are added.
Relnote: "Emoji2 will add emoji to PrecomputedText by discarding
previously precomputed text layout."
Fixes:
Test: ./gradlew :e2:e2-bun:cAT
Change-Id: I47d066f5cd1f61e0d6338ecc133879fe5bda7e27
M emoji2/emoji2-bundled/src/androidTest/java/androidx/emoji2/bundled/viewstests/EmojiTextViewProcessTest.java
A emoji2/emoji2/src/main/java/androidx/emoji2/text/UnprecomputeTextOnModificationSpannable.java
M emoji2/emoji2/src/main/java/androidx/emoji2/text/EmojiProcessor.java
https://android-review.googlesource.com/2025744
Branch: androidx-main
commit db5061885534c4b23d4ab3a9246ee9cace4119d8
Author: Sean McQuillan <seanmcq@google.com>
Date: Tue Mar 08 14:47:07 2022
Unprecompute text when adding emoji
Emoji2 will now unwrap PrecomputedText to add emoji automatically. This
has the effect of discarding precomputed text when emoji spans are added.
Apps wishing to optimize this may call EmojiCompat.procss manually, then
avoid the PrecomutedText path if any spans are added.
Relnote: "Emoji2 will add emoji to PrecomputedText by discarding
previously precomputed text layout."
Fixes:
Test: ./gradlew :e2:e2-bun:cAT
Change-Id: I47d066f5cd1f61e0d6338ecc133879fe5bda7e27
M emoji2/emoji2-bundled/src/androidTest/java/androidx/emoji2/bundled/viewstests/EmojiTextViewProcessTest.java
A emoji2/emoji2/src/main/java/androidx/emoji2/text/UnprecomputeTextOnModificationSpannable.java
M emoji2/emoji2/src/main/java/androidx/emoji2/text/EmojiProcessor.java
ma...@marcardar.com
Can I know in which appcompat version that includes this fix? I'm using appcompat v1.4.1 and suddenly receive a lot of such crash :(
je...@gmail.com
This fix will be in the next stable release.
da...@google.com
Hi someone is using my device for a business, Google ads, and a YouTube channel. The YouTube is mashup and I found a name in my Facebook where it should have only been my name. Now when I go to look up the emoji comments from the above I'll get a page saying I can't access and it won't let me go.
[Deleted User] <[Deleted User]>
I'd like to know if you can look into this or how will it go?
yb...@google.com
Channels are experimental right now so we probably want to wait until it is stable.
cr...@shou.tv
Channels +1
da...@google.com
Marking as fix since core coroutines are supported in 2.1, in the mean time we'll keep an eye on the Channels API to potentially support it once its upgraded out of experimental. https://issuetracker.google.com/issues/127328278
pi...@gmail.com
Is it expected that we still have to ensure that suspended functions aren't dispatched from the main thread?
The first call (eg `final SupportSQLiteStatement _stmt = __preparedStmtOfDeleteAll.acquire();`) is not wrapped in a callable and can't be done on the ui thread, so we still have to wrap suspensions with our own context.
The first call (eg `final SupportSQLiteStatement _stmt = __preparedStmtOfDeleteAll.acquire();`) is not wrapped in a callable and can't be done on the ui thread, so we still have to wrap suspensions with our own context.
ai...@gmail.com
Kotlinx.coroutines 1.2 released with cold stream abstraction Flow:
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-flow/index.html
It's in "preview" status, but maybe we also could expect some experimental version of Room with Flow support for observable requests
It's in "preview" status, but maybe we also could expect some experimental version of Room with Flow support for observable requests
Description
Version used: 1.0.0
Room currently supports RxJava and LiveData, but it would be great to also have support for Kotlin's Coroutines.
In a basic implementation this could be achieved with supporting the following types:
- Query: Deferred<T>
- Insert: Job or Deferred<Long>
- Delete: Job or Deferred<Int>
- Update: Job or Deferred<Int>
What could be really awesome though would be implementing support for the `suspend` keyword, as the developer would be able to write just:
```
@Query("SELECT * FROM ITEMS")
suspend fun getItems(): List<Item>
```
I understand this might be tricky to implement on your side though, since a suspend function has got a continuation parameter and that might be an issue with the way Room currently works.