Is there a succinct list of settings I'm supposed ...
# compose-android
t
Is there a succinct list of settings I'm supposed to configure to "Do The Right Thing(tm)" for keyboards and such for modern/new Android Compose app? I believe, that I'm supposed to do the following: • in my Manifest, place
android:windowSoftInputMode="adjustResize"
in the application body • place
WindowCompat.setDecorFitsSystemWindows(_window_, *false*)
in my MainActivity onCreate override Are these correct? Are there other things I'm supposed to employ? Something about ime padding at the root composable? (I am not using a Scaffold). If there's a document somewhere that describes this in one place, I haven't found it yet. :(
s
You can also just call
ComponentActivity.enableEdgeToEdge()
and let that call the right thing, and remove your WindowCompat function call. After this, you should be getting the IME insets as WindowInsets.ime in your compose code and you can do whatever you want with them. Is there something you're doing that just doesn't work for you?
t
Do I need to do the thing in the Manifest still? (I'm still iterating on my current "this isn't working bit). Thanks for the bit on enableEdgeToEdge. I'll switch to that. Can you share an example of where you use the WindowInsets.ime to affect the change you want?
My current issue is that I'm trying to coordinate some layout in a BasicAlertDialog with my main app screen. I have the two shown settings turned on (haven't switched to your recommendation yet). I'm using this fragment:
Copy code
.onGloballyPositioned { layoutCoordinates ->
    nameTop = with(density) { layoutCoordinates.positionInRoot().y.logged("ROOT")
       layoutCoordinates.positionInWindow().y.logged("WINDOW")
       layoutCoordinates.positionInRoot().y.toDp() }
})
to capture the top of one of my main screen composables. I have determined that 0 is at the TOP of the whole screen (i.e. under the system bar). But 0, in my BasicAlertDialog appears to be at the bottom of the system bar. I've even passed the following to my BasicAlertDialog:
Copy code
properties = DialogProperties(usePlatformDefaultWidth = false, decorFitsSystemWindows = false)
s
Yep, keep the manifest part. Not sure I really follow the global layout coordinates stuff you're doing 😅 If you just add window insets modifier to one of your composables and give it the IME insets, and you open the keyboard you should hopefully be able to see it working well. Not sure how all this plays out along with onGloballyPositioned or if it affects it at all in the first place tbh
t
My issue seems to be that main window is running edge to edge, but the BasicAlertDialog is NOT. I'm not sure how I encourage it to be. I thought my custom DialogProperties would do that
a
https://developer.android.com/jetpack/compose/layouts/insets#insets-setup is the main setup - but if you’re also placing content in `Dialog`s, stuff gets trickier, and the built-in Compose `Dialog`s have some known issues especially around edge-to-edge. Fundamentally, the issue is that each
Dialog
is placed into a new platform
Window
, which has a bunch of fun consequences: • each new window comes a new set of window flags to configure (fits system windows, window soft input mode, etc.) • going edge-to-edge is window-specific - you could go edge-to-edge in an Activity with its
Window
, but not in a dialog’s window, or vice versa (or neither, or both) • window insets are window-specific - the value of window insets can differ between windows depending on their window flags I’ve been experimenting with an alternate dialog setup in https://gist.github.com/alexvanyo/594abce742ecd9f973cb1162ec49df12 which might be interesting to take a look at. The rough goal is: Provide a type of dialog that always goes edge-to-edge, and gives the contained content the flexibility and responsibility to fill that edge-to-edge space
t
Wow. Thanks for that writeup @Alex Vanyo. I appreciate the detail As a workaround for the time being, until Dialog becomes legit edge2edge aware, is there anyway I can query the top status/system bar height? I think I can use WindowInsets.systemBars.getTop(LocalDensity.current)?
a
That should work if you call
WindowInsets.systemBars
from inside the dialog, and you are using the
decorFitsSystemWindows = false
dialog property
This is also why bottom sheets are so much fun 😄
s
You have an interesting definition of fun Alex 😂
😄 1
a
The gist above also has a version of
ModalBottomSheet
based on the edge-to-edge dialog I’m experimenting with, which seems to help with some of the issues around insets too
t
@Alex Vanyo, I found the opposite to be true of the WindowInsets.systemBars. Inside the dialog, the top is reported as 0. Outside, it is reported as 78. I am running in a Scaffold in the main window.
a
Hmm, interesting. Is the
WindowInsets.systemBars
that is outside the dialog being called directly outside the dialog?
t
Copy code
if (isEditing) {
   ....
    val topBarHeight = with(LocalDensity.current) {
       WindowInsets.systemBars.getTop(LocalDensity.current).toDp().logged("SYSTEMBARPADDING IN WINDOW")
    }
    val focusRequester = remember { FocusRequester() }
    BasicAlertDialog(
       ....
👍 1
I have a more naive basic question. Why Dialogs at all? Can't one just simulate a dialog in Compoose by have a root composable that can be triggered to add an "overlay" composable on top of everything with a skrim and achieve a simular Ux effect? What does one gain by using the underlying platform Dialog services. I'm just using it in my case to get a full screen scrim with a target modal interaction.
s
For one, if you got your own dialog, then if you actually try to show a real dialog it will show on top of yours 😅 Other than that, I suppose if you do placement well, add the darkened background somehow and intercept back press to dismiss it, along with pressing outside, I suppose you got yourself something to work with 🤷‍♂️