:wave: On a widget with a `BasicTextField` and an ...
# compose
j
šŸ‘‹ 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?
a
Copy code
SoftwareKeyboardController
FocusRequester
is what i used before, not sure it fits the use case or if its still up to date
z
ā˜ļø 1
j
I’m not sure I’m following, this is the code:
Copy 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?
z
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.
Still, I wonder if you could still use decoration box and just not call the
innerTextField
function conditionally?
j
Sorry šŸ™‚
Lemme try…
It kinda works. Even though the docs say
Copy code
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).
z
Yea, this feels pretty hacky, but might be a use case they want to consider?
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
j
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ā€.
z
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.
j
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.
z
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.
j
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!
z
yea idk what the expected behavior even is, since this technically violates the contract described in the doc