use case: i have `Column` content in the foregroun...

# compose

[Sam]

use case: i have Column content in the foreground that should respect WindowInsets but have a background image that should bleed completely full screen

[Chris Sinco [G]]

Assuming this is set in your Activity:

WindowCompat.setDecorFitsSystemWindows(window, false)

you will have to handle all the insets. Components like Scaffold in Material3 have insets within it’s content scope, but you still have to pass that as a Modifier or PaddingValue to the child Composable you want to inset.

[Sam]

yes i have setDecorFitsSystemWindows and content in the container view is using .navigationBarsPadding() but if there is a child view within the Box, how do i “break free” from the padding and go edge to edge? apply negative padding?

[Sam]

in SwiftUI it’s really easy:

ZStack { // equiv to Box
  Image().ignoresSafeArea() // full screen edge to edge
  VStack { // equiv to Column
    // content respecting insets
  }
}

[Chris Sinco [G]]

Not sure we have a convenience method for that - @Alex Vanyo may know more. Otherwise, negative offset is doable, or you apply navigationBarsPadding to a sibling of the Image instead of the Box and/or its parents.

[Sam]

does negative padding work in jetpack compose?

[Chris Sinco [G]]

No it will throw a runtime error

[Sam]

i dont see how offset will help in the case of wanting an image edge to edge — unless i specify the height explicitly

[Chris Sinco [G]]

Compose doesn’t clip by default, like in Box, so using the offset modifier will offset the content against the insets/padding. You might just have to scale up the Image a bit to compensate

[Sam]

offset -y would only place the content inside the bleed area on the top, it would not compensate the height so it could also bleed into bottom bar

[Alex Vanyo]

There isn’t a convenience method or modifier like that. There are some tricks that could work, but you’re sort of going against the grain of the layout system by forcing children layouts to be larger than their parents.

I’d recommend applying the inset padding (like navigationBarsPadding()) further down the hierarchy like Chris mentioned, so the Image goes edge-to-edge naturally just by filling the max space in the parent

[Sam]

yep you might be right in most cases, but there are other cases where the component is further down and i need to “break out” of parent system bar padding. i think it might be achievable like so:

Box(
  modifier.background(
    Image(modifier.height(fullScreenHeight)
  )
) {
  // regular window inset content goes here
}

[Alex Vanyo]

Could you expand on some of those cases? Window insets padding ideally shouldn’t be too different from other types of padding, and having components “break out” of its parent and the padding in general sounds like a more complex approach than applying the padding further down into the children.

[Sam]

nested navigation with a screen that expands to full screen with a shared component transition

[Sam]

it will start from within a window inset component and will want to retain the insets for all content except its background content

you can’t always rely on being able to get your desired full screen content outside of the parent which has the padding applied

[Sam]

this is a pattern we use everywhere on SwiftUI, it’s super common in iOS and built-in because of how frequently it is used that way

[Sam]

this is everywhere we intentionally break out in our iOS codebase 😅

[Sam]

i presume if you are an android only developer, then:
• you only recently started catering towards edge-to-edge designs
• compose wasn’t built with these accommodations as first class (i.e. accompanist addon until recently)
then thinking of building this way wouldn’t be second nature like it is for iOS devs

[Chris Sinco [G]]

Well edge-to-edge has been a thing for sometime in Android, even before Compose, it just hasn’t had the broadest adoption like iOS for many reasons. I can’t authoritatively speak to the low-level layout system technical details in Compose, so something @Adam Powell or @romainguy may be able to provide insight on on why this kind of modifier may not be straightforward.

[Alex Vanyo]

Thank you for sharing by the way, that approach is interesting to think about

[Sam]

no prob, thanks for your consideration and advice