TextField/FilledTextField should have String overloads instead of TextFieldValue overloads [155211005]

Fixed

Feature Request

Status Update

No update yet.

Description

le...@google.com

created issue #1

Apr 28, 2020 07:38PM

Currently we have TextField variants with the following `value`, `onValueChange` parameters:

CoreTextField(EditorValue, (EditorValue) -> Unit) (in ui.text)
TextField(EditorValue, (EditorValue) -> Unit) (in ui.foundation)
TextField(TextFieldValue, (TextFieldValue) -> Unit) (in ui.foundation)
FilledTextField(TextFieldValue, (TextFieldValue) -> Unit) (in ui.material)
FilledTextField(String, (String) -> Unit) (in ui.material)

EditorValue is the most powerful API, where every aspect of the text field is controllable, but also more cumbersome to use.
TextFieldValue is middle-weight, with only string value and selection controllable, but still a bit cumbersome to use
String is the least powerful API, but also the most convenient and powerful enough to satisfy the overwhelming majority of use cases.

My suggestion is to refactor these overloads to have each one fit into one of two overloads:
1. EditorValue-based (cumbersome, powerful)
2. String-based (convenient, useful)

The string-based variants would have an `onSelectionChanged: (Selection) -> Unit` parameter, but would not allow for a selection to be *controlled* (hence the past tense on the parameter name).

It seems to me like the need to control or listen to the selection state are both somewhat rare, but the need to control it is even more so. On the other hand, the need to control the text value is virtually 100% of the time. As a result, adding the overhead of the selection controllability in the common case feels wrong, since the times you might want to do that, the more powerful EditorValue API might be something you need to reach for anyway.

As a result, my proposal is to have the following APIs:

in ui.text:
fun CoreTextField(value: EditorValue, onValueChange: (EditorValue) -> Unit) (unchanged)

in ui.foundation:
fun TextField(EditorValue, (EditorValue) -> Unit) (unchanged)
fun TextField(value: String, onValueChange: (String) -> Unit, onSelectionChanged: (Selection) -> Unit)

in ui.material:
fun FilledTextField(EditorValue, (EditorValue) -> Unit)
fun FilledTextField(value: String, onValueChange: (String) -> Unit, onSelectionChanged: (Selection) -> Unit)

Comments

si...@google.com <si...@google.com> #2May 11, 2020 05:22PM

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

Message last modified on May 25, 2020 07:32PM

si...@google.com <si...@google.com> May 26, 2020 01:23AM

Reassigned to si...@google.com.

si...@google.com <si...@google.com> Jun 5, 2020 12:19AM

Accepted by si...@google.com.

si...@google.com <si...@google.com> #3Jun 9, 2020 04:44AM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

Message last modified on Jun 9, 2020 04:45AM

si...@google.com <si...@google.com> #4Jun 10, 2020 05:53AM

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

si...@google.com <si...@google.com> #5Jun 10, 2020 06:28AM

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

si...@google.com <si...@google.com> #6Jun 10, 2020 09:48PM

Marked as fixed.

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

ap...@google.com <ap...@google.com> #7Jun 10, 2020 10:54PM

FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model. https://developers.google.com/ml-kit/release-notes#august_11_2021

Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!

si...@google.com <si...@google.com> #8Jun 15, 2020 11:28PM

Status: Assigned (reopened)

Thank you, I'll try it and check.

si...@google.com <si...@google.com> Jun 16, 2020 01:47AM