Fixed
Status Update
Comments
dr...@gmail.com <dr...@gmail.com> #2
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
}
}
ki...@google.com <ki...@google.com>
no...@google.com <no...@google.com> #3
add this line :
textView.setLayoutDirection(ViewCompat.getLayoutDirection(textView));
before :
setTextFuture(....)
textView.setLayoutDirection(ViewCompat.getLayoutDirection(textView));
before :
setTextFuture(....)
si...@google.com <si...@google.com> #4
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
}
}
ap...@google.com <ap...@google.com> #5
Sorry. I forgot the info.
minSdk 21
targetSdk 28
Thanks #3 again.
minSdk 21
targetSdk 28
Thanks #3 again.
si...@google.com <si...@google.com>
an...@google.com <an...@google.com> #6
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
dr...@gmail.com <dr...@gmail.com> #7
With reference to comment #4 , issue is resolved by implementing suggested changes in comment #3 . Can you please confirm if we need to still investigate this issue ?
si...@google.com <si...@google.com> #8
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!
dr...@gmail.com <dr...@gmail.com> #9
I think should handle setLayoutDirection in the AppcompatTextView when setTextFuture, it will simpler for dev when implement TextFuture.
Description
When using
ResourcesCompat.getFont
to resolve a .ttf file in res/font, the returnedTypeface
instance always has a weight of 400 and a style ofNORMAL
.On all APIs < 29, style correctly resolves to
ITALIC
. On API 28, weight correctly resolves to 300.The font actually looks correct when displayed on an API 29 device, it just has the wrong values according to the
Typeface
instance.The issue is reproducible in this test class . Several tests fail on API 29 only due to this issue. I've also added a temporary
typefaceBug
test case that uses an ActivityScenario to demonstrate that the text actually appears correctly on API 29.