A modern programming language that makes developers happier.

kotlinlang

:question: Common problem around keeping *focused* things *visible* here; I'm curious how people are solving it.
*Scenario:*
• Screen with a text field (inside a scrollable area with IME insets), soft keyboard is *not* yet showing
• User taps on text field - so it gets focused and the soft keyboard shows.
• Insets shrink down, but the text field gets obscured behind the keyboard :face_palm:. The scrollable viewport _has_ been shrunk, but its scroll state does not adjust to maintain view of the focused element.
• How do you make sure the field stays scrolled-to-visible?
Solutions in :thread: :point_right:

What I've tried:  Apply a `RelocationRequester` modifier to the `TextField` and use it in `onFocusChanged`, to bring the text field back into view.  The problem is, this fires too early, before the keyboard is fully shown, and so the problem remains.
The next logical branches from this path would be to _also_ monitor the keyboard state (Complex) or add a delay to the relocation request (Yuck :face_vomiting:), but then this whole mechanism starts to feel unexpectedly complex to apply to every field, for what is a very common use-case?

<@UJBKXD0HH> Is <https://kotlinlang.slack.com/archives/CJLTWPH7S/p1627913606279300?thread_ts=1627897521.232900&amp;cid=CJLTWPH7S|this earlier reply> of yours relevant here?  Does this mean there are upcoming API changes that will make it simpler to keep focused elements visible in the face of inset/keyboard changes?

If you want a `TextField` to be visible when the keyboard appears, `adjustResize` in your `AndroidManifest.xml` is your friend.

I've found an annoyance with a top surface and a bottom `LazyColumn`, however, where the screen is resized but the `TextField` isn't above the keyboard. I should write about it later.

This isn't a general adjustResize issue - the drawable area is shrinking; but the scrollable column is not also scrolling to maintain visibility of the focused element when that shrinking occurs.

did you end up figuring out how to fix this?

Is it this issue <https://issuetracker.google.com/u/1/issues/192043120> ? If so, please star.

There's a solution at the bottom.

It looks like this issue, yes.  Thanks I've voted for it.
I ended up applying an unpleasant workaround; observing for keyboard state change and then calling a `RelocationRequester` on it after a brief (~400ms) delay :nauseated_face:   Will see if the solution in thread offers an improvement.

But I completely agree this should be higher than a P4, this is not some obscure edge case; it's absolutely on the 'happy path' for using text input on device... basic stuff!

...after checking the workaround in thread, it's the same thing I'm already doing. Commented; this is a really rough issue :disappointed:

It's the eighth most starred issue there. Needs a few more. Or a googler or jetbrainers to take up its cause.

Yeah; I am about to spruik this in the main channel; I know there's always that bias in thinking the issues affecting you are more severe... but seriously; this is _basic_ functionality.  I spent a long time to arrive at my hack solution, not because I couldn't invent it, but because I couldn't _believe_ I had to invent it - I *must* be doing something wrong... surely Compose can't be broken on something this simple??  :point_left:  Me before reading replies in this thread.