Sometimes I think there’s an overlap between the `...
# compose-android
g
Sometimes I think there’s an overlap between the
WindowInset
APIs and the
contentPadding
pattern used in the
Scaffold
and
LazyColumn
APIs. I have to implement a translucent bottom navigation bar, and I think the default approach would be to pass the scaffold’s content padding down to any screen composable with scrollable content. But I think it would be way easier to contribute to the WindowInsets instead of consuming from them (I don’t think I can consume a negative inset value 😄). Alternatively I can have a separate
CompisitionLocal
similar to insets’ to pass down the nav bar size, or any other app-wide content paddings. What would be the preferred approach?
k
We had a similar feeling in our project. We ended up using a
ModifierLocal
, basically copying how WindowInsets modifiers worked but for
PaddingValues
, and adding helpers to consume
WindowInsets
t
Ah do you mean you want to add your status bar to the windowinsets for the content of the scaffold? But keep in mind that there are many different WindowInsets. And it depends what WindowInset should be used. But yes interesting idea. I also see problems with the modifier based consuming system. It makes it very difficult to adapt it to different needs.
g
@KoskiA yeah exactly. The problem then is that all my screens need to know about this new modifier, and it adds a new concept and dependency. While if I could just contribute to the insets, the screens would not have to change (assuming they handled insets properly)
@Timo Drick I would like to add the BottomNavBar's height to the bottom insets. Probably by increasing the navigationBars insets, instead of consuming them
t
Hmm interesting. I am also playing around with WindowInsets currently and try to find better ways handling them. I do have problems with them because the consumption is only managed by modifiers. This makes it difficult to change insets in custom layouts. And also for LazyLists it is not optimal. So i think also it would be better to have a little bit more flexible implementation. Would like to see some sample code of your approaches.
Also an other important thing for WindowInsets is that it depends on the position of the Composable what and how much of an insets should be used. So when the component is at the bottom only the bottom inset should be used as padding. And when the component does not reach the bottom only the overlapping part of the inset should be applied as padding. Also important if you do have animations in your layout. E.g. expanding a detail view.