I need to keep some buttons onscreen underneath a ...

# compose

[colintheshots]

I need to keep some buttons onscreen underneath a textfield while my IME keyboard is visible. I know all the tricks with Accompanist Insets (and the new insets in Compose 1.2.0-alpha), but none of them seem to be working for me. When I use Modifier.imePadding or Modifier.navigationBarsWithImePadding , the UI elements are scrolled completely offscreen and I’m left with a blank space where they were. I was able to workaround the issue by giving my textfield a weight of 1f and this keeps the buttons onscreen above the keyboard and below the textfield, but I can’t use this on screens with more than one textfield. Are there any alternatives to Modifier.weight(1f) that will work better here?

[Bradleycorn]

First, are you aware of the existing defects around the ime keyboard and scrolling the focused textfield into view? See this issue in the tracker:
https://issuetracker.google.com/issues/192043120

Second, maybe you could use a bringIntoViewRequester to bring the buttons into view when the text field is focused? maybe something like this:

val bringIntoViewRequester = bringIntoViewRequester()

TextField(..., modifier = Modifier.onFocusEvent {
    if (it.isFocused || it.hasFocus) {
        bringIntoViewRequester.bringIntoView()
    }
})

...

Button(modifier = Modifier.bringIntoViewRequester(bringIntoViewRequester), ...)

[colintheshots]

I did mess with making the parent view scrollable, but I thought that was the cause of a lot of problems in that thread. I think a big part of the problem is the focused view is the textfield, not the buttons. Using weight(1f) on the textfield successfully causes the view elements to scale to fit into the smaller area left by the keyboard. Adding Modifier.requireSizeIn(minHeight=?) to the button container seems to keep the buttons onscreen with the weight on the textfield.

[colintheshots]

Also, I didn’t mention that I’m working with an AndroidView here for a legacy Markdown editor view, so the options involving focusRequesters are remarkably convoluted.

[Zach Klippenstein (he/him) [MOD]]

I tried a simple version of this idea and it Just Worked:

@Composable
fun Repro(modifier: Modifier = Modifier) {
    var text by remember { mutableStateOf("") }

    Column(modifier.windowInsetsPadding(WindowInsets.ime)) {
        BasicTextField(
            text,
            onValueChange = { text = it },
            modifier = Modifier
                .fillMaxWidth()
                .weight(1f)
        )
        Divider()
        BasicText("toolbar goes here", Modifier.align(Alignment.CenterHorizontally))
    }
}

I was using soft input mode ADJUST_RESIZE and tried with decorFitsSystemWindows both true and false, worked in both cases.

[Zach Klippenstein (he/him) [MOD]]

So i’m guessing there’s something else in your UI that is getting in the way. Could you share some code?

[colintheshots]

Weight(1f) was the only solution that worked for me. This is only a problem because there are screens with multiple textfields which can’t use weight because they’re buried in different hierarchy. If I set a weight, the second textfield doesn’t appear onscreen and the first one takes up the whole screen.

At the moment, I’m running with a workaround where I detect the keyboard being open and conditionally set maxLines to a lower number. This isn’t an elegant solution because it doesn’t properly adjust to the size of the device.

[Zach Klippenstein (he/him) [MOD]]

So you want each text field to take up the size of a whole screen, no matter where it is in the hierarchy?

[colintheshots]

That’s not what I want. I was looking for a solution to make the buttons appear onscreen with the textfield after the keyboard opened (without overlapping). The only reason I used weight(1f) was to ensure the textfield shrunk when the keyboard opened and that the buttons still fit regardless of the screen size of the device. This only works if there’s only one textfield onscreen and even then might not match the UX design. My alternative solution: adjusting the maxLines based on the keyboard state-- only works here if the device size is somewhat similar to the device being used for testing.

[Zach Klippenstein (he/him) [MOD]]

Are your text fields in a scrollable?

[colintheshots]

No. In fact, that would be undesirable to have unnecessary nested scrolling.

[Zach Klippenstein (he/him) [MOD]]

I think the part I’m missing is how your UI generally responds to the height change if you have multiple text fields, they’re a fixed size, and your screen isn’t vertically-scrollable.

[colintheshots]

The fields do not need the whole space of the screen and they’re not fixed size. I’d want them to limit the height when the keyboard opens.

[colintheshots]

What I’d want is the layout manager to use the remaining space on the screen to determine how tall the textfields can max out at.

[Zach Klippenstein (he/him) [MOD]]

Does this work?

Column {
  Column(Modifier.weight(1f)) {
    TextField(…)
    // etc.
  }
  Toolbar()
}