Is there a way for the compose inset APIs to give ...
# compose-android
s
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.
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
e
I feel like that won't be possible given that keyboards can resize themselves at will
s
Yeah, so I am really really curious, what are they doing here to get this working in the way it does?
screen-20231209-190841.mp4
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
What I wonder then is how they do it on first app launch, since the IME was never shown at that point
e
perhaps they just hard-code an initial guess which matches the most common keyboard sizes
👍 1
👍🏾 1
s
If you resize the keyboard in another app and then open this app again, does it then know the new size before opening it?
think smart 2
s
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 🕵️🔎
s
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!
e
not really afaik, but if you just assume most users are using Gboard then you're pretty close
👍 1
I wonder what happens with their UI if you use a floating keyboard, or a super slim one like https://minuum.com/
s
Not a super smooth experience with a floating keyboard
s
Yeah, although that behaviour makes sense, I guess.
e
makes some sort of sense but I wouldn't want to emulate that behavior
same 1
I could probably pull out my Surface Duo and get even weirder keyboard scenarios that it doesn't handle
e
Also, late but, check out WindowInsets.imeSource & WindowInsets.imeTarget (latter is what youre looking for)
s
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.
e
Yeah thats it, sorry, forgot what it was called. Tells you, for the opening/closing of the keyboard, its starting & ending position
s
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
e
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
s
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