Status Update
Comments
hu...@google.com <hu...@google.com>
js...@google.com <js...@google.com>
js...@google.com <js...@google.com>
js...@google.com <js...@google.com>
an...@google.com <an...@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.
an...@google.com <an...@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.
Description
When @Parcelize support was added for sealed classes the final implementation also included support for sealed interfaces , however Lint still gives the following warning for deriving classes:
Sample snippet:
This warning was fixed for the sealed class case in a previous issue , but sealed interfaces still report the warning, requiring the annotation on each child to remove the warning despite the code running successfully with just the parent annotation.
Studio Build: #AI-242.23339.11.2421.12483815
Version of Gradle Plugin: 8.3.1
Version of Gradle: 8.11
OS: MacOS 15.2