When an AppBarLayout is loaded, it will load the attribute and set up a non-forcing pending action. However when it's measured, the current scroll state will be saved and restored, which will override the non-forcing pending action. This behavior is incorrect - if there's a pending action, we shouldn't restore the scrolling state because it's meant to be changed.
Resolves https://github.com/material-components/material-components-android/issues/2629
PiperOrigin-RevId: 440960254
When scroll range changes, the current scroll position may not make sense anymore. Therefore we need to save the scroll state and restore it after the scroll range is invalidated. This change reuses and refactors the existing saving instance state logic to support this need. Also adds a flag to denote "fully expanded" state to avoid improper scroll position calculation when views are still being initialized.
PiperOrigin-RevId: 421348135
Unlike other child views of AppBarLayout, CollapsingToolbarLayout will shift its top boundary to consume the window insets as well. Therefore we need to shift the top boundary back when calculating snapping positions to have a consistent logic with other views.
This CL also simplifies the calculation so the origin of the y-coordinate used in the calculation will always be the top of the AppBarLayout.
PiperOrigin-RevId: 413750156
In the snap logic we didn't take the AppBarLayout's top padding into account, therefore in certain cases the scrolling will be incorrectly snapped to the top of CollapsingToolbarLayout instead of the bottom of it, which cause the title not collapsed.
PiperOrigin-RevId: 400749401
An app bar remembers the visible percentage of its first visible child during recreation to restore its scroll position. However, if an app bar is "fully" scrolled (scrolled to its maximum range), gets recreated, and changes its size after recreation, it can become not fully scrolled even if it keeps the same visible percentage of its first visible child, due to the difference in its own size. This can result in unexpected "gaps" in the layout due to inconsistency between AppBar layout's scroll position and the content view's.
Fixes this by remembering the "fully scrolled" state and restore it during recreation.
PiperOrigin-RevId: 398013525
Originally we always set the outline provider of app bars to BOUND, even if the outline provider is set to none explicitly in the XML file.
Checks if the outline provider is set to BACKGROUND before we override it, to prevent unwanted overriding from happening.
Resolves https://github.com/material-components/material-components-android/issues/2332
PiperOrigin-RevId: 391339943
Helpful for the case where the Top App Bar text/icons are still visible underneath a transparent status bar, when the Top App Bar is scrolled up.
PiperOrigin-RevId: 384985602
Currently AppBarLayout lacks the functionality which
CollapsingToolbarLayout does, to draw a drawable behind
the status bar. This CL adds that functionality.
Also added related functionality to Catalog
PiperOrigin-RevId: 242949840
When AppBarLayout is used with a CollapsingToolbarLayout
child, it currently does not handle WindowInsets
very well. This commit fixes that by properly handling
insets.
The primary issue is when an AppBarLayout is used
with a single Toolbar (very common use case), where
the Toolbar will currently be displayed behind the status bar.
Another issue is with HeaderScrollingViewBehavior.
To workaround CoordinatorLayout using its 'compatible measuring'
for insets, the behavior manually sets the scrolling view to fit
system windows. This has other issues though because
that view will get padded in. Fixed by manually adding the insets
back into the measured dimensions.
Also updated the catalog layouts to make use of
android:fitsSystemWindows=true
Resolves https://github.com/material-components/material-components-android/pull/299
PiperOrigin-RevId: 238396626
- Add liftOnScrollTargetViewId attribute to allow client to specify the scrolling view that should be listened to for updating AppBarLayout lifted state.
- Use View#canScrollVertically instead of View#getScrollY to determine lifted state.
PiperOrigin-RevId: 213614055
