Collapse browser toolbar on scrolling the card list #18037
Conversation
Here I opted for an extra `LinearLayout` inside of the `AppBarLayout`
for a minimal and safe-contained change. Other options are available,
see the comment in the code.
I also moved the linear progress indicator to the bottom of the
`CoordinatorLayout` for the following reasons:
* As a child of `CoordinatorLayout`, which is a “super-powered
`FrameLayout`”, it doesn't shift other elements when it becomes
visible and disappears;
* It stays on the bottom and doesn't move with the scrolling cards;
* Before, visually it was positioned just inside of the grid of the
table, which looked a bit weird, and it has rounded corners and
thus appeared shorter than the table;
* It may be harder to move it along with the `RecyclerView`.
There was a problem hiding this comment.
LGTM, thanks!
Requesting @david-allison opinion as you worked on this extensively.
|
|
||
| <!-- Note: AppBarLayout itself is a vertical LinearLayout, so strictly speaking |
There was a problem hiding this comment.
I don't think this comment is needed(maybe in the commit message).
We shouldn't look into optimizing by tying to specific implementations. We already had several crashes due to using specific LayoutParams(although a more general parent was available) and then changing the layout structure.
There was a problem hiding this comment.
I left this information as a comment as having a vertical LinearLayout as a child of AppBarLayout is weird, and whoever reads the code later on will eventually wonder why it is here. While this could be in a commit message, it takes time and effort to go through the blame to find anything useful, and more often than not the explanation just isn't there.
(As per the tutorial, you would be setting app:layout_scrollFlags on the individual children of AppBarLayout.)
lukstbit
added
Needs Second Approval
| here it is not necessary to have another LinearLayout as a child. | ||
| Instead we could be setting app:layout_scrollFlags on the individual children. | ||
| However, the <include> tag can only override a very limited set of arguments, | ||
| so the alternatives here would be not using the <include> tag, |
There was a problem hiding this comment.
my two cents: the alternative of not using <include> is super reasonable. Most of the new screens don't use it, if that matters.
There was a problem hiding this comment.
A quick search says there are 15 files saying <include layout="@layout/toolbar" in the XML
There was a problem hiding this comment.
Most of the new screens don't use it
A quick search says there are 15 files saying <include layout="@layout/toolbar" in the XML
Yes, it is still used in some places, but most of the "new" ones use MaterialToolbar instead of including the toolbar.xml layout, which has some extra sutff that normally is not used.
There was a problem hiding this comment.
Ah I see. I just went this way for the self-contained minimal change, otherwise I personally have no opinion on which way is the best one. 🤷♀️
Purpose / Description
Collapse browser toolbar on scrolling the card list. The toolbar takes space and may take even more space when browser chips are introduced (see #17355, #12554).
Screen_recording_20250301_155316.mp4
Approach
Pretty straightforward, use
AppBarLayout. I used my old commit which had some issues, namely:I suspected that these issues would be resolved with moving to
RecyclerView, and it seems that they have.See also the commit message.
How Has This Been Tested?
Briefly tested on my device API 34 and emulator API 24. Requires more on-hand testing to ensure the above issues are truly gone.
Checklist