Fixed
Status Update
No update yet.
Comments
si...@google.com
We have some support in androidx.compose.ui.autofill
Leaving this bug open in case Ralston wants to add more info
tc...@google.com
I found an example
D/Autofill Status: Autofill popup isn't shown because autofill is not available.
Did you set up autofill?
1. Go to Settings > System > Languages&input > Advanced > Autofill Service
2. Pick a service
Did you add an account?
1. Go to Settings > System > Languages&input > Advanced
2. Click on the settings icon next to the Autofill Service
3. Add your account
Is this a bug on your side or do the app developers of these password managers need to change their implementation?
si...@google.com
si...@google.com
si...@google.com
se...@google.com
se...@google.com
se...@google.com
ap...@google.com
deleted
ap...@google.com
Facing the same issue here, Google autofill service seems to work. Zero documentation on adding support for Autofill framework on jetpack compose.
ap...@google.com
Hello, I am trying to implement the same thing - it seems like there's no way for current password managers like 1Password or Bitwarden, to automatically pick up the fields. Is there a possible solution?
Description
Specifically, a user wanted to "close the software keyboard in onClick on a button", and Fudge's workaround was to capture the SoftwareKeyboardController in the onTextInputStarted callback and write it into a field in the parent. var controller by remember { mutableStateOf<SoftwareKeyboardController?> { null } } Button("Close", onClick={controller!!.hideSoftwareKeyboard()}) // Pray this doesn't crash (NPE) TextField(value=..., onClick=..., onTextInputStarted={c -> controller = c})
A better pattern would be to have the user create a SoftwareKeyboardController as-if it were a hoisted state object and pass it into the TextField. val controller by remember { SoftwareKeyboardController() } Button("Close", onClick={controller.hideSoftwareKeyboard()}) TextField(value=..., onClick=..., controller=controller)
We realize/expect this requires playing a bit of a trick with the internal implementation of the SoftwareKeyboardController, to make the hideSoftwareKeyboard() function capable of operating as if it were the source of truth, even though the actual source of truth doesn't exist until later when the TextField is initialized by Android, which is probably one reason why it didn't occur to the original author of this widget. But it results in a much cleaner declarative API with less reasoning about the flow of information.
Discussion in API Council back in August, but I don't think a bug ever got filed for this.