Is there a way for the compose inset APIs to give ...

# compose-android

[Stylianos Gakis]

Is there a way for the compose inset APIs to give you the height that the keyboard would've gotten if it was shown, but before it's ever shown in the first place?
Basically a way to know the IME size in advance in order to place things accordingly for when the IME actually does show and not get any size animations after the fact.

[Stylianos Gakis]

I had this interaction in mind, and I can't understand how else this'd be done besides getting the IME insets before the IME ever shows in the first place.
Notice how the view which allows one to add pictures and whatnot is already perfectly sized for the input field to not have to move vertically after the keyboard shows or disappears

screen-20231209-164004.mp4

[ephemient]

I feel like that won't be possible given that keyboards can resize themselves at will

[Stylianos Gakis]

Yeah, so I am really really curious, what are they doing here to get this working in the way it does?

[Stylianos Gakis]

screen-20231209-190841.mp4

screen-20231209-190841.mp4

[Stylianos Gakis]

Well just tested by resizing the keyboard in two ways, changing to one handed mode and by going to an emoji view, and it does seem like it actually tries to remember the last known IME size

[Stylianos Gakis]

What I wonder then is how they do it on first app launch, since the IME was never shown at that point

[ephemient]

perhaps they just hard-code an initial guess which matches the most common keyboard sizes

[sindrenm]

If you resize the keyboard in another app and then open this app again, does it then know the new size before opening it?

[Stylianos Gakis]

Hehe nice test scenario. It does in fact not update until it sees the new size itself.
This video is after I opened this view, went to another app, changed to a short one handed mode, then comes what you see in the video, where it jumps to the new size.
So yeah, they do some sort of guessing, and then they store in memory the last known IME size, that must be it.
Thanks for helping me in this investigating job 🕵️🔎

screen-20231209-194901.mp4

[sindrenm]

Yeah, then that seems likely. Don't know much about IMEs, but maybe there's a “recommended default size” or some guidelines that their initial guess is based on. Interesting case!

[ephemient]

not really afaik, but if you just assume most users are using Gboard then you're pretty close

[ephemient]

I wonder what happens with their UI if you use a floating keyboard, or a super slim one like https://minuum.com/

[Stylianos Gakis]

Not a super smooth experience with a floating keyboard

screen-20231209-201334.mp4

[sindrenm]

Yeah, although that behaviour makes sense, I guess.

[ephemient]

makes some sort of sense but I wouldn't want to emulate that behavior

[ephemient]

I could probably pull out my Surface Duo and get even weirder keyboard scenarios that it doesn't handle

[efemoney]

Also, late but, check out WindowInsets.imeSource & WindowInsets.imeTarget (latter is what youre looking for)

[Stylianos Gakis]

I can't find that, but I can fine imeAnimation(Source|Target).
But these https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/foundation/foundation-layout/src/androidMain/kotlin/androidx/compose/foundation/layout/WindowInsets.android.kt;l=415 imply that they only tell you what the IME size will settle to after the animation is over. Aka if the keyboard isn't showing yet, they'll both just be == 0 anyway. Only on the first frame of the keyboard showing we'll get the first value.
Can't test atm as I am afk, but that's what I understood from the docs here.

[efemoney]

Yeah thats it, sorry, forgot what it was called.

Tells you, for the opening/closing of the keyboard, its starting & ending position

[Stylianos Gakis]

Yes, but on app startup those still don't help you with the initial height guess right, you still need to use something else, which might just be guessing is what we assumed further up in this thread

[efemoney]

Hmm, I see, so you need the value for actual layout of your View? Not just for when the keyboard is open 👍🏾 Then it makes sense what you mentioned above

[Stylianos Gakis]

Yeah, as the video shows in the first reply in this thread.
Well, I don't really need it, I was just really curious is all

[raghunandan]

is this not similar to what's app does switching to emoji but the height seems to be same as keyboard. I also have a similar requirement. So the initial height is a guess then?. I wonder how it works on other phones as the keyboard might differ from phones to phones cause we can't assume its always g board. Some one might use samsung keyboard app or even custom keyboards. Did you hardcode in this case @Stylianos Gakis

[Stylianos Gakis]

I simply did not do any hardcoding in the end. Just listen to the insets as-is and let things re-layout by themselves. I didn't want to make any size assumptions and have jumpiness that way.

[raghunandan]

Ok.