My app has a `Scaffold` with a `TopAppBar`, `BottomNavigation` and the content is a `Column` contain...

# compose

[Chris Miller]

My app has a Scaffold with a TopAppBar, BottomNavigation and the content is a Column containing a LazyColumn plus a TextField. When the onscreen keyboard is displayed, I want the TopAppBar and LazyColumn to stay where they are, the TextField to be pushed up to just above the keyboard, and the BottomNavigation to be hidden. I'm trying to achieve this with accompanist-insets-ui, but haven't been able to figure out how. navigationBarsWithImePadding() comes close, but results in extra whitespace between the TextField and the keyboard, due to the TextField not being located right at the bottom of the screen when there's no keyboard showing. Any ideas on how I can solve this?

[Chris Miller]

If anyone has Firefox installed, the behaviour of the search field at the bottom of the screen is very similar to what I'm after - except with a navigation bar showing below the search field only when there's no keyboard being displayed.

[Alex Vanyo]

Are you directly hiding the BottomNavigation when the IME is visible? Or are you relying on the IME to obscure it?

[Chris Miller]

Currently the latter, but I'm open to suggestions

[Alex Vanyo]

I’d be curious to know what that looks like with a hardware keyboard plugged in, since the IME can be extremely small in that case.

[Chris Miller]

Good point, I would guess the BottomNav would poke through... I'll look into making the BottomNav hidden when the IME is visible

[Alex Vanyo]

If you can sync the hiding of the bottom nav with the IME animation (so the height of the BottomNavigation is at 100% when the IME is closed, and 0% when the IME is open), the math might work out nicely for the TextField. In that case you might want to use just imePadding() as well for the TextField, if the navigation bars are dealt with separately

[Chris Miller]

OK thanks for the guidance, I'll see if I can figure out how to get that working

[Alex Vanyo]

For the value that drives choreographed animations, WindowInsets.Type.animationFraction should allow you to get the underlying animation progress

[Chris Miller]

Ah thanks, was wondering about that 😄

[Chris Miller]

One thing I'm not clear on, if I access LocalView.current.rootWindowInsets in a @Composable, how do I trigger recomposition when the insets change? Or will that happen for me?

[Alex Vanyo]

If you use LocalWindowInsets.current.ime (from accompanist) you shouldn’t have to worry about recomposition: all of those values will be observable to Compose automatically.

Or in other words, accompanist manages all of that for you, so you don’t have to use LocalView.current directly

[Chris Miller]

Thank you

[Chris Miller]

OK great, wrapping my bottom nav with if (!LocalWindowInsets.current.ime.isVisible) { } gives the end result I'm after, but as you insinuated, I'll need to take into account the animation fraction to prevent the UI "jumping". I'll have a crack at that later on, for now I'm off to have some dinner. Many thanks for the help!

[Stylianos Gakis]

Instead of just wrapping it in an if, you could animate it's height using this boolean as the indicator to when it should be max height vs no height. This would replace the jumpiness with a smooth size adjustment right?

[Chris Miller]

Yep something like that... I just wrapped it as a quick test things would work as expected

[Alex Vanyo]

Playing around with the interpolation there as well could be interesting. If you delayed changing the height of the navigation bar until something like 1/3 of the way through the animation (when opening the IME), you might be able to get the right end state and for most IMEs would probably obscure the shrinking