:wave: On a widget with a `BasicTextField` and an `IconButton`, I’d like to give focus to the text f...

# compose

[julioromano]

👋
On a widget with a BasicTextField and an IconButton, I’d like to give focus to the text field (and therefore have the on screen keyboard appear) at the press of the button.
Which API should I use?

[Adriano Celentano]

SoftwareKeyboardController
FocusRequester

is what i used before, not sure it fits the use case or if its still up to date

[Zach Klippenstein (he/him) [MOD]]

Have you seen the new decorationBox API in alpha11? https://android-review.googlesource.com/c/platform/frameworks/support/+/1537302

[julioromano]

I’m not sure I’m following, this is the code:

@Composable
fun MyWidget(
    text: String,
    onTextChange: (text: String) -> Unit
) {
    var isVisible by mutableStateOf(false)
    if (isVisible) {
        BasicTextField(
            value = text,
            onValueChange = onTextChange
        )
    } else {
        IconButton(
            onClick = {
                isVisible = true
                // we should shift focus on BasicTextField here
                // therefore the on screen keyboard should reveal itself
            }
        ) {
            Icon(
                imageVector = <http://Icons.Default.Info|Icons.Default.Info>,
                contentDescription = null
            )
        }
    }
}

How can the decorationBox help here?

[Zach Klippenstein (he/him) [MOD]]

Ah, I’m not sure it would. From your original question, I interpreted you to mean that the button and the text field were shown at the same time.

[Zach Klippenstein (he/him) [MOD]]

Still, I wonder if you could still use decoration box and just not call the innerTextField function conditionally?

[julioromano]

Sorry 🙂

[julioromano]

Lemme try…

[julioromano]

It kinda works. Even though the docs say

You must call innerTextField exactly once.

it is possible to call it 0 times.

Though when isVisible is flipped to true and innerTextField is actually called, the text field becomes visible but still no keyboard pops up automatically (another tap in the text field is needed).

[Zach Klippenstein (he/him) [MOD]]

Yea, this feels pretty hacky, but might be a use case they want to consider?

[Zach Klippenstein (he/him) [MOD]]

As for the keyboard not showing, i’m asssuming that’s a bug? There’s been so many keyboard bugs in Compose recently it seems, i’ve lost track

[julioromano]

Dunno 🤷 I’m just at the beginning in this compose journey.
That’s why I was originally looking for a way to shift focus “on demand”.

[Zach Klippenstein (he/him) [MOD]]

I would probably file it as a bug, the compose team is actually pretty good about addressing bugs filed to them. And if it’s not an implementation bug, then it probably means the documentation needs to be improved.

[julioromano]

You mean filing a bug because it is possible to call innerTextField 0 times?
Or because of the focus thing?
IMHO it’s correct that calling innerTextField merely shows the text field without necessarily shift focus to it.
One would not always want to move focus into a text field on every recomposition.

[Zach Klippenstein (he/him) [MOD]]

I think it’s a bug because, as i understand decoratedBox, the text field should get focus any time the box has focus. If the text view was already shown, and you clicked in the box, then it would definitely be a bug if the text field wasn’t shown.

I suspect the resolution to the bug would be “throw if called zero or >1 times”, but at least then it prevents others from going down this path erroneously.

[julioromano]

I believe it’s again a miscommunication on my side.

Here’s the bug along with the sample code I used https://issuetracker.google.com/issues/179280360

To me it seems there’s no focus issue, it’s fine that there are no focus changes when the inner text field shows up after recomposition because the isVisible state var has changed.

If I got it wrong and you still think there may be a bug somewhere feel free to add details to the bug report.

Thanks!

[Zach Klippenstein (he/him) [MOD]]

yea idk what the expected behavior even is, since this technically violates the contract described in the doc