Status Update
Comments
sg...@google.com <sg...@google.com>
ap...@google.com <ap...@google.com> #2
Thanks for filing Alex. Not handling it at all would be a burden for developers to handle IMO, as it will be hard to guess what sides are handled by top/bottom app bars and what should be handled by the content manually. It is probably better than claiming all the padding automatically, I agree.
Would this make sense for scaffold to handle and consume the insets on the sides where we have top and bottom app bar, so that the rest is handled by the application? Still not ideal, but at least it is easier to wire up when nesting is involved.
na...@google.com <na...@google.com> #3
I think even in that case, the Scaffold
isn't directly handling the insets itself: the underlying component of the top bar or bottom bar is.
I think having a WindowInsets
parameter like the app bars would be enough. Then the contract could be something along the lines of "By default, the Scaffold
will inset the content to avoid the safeDrawing
, either because there is an app bar taking up at least that much space directly or because the Scaffold
will inset it."
And that could be an opt-out point as well: Passing an empty window insets would keep the old behavior, and let the insets pass down insets down the hierarchy unaltered.
de...@gmail.com <de...@gmail.com> #4
the underlying component of the top bar or bottom bar is.
Right, but in cases when top or bottom app bars handle this insets, we need to make sure that those insets are claimed successfully so that they are not reapplied again? It becomes a burden of the scaffold to make sure this is done properly, otherwise content
code will have to check and adjust based on the top/bottom app bar presence, which is not ideal.
And that could be an opt-out point as well: Passing an empty window insets would keep the old behavior
Same here, I would like to avoid the cases where you would need to check the top/bottom app bar presence in the content lambda. Not sure it is completely possible though, i will look into it more.
sg...@google.com <sg...@google.com> #5
I would also like to throw in the following:
With the changes, the entire screen is now reduced in size when the keyboard appears.
This was not the case before the change and I would like to deactivate it again. Is it possible to add this as an option?
ph...@gmail.com <ph...@gmail.com> #6
I would also appreciate the ability to turn off Scaffold
insets handling. We are handling insets on each screen, and this update made our app look odd (double insets all over the place). Fortunately, it's quite easy to fix it. But there is one thing that is not easily fixable.
We are using Scaffold
for the base structure on each screen, but most of our screens with LazyColumn are supposed to draw behind the navigation bar. But this is currently not easily possible with the Scaffold
. I know, I can remove the bottom inset from the bottom padding, but this is not a great solution.
Also, Scaffold's snackbarHost
slot (or SnackbarHost
) doesn't handle insets by default.
Description
Starting with
1.0.0-beta02
, trying to set the container color of a TopAppBar to be transparent no longer works.It looks like inhttps://android-review.googlesource.com/c/platform/frameworks/support/+/2189523 the behavior was changed so that there is always a
Surface
with the default color underneath the TopAppBar, whose color can't be configured to be transparent.Example usage:https://github.com/android/nowinandroid/blob/main/feature-foryou/src/main/java/com/google/samples/apps/nowinandroid/feature/foryou/ForYouScreen.kt#L143-L145