Assigned
Status Update
No update yet.
Comments
ki...@google.com
si...@google.com
ja...@gmail.com
Or when changing to textView.textMetricsParamsCompat still crash.
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
ru...@gcpsoftware.com
add this line :
textView.setLayoutDirection(ViewCompat.getLayoutDirection(textView));
before :
setTextFuture(....)
textView.setLayoutDirection(ViewCompat.getLayoutDirection(textView));
before :
setTextFuture(....)
e....@gmail.com
Thanks, #3. It worked.
But I think it is better when set before this line
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
Set android:layoutDirection="locale" or android:layoutDirection="inherit" for AppCompatTextView in the XML layout didn't this problem.
The new method btw re-set layoutDirector. Weird! This should handle in the AppcompatTextView.
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
textView.layoutDirection = textView.layoutDirection
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
But I think it is better when set before this line
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
Set android:layoutDirection="locale" or android:layoutDirection="inherit" for AppCompatTextView in the XML layout didn't this problem.
The new method btw re-set layoutDirector. Weird! This should handle in the AppcompatTextView.
private fun setAsyncText(textView: AppCompatTextView, text: String?) {
if (!text.isNullOrEmpty()) {
textView.layoutDirection = textView.layoutDirection
val textFuture = PrecomputedTextCompat.getTextFuture(text!!, textView.textMetricsParamsCompat, null)
textView.setTextFuture(textFuture) //Crash
}
}
jh...@themeetgroup.com
Sorry. I forgot the info.
minSdk 21
targetSdk 28
Thanks #3 again.
minSdk 21
targetSdk 28
Thanks #3 again.
ap...@google.com
App Crash at
TextViewCompat.java:889
if (!param.equals(precomputed.getParams())) {
throw new IllegalArgumentException("Given text can not be applied to TextView.");
}
PrecomputedTextCompat.class:334
with : this.mTextDir != other.getTextDirection() == true
So,
TextDirection on TextView and TextDirection on Param is difference
maybe, it handled wrong or missing conditional on getTextDirectionHeuristic of TextViewCompat
TextViewCompat.java:889
if (!param.equals(precomputed.getParams())) {
throw new IllegalArgumentException("Given text can not be applied to TextView.");
}
PrecomputedTextCompat.class:334
with : this.mTextDir != other.getTextDirection() == true
So,
TextDirection on TextView and TextDirection on Param is difference
maybe, it handled wrong or missing conditional on getTextDirectionHeuristic of TextViewCompat
ap...@google.com
With reference to
ap...@google.com
Yes. textView.layoutDirection = textView.layoutDirection(>= API17) or ViewCompat.setLayoutDirection(textView, ViewCompat.getLayoutDirection(textView)) will resolve this bug.
But I think you should handle it in the AppcompatTextView. It is better. If a developer forgets testing with RTL. I think this is the nightmare(it is difficult to determine the bug) when they update their app on the Play Store.
I read this article, in the part databing he noted about set the direction
https://medium.com/google-developers/prefetch-text-layout-in-recyclerview-4acf9103f438 '
fun asyncText
..........
// first, set all measurement affecting properties of the text
// (size, locale, typeface, direction, etc)
But in the offical document isn't good (lack direction)
https://developer.android.com/reference/androidx/appcompat/widget/AppCompatTextView.html#setTextFuture(java.util.concurrent.Future%3Candroidx.core.text.PrecomputedTextCompat%3E)
Anything layout related property changes, text size, typeface, letter spacing, etc after this method call will causes IllegalArgumentException during View measurement.
My view: Handling this in the AppcompatTextView is the best choice if you can do it.
Thanks!
But I think you should handle it in the AppcompatTextView. It is better. If a developer forgets testing with RTL. I think this is the nightmare(it is difficult to determine the bug) when they update their app on the Play Store.
I read this article, in the part databing he noted about set the direction
fun asyncText
..........
// first, set all measurement affecting properties of the text
// (size, locale, typeface, direction, etc)
But in the offical document isn't good (lack direction)
Anything layout related property changes, text size, typeface, letter spacing, etc after this method call will causes IllegalArgumentException during View measurement.
My view: Handling this in the AppcompatTextView is the best choice if you can do it.
Thanks!
ap...@google.com
I think should handle setLayoutDirection in the AppcompatTextView when setTextFuture, it will simpler for dev when implement TextFuture.
e....@gmail.com
We have passed this to the development team and will update this issue with more information as it becomes available.
xa...@gmail.com
Fix released with appCompat 1.0.2, core 1.0.1
Description
Motivation:
With android:textFontWeight backported (backed by the above-mentioned method) we could use text appearances with different weights - by referencing font family and weight - since API 16 (?) in AppCompatTextView.
This is currently only possible since API 28.
Another potential use is a future TypeAppearanceSpanCompat.
Example:
res/font/raleway.xml
<font-family xmlns:app="
<font
app:font="@font/raleway_thin"
app:fontStyle="normal"
app:fontWeight="100" />
<font
app:font="@font/raleway_thin_italic"
app:fontStyle="italic"
app:fontWeight="100" />
<font
app:font="@font/raleway_regular"
app:fontStyle="normal"
app:fontWeight="400" />
</font-family>
res/values/styles.xml
<resources>
<style name="TextAppearance.Raleway.Regular" parent="TextAppearance.AppCompat">
<item name="android:fontFamily">@font/raleway</item>
<item name="android:textFontWeight">400</item>
<item name="textFontWeight">400</item>
</style>
<style name="TextAppearance.Raleway.Thin" parent="TextAppearance.AppCompat">
<item name="android:fontFamily">@font/raleway</item>
<item name="android:textFontWeight">100</item>
<item name="textFontWeight">100</item>
</style>
<style name="TextAppearance.Raleway.Thin.Italic" parent="TextAppearance.AppCompat">
<item name="android:fontFamily">@font/raleway</item>
<item name="android:textFontWeight">100</item>
<item name="textFontWeight">100</item>
<item name="android:textStyle">italic</item>
</style>
</resources>
Example implementation:
On API 26-27 we could re-implement Typeface.create mentioned above as the backing JNI method already exists.
See
On API 21-25 we'd need to first create a Typeface with matching italic (using the Typeface.create with style API) and then use the JNI method to create weight alias.
See
On API 20 and below we could leverage the fact that the only place weight typefaces could come from are from ResourcesCompat.getFont so we use TypefaceCompat internals to find the font family and look for best match in Java.
See