1. Suppose the view is large enough to scroll down
2. After scrolling down, you hide a child view, which reduces the height to a value which means it would have been unscrollable in step 1
3. Now you can’t scroll back up
PiperOrigin-RevId: 623883120
getSupportActionBar.show/hide uses visibility to show/hide the toolbar which conflicted with the compress effect's use of Visibility to remove the toolbar when completely masked. This updates the compress effect to use alpha instead of visibility.
PiperOrigin-RevId: 619253990
This replaces the use of `ViewCompat#add/removeAccessibilityAction`
Both are valid strategies, but each call to `remove` or `add` triggers an accessibility event. Since this check is done in layout (originally to fix a11y scroll state) it's sending a high number of events that create noise for accessibility services.
To avoid this, we move this code to the delegate `onInitialize` and `performAction` methods. Instead of the view dynamically adding and removing actions to itself, the node is initialized with actions only when an a11y service sends a request with a new node (likely due to some UI change).
The flow here would look like:
1. UI is scrolled/page is loaded
2. TalkBack gets a scroll event/content change event
3. TalkBack requests new snapshot of the screen
4. ABL populates the node with the actions
For a simple scroll, this change reduces the events from ~40 to ~10.
We also add the Truth library for clearer assertions.
PiperOrigin-RevId: 605333170
Adding the a11y delegate and a11y actions was dependent on there being a CoordinatorLayout child that both inherits from certain scrolling classes (NestedScrollingChild, ListView, ScrollView) and has an AppBarLayout scrolling behavior. This was too restrictive and so we only check for a behavior.
Any scrolling child may add an a11y delegate or scroll action to the parent CoordinatorLayout.
PiperOrigin-RevId: 448335380
Ensure the CoL can scroll to the bottommost elements of the scrolling child, which may not be visible due to the app bar.
Also, set the node info properties to expose the CoL to auto-scrolling.
PiperOrigin-RevId: 447596411
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
