Are soft keyboards somehow tied to the current win...

# compose-android

[Alex Styl]

Are soft keyboards somehow tied to the current window on android?

I am trying to use Compose's LocalSoftwareKeyboardController but I can't dismiss the keyboard from a modal/dialog if the reference of the SoftwareKeyboardController was taken from outside of the dialog's scope.

[Alex Styl]

on top of that, if the dialog shows the softkeyboard, it just dissapears instantly (no animation) when the dialog goes aways, which looks ugly.

is there a way to keep the softkeyboard after the dialog is dismissed?

[Alex Vanyo]

Yes, generally. If you retrieve LocalSoftwareKeyboardController outside the Dialog, it'll be a different instance than the one you get retrieving it inside the Dialog

[Alex Styl]

@Alex Vanyo what does it mean in reality? is each instance only allowed to control its window's soft keyboard?

cant find any docs around this

[Alex Styl]

Regarding the dialog animation, it turned out that the ime animation is somehow tied to the dialog's windowAnimationStyle.

Thread on X with full investigation

[Alex Vanyo]

It looks like you've found the window flags and how behavior can be subtly different across window versions, welcome to dealing with software keyboard behavior 😄

what does it mean in reality

In reality in means behavior ends up being very whack-a-mole: getting off the expected path can ends up in weird situations. The history of LocalSoftwareKeyboardController and the underlying SoftwareKeyboardControllerCompat from androidx.core is trying to deal with the weirdness