Hi! Is there a way to listen for keyboard inputs when the keyboard has started the process of hidin...

# compose

[robercoding]

Hi!

Is there a way to listen for keyboard inputs when the keyboard has started the process of hiding? (Not when it's already hidden, it takes a bit of time)
Or even better: Is there any way to intercept back handler when the keyboard is open?

I see similar questions on SO have been asked but I don't see any answer 😅

[robercoding]

The only solution is:
WindowInsets.isImeVisible but this looks ugly in UX since the keyboard takes around 300ms to be hidden or more and I want functions to run immediately after pressing back wether the keyboard is up or not

[Zach Klippenstein (he/him) [MOD]]

There are callbacks for when the animation starts and finishes, but afaik the Compose insets APIs don’t currently expose hooks for them

[Zach Klippenstein (he/him) [MOD]]

Unless @George Mount added that recently that i’m not aware of

[efemoney]

The insets are animated. You can do WindowInsets.ime == 0

[robercoding]

Didn't see that one @efemoney but I don't think it works because seems to represent the space in pixels and that goes in hand with the animation since I only know if it's visible when it has reached the maximum space or hidden because it's 0.
Moreover, I don't know the direction of the keyboard if it's going to close or hide, anyways appreciate it

[james]

I wrote a function to workaround not having an exposed end-of-anim callback and improve this UX a little

essentially it is a suspending function which runs a loop with a timeout. so it:
• fires a function requesting keyboard hide
• while ime.getBottom > 0, keep looping with a delay of 1ms
• if we surpass 300ms, break out of the loop
• finally, fires a lambda callback
the function certainly feels hacky but the UX is surprisingly good and it works as expected on each device I tested it on, including my Fold which sometimes has strange quirks

it’s interesting Zach mentions there are private/internal callbacks for these animations, I wonder if anyone has filed a feature request to expose them publicly

[james]

I should clarify: when I say “works as expected” on each device I mean, it never even hits my 300ms timeout, because the ime.getBottom call returns 0 before that

[robercoding]

• fires a function requesting keyboard hide

• while ime.getBottom > 0, keep looping with a delay of 1ms

• if we surpass 300ms, break out of the loop

• finally, fires a lambda callback

But that's for listening to the end of an animation, I'd like to know when it starts the animation for cases that I can't control like:
• The Keyboard is up, the user presses back and the keyboard starts hiding
For cases where I request the keyboard?.hide() I can manage it by myself since I already run the function along the keyboard?.hide()

Not sure if your workaround is the solution I'm looking for

[Alex Vanyo]

Two new APIs that should useful here were introduced in `1.4.0-alpha1`: WindowInsets.imeAnimationSource and WindowInsets.imeAnimationTarget

[efemoney]

@robercoding I just realized I misread and instead (if youre on 1.4 alpha) you probably need WindowInsets.imeAnimationTarget != WindowInsets.imeAnimationSource to signify that the animation is started.

[robercoding]

Omg it works super nice! thanks a lot everyone!! 🫶