https://kotlinlang.org logo
#compose
Title
# compose
c

colintheshots

03/18/2022, 7:47 PM
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?
b

Bradleycorn

03/18/2022, 8:22 PM
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:
Copy code
val bringIntoViewRequester = bringIntoViewRequester()

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

...

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

colintheshots

03/18/2022, 8:39 PM
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.
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.
z

Zach Klippenstein (he/him) [MOD]

03/20/2022, 5:53 PM
I tried a simple version of this idea and it Just Worked:
Copy code
@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.
So i’m guessing there’s something else in your UI that is getting in the way. Could you share some code?
c

colintheshots

03/21/2022, 2:38 PM
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.
z

Zach Klippenstein (he/him) [MOD]

03/22/2022, 3:34 PM
So you want each text field to take up the size of a whole screen, no matter where it is in the hierarchy?
c

colintheshots

03/22/2022, 3:41 PM
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.
z

Zach Klippenstein (he/him) [MOD]

03/22/2022, 3:43 PM
Are your text fields in a scrollable?
c

colintheshots

03/22/2022, 3:44 PM
No. In fact, that would be undesirable to have unnecessary nested scrolling.
z

Zach Klippenstein (he/him) [MOD]

03/22/2022, 3:46 PM
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.
c

colintheshots

03/22/2022, 3:50 PM
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.
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.
z

Zach Klippenstein (he/him) [MOD]

03/22/2022, 4:40 PM
Does this work?
Copy code
Column {
  Column(Modifier.weight(1f)) {
    TextField(…)
    // etc.
  }
  Toolbar()
}
63 Views