IssueTracker

+cc Siyamed and Matvei

• For the context, there've been this bug b/155211005 that also proposed to have a String overload for the foundation text field. This bug is marked as fixed. So I'm wondering whether we did not provide this primitive override on purpose.

• Since we're considering merging the BaseTextField and CoreTextField, do we want to have the primitive override in a single 'core' text field?

do we want to have the primitive override in a single 'core' text field

I don't think so. This whole bug is a side effect of the naming problem we've already fixed. I would suggest to close this bug as fixed because of renaming and original problem being infeasible anymore.

If someone is reimplementing their TextField for their design need, I expect them to be ok with TextFieldValue hoisting or them be able to wrap this API with their string overload.

It seems reasonable to separate selection range and value long term, but maybe I'm missing some cases there where this might not work. Over to Siyamed to give some input here

I'm not actually sure that the Material TextFields fully replace this API – it's pretty common to need text input in various contexts that aren't well supported by the styling of a material TextField.

In particular, the label is often undesired in interactive inputs (search fields / inline data entry) and typical applications will need to use BaseTextField in typical application coding.

I'm currently working on a TODO sample app and am copy/pasting the code from TextField to manage state into the sample. I can't use either of the material text fields in this UI location.

@OptIn(ExperimentalFoundationApi::class)
@Composable
fun TodoTextField(value: String, onValueChange: (String) -> Unit, modifier: Modifier = Modifier) {
    // this code is used to manage the selection and composition state of the BaseTextField
    var textFieldValue by state { TextFieldValue() }
    if (textFieldValue.text != value) {
        @OptIn(InternalTextApi::class)
        textFieldValue = TextFieldValue(
            text = value,
            selection = textFieldValue.selection.constrain(0, value.length)
        )
    }
    BaseTextField(
        value = textFieldValue,
        onValueChange = {
            val previousValue = textFieldValue.text
            textFieldValue = it
            if (previousValue != it.text) {
                onValueChange(it.text)
            }
        },
        modifier = modifier
    )
}

It seems in general if we find that a material component requires an API like this for usability the core equivalent should be exposed similarly.

One thought is that maybe the label parameter should be optional in material text fields? Even though you can do label = {}, but label parameter being non-optional maybe makes it confusing.

Assigning to Anastasia for future work or to close

We now provide both String and TextFieldValue overrides in both material and foundation text fields.

For this bug we're looking at 2 things: -

• the additional build types that are created to generate baseline profiles and benchmark
• the build types that are visible in AS

There is a bug that should be fixed by aosp/3260794 about build types that should not be created. The AS part was to check that these wouldn't be visible. Will add this to version 1.3.1.

Thanks

I confirm this will be in 1.3.1

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.benchmark:benchmark-baseline-profile-gradle-plugin:1.3.1