I'm trying to implement a PIN entry text field, th...

# compose

[aoriani]

I'm trying to implement a PIN entry text field, therefore it can only accept digits and it has a fixed number of digits. I was considering using BasicTextField and its onValueChanged parameter to filter out any non-digit character. However, reading the documentation I found this :

Please keep in mind that onValueChange is useful to be informed about the latest state of the text input by users, however it is generally not recommended to modify the value that you get via onValueChange callback. Any change to this value may result in a context reset and end up with input session restart. Such a scenario would cause glitches in the UI or text input experience for users.

Does that mean that something like

var text by rememberSaveable { mutableStateOf("") }
BasicTextField(
    value = text,
    onValueChange = { input ->
        text = input.filter { it.isDigit() }.take(5)
    }
)

could be a problem because I am not passing input as is to value ?

[Siyamed]

This looks fine to me. At the end it is the goal: user entering a char and app rejecting it therefore the flow afterwards is what is should be.

[ephemient]

that might be ok for digits, but in general filtering input is trickier than that due to IME composition

[ephemient]

(not directly related, but like in the old TextView you should add

keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Number)

so that the right type of soft keyboard can be shown to the user)

[aoriani]

Thanks for the response.

and what about using decorationBox but not calling the innerTextField composable that is passed to it as argument, in order to implement my own visuals of the text field's value . I see people using that trick and rendering each digits as its own Text composable with border and what not. I wonder if not calling innerTextField could create problems.

My goal is to have some custom input widget. Thus I was wondering if I could leverage BasicText. Implementing a view from scratch that could interact with IME was already painful. I imagine that doing the same for a composable would be the same or worse.

[aoriani]

@ephemient I did that. IME will still show dot and negative signal that I will filter out. And I still need to handle hardware keyboard.

[ephemient]

yes, of course you do. but showing the right soft keyboard is a better experience for the user. that's why I said it's not directly related