Is it expected that

WindowInsets.isImeVisible

returns false when the keyboard is showing if the softInputMode is set to pan?

Yes, I would expect that it might return false on some API versions, since

adjustPan

can cause changes that the app isn’t fully aware of.

adjustResize

gives the most consistent results across API versions, as it gives the most information to the app about how the insets are changing

Isn't

adjustResize

deprecated though? Does it make sense to only use it until the API version it was deprecated in, and then switch to

adjustPan

?

Yes that is true, and that also lines up with https://issuetracker.google.com/issues/176400965 where API 30 is the version where the insets should be available with

adjustPan

. For simplicity I usually just specify

adjustResize

only in the manifest, but you should be able to apply

adjustResize

for API 29 and below, and

adjustPan

for API 30 and above. I’d actually be very interested to know if that works if you try it out!

I'm trying out a few different options. I'll add that to the matrix and report back 😁

For the first case of

adjustResize

, are you changing the size of the scrollable container itself based on the IME insets?

Not in this particular case. I'll try to get a screen capture of what I'm doing, together with some code. We're using

WindowInsets.isImeVisible

to drive treatment of a

BasicTextField

decorationBox. When the IME is visible we draw a border around the area that the next character will display.

If you’re handling insets directly with

WindowCompat.setDecorFitsSystemWindows(window, false)

, then you’ll want to ensure you are applying insets to your components to avoid overlapping. But it sounds like you might want to have logic based on whether the text field is focused? If you’re using a hardware keyboard, you might want to have the border visible as well?

We're in middle of converting a large codebase from View to Compose and we didn't really look at that yet. Our theme sets

android:fitsSystemWindows

to

false

and we're using the

Scaffold

composable at the top level of all of our screens (single activity)

Nice! My guess is that the

fitsSystemWindows

is providing the inset handling, but since the app is getting notified more than with

adjustPan

,

WindowInsets.isImeVisible

is still giving the correct value. If you want the nice synchronized IME animations, or to go edge-to-edge with more fine-tuned behavior, then you’ll probably want to turn

fitSystemWindows

back to

false

, and handle the insets directly at a per screen level (using

imePadding

and other modifiers) But glad you found a solution that works for you as you are converting.

Well it works for this particular use case. The rest of the app is not taking it so well 😅 It's a good starting point though, thanks!

Can I go back to the question of

But it sounds like you might want to have logic based on whether the text field is focused? If you’re using a hardware keyboard, you might want to have the border visible as well?

If you’re just using

isImeVisible

for that behavior

I'm just an engineer I don't have a say in these things 😬 It's a good point though, and I'm going to look into providing a better UX in that scenario. However we do have other places in the app that uses the equivalent of

isImeVisible

so I'd rather bite the bullet now and fix it before it becomes a problem

I would say you do, or at least you can ask if showing the border is because the user is inputting text, or because the software keyboard is open. The software keyboard is the most common way to do so, but not the only way. It’s also possible for the software keyboard to be open (on the device), but not overlap with your app at all in multi-window mode, in which case

isImeVisible

will likely be false. But the user could still be inputting text.

I'm just an engineer I don't have a say in these things 😬

That was just my lame attempt at humor. I'm more concerned with the latter point that I raised.

As for the whack-a-mole with inset behavior,

adjustResize

for API 29 and below with

WindowCompat.setDecorFitsSystemWindows(window, false)

will give your app the most information in the long term, although then you will need to be sure to avoid overlapping issues and handle insets directly. I wouldn’t expect

adjustPan

to work reliably on API 29 and below as per https://issuetracker.google.com/issues/176400965

Isn’t

adjustResize

deprecated though

Is that true? I’ve always see this as being the de-facto way to get the best kind of backwards compatibility when using that +

WindowCompat.setDecorFitsSystemWindows(window, false)

. Is there any case where one would not want to use that? If thy were targeting minSdk = 30+ for example? I wonder if there’s any material in the docs regarding picking the right choice for you, among adjustResize and its alternatives

It is deprecated on API 30 and above, but specifying it anyway in the manifest to get that behavior for API 29 and below along with

WindowCompat.setDecorFitsSystemWindows(window, false)

is the simplest and most consistent way to get good behavior. (Once your minSdk is API 30, you could probably switch to

adjustNothing

but I haven’t tested that in detail. And setting it dynamically instead of in the manifest in the meantime can be troublesome and quirky)

Off the bat

adjustNothing

on API 30+ doesn't scroll to the focused TextField

I think that would be because you aren’t resizing the scrolling views with

imePadding()

or similar? To go edge-to-edge, get good IME inset animations, and the most consistent

isImeVisible

value, and want the most consistent behavior across API versions, the setup to go with is: •

adjustResize

in manifest •

WindowCompat.setDecorFitsSystemWindows(window, false)

in

Activity.onCreate

Once you’re handling insets yourself completely, it is up to you to handle resizing scrolling views so that elements remain visible (Compose

1.4.0

has improvements there for

LazyColumn

in particular) In some sense, the most reliable answers to

isImeVisible

are available only when you are going edge-to-edge and the app is handling all insets, instead of the platform.

I am using

imePadding

in this case, together with the setup you specified.

I experienced similar things like in this video with the exact same setup. Im interested in how to solve this precisely? And it can happen too, that the textfield is not on the bottom of the screen

Which Compose version are you using? And which type of scrolling container?

I'm using Chris Banes' alpha bom, so these versions - https://github.com/chrisbanes/compose-bom/blob/v2023.02.00-beta03/bom/build.gradle.kts The container is a

Column

with

verticalScroll

that lives in the

content

of a

Scaffold

Thanks for checking with the latest alpha bom, one more question: to which component are you applying the

Modifier.imePadding

?

To the

TextField

(those boxes are all one `BasicTextField`; we're using a decorationBox to achieve that look)

Could you see what happens when adding it to the

Column

instead?

That works!

Woohoo, nice! I’d also recommend upgrading to

1.10.0-rc01

of

androidx.core

for getting better IME animations on API 29 and below as well

So

LazyColumn

needs

imePadding

as well?

Right, exactly.

OK cool. Thanks so much for the help. And this solution is great because I just have to make one change in a centralized component for all of my screens 😁

You are welcome, thanks for working through it!

Would you recommend using

adjustNothing

for API 30+ or stick with

adjustResize

?

I’d stick with

adjustResize

in the manifest for all API versions