Conversation
Julow
left a comment
There was a problem hiding this comment.
Awesome! Do you have examples of apps that send autofills that I can test ?
res/layout/keyboard.xml
Outdated
| @@ -1,2 +1,16 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <juloo.keyboard2.Keyboard2View xmlns:android="http://schemas.android.com/apk/res/android" android:hardwareAccelerated="false" android:background="?attr/colorKeyboard"/> | |||
| <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:hardwareAccelerated="false" android:background="#00000000"> | |||
There was a problem hiding this comment.
I'm working on a suggestion strip for a future word suggestion feature, in this branch: master...candidates_view
Do you have ideas how to make these compatible ? For example, it has a fixed width instead of being scrollable and it has a fixed number of spots for suggestions (3).
There was a problem hiding this comment.
You could add a separate layout below the autofill_container HorizontalScrollView I added here that is visible if a suggestion is available. That way, the sizing and positioning should get handled automatically, even if setting the visibility will still need to be done manually (I don't think there is a way around that)
There was a problem hiding this comment.
Does the autofill makes sense after the user has started typing on the keyboard ? Perhaps the autofill container could be hidden in favor of the suggestion strip after the first key was pressed ?
Bitwarden is one. |
|
I used this test page with KeePassDX to quickly validate changes in Chrome and Firefox. |
Julow
left a comment
There was a problem hiding this comment.
Thanks! I could test with KeePassDX
Since Android 11, Android allows keyboards to display autofill suggestions inline instead of trying to show a popup.
Based on some code in AnySoftKeyboard, this PR introduces support for that feature here.
To do so, I had to modify the default keyboard layout to include a scrollable view in which the components provided by the framework are displayed. I based this on the layout for the emoji pane, but I must admit that I'm not completely happy with the comparatively large number of additional layout bits the java code now needs to keep track of.
(I could have also tried to reimplement their behavior manually, but that seemed overly complicated).
If you have an idea for a better approach the layout and its handling could be modified to take, please suggest it. It has been quite a while since I wrote any android UI stuff without compose, so I'm almost certain I forgot about something.
I set an
android:backgroundon the wrapping layout element in an attempt to get keyboard background opacity to work, which seems to have been successful, but I only really tried it in the keyboard app and the browser, both of which have a single-color background, so if you have another app with a more colorful background to try this with, that would be appreciated.With that said, this implementation of the feature does seem to work quite well in the emulator.