pubiqq
pubiqq
> Also, in some cases I believe the doubly nested scrolling works without flickering via the standard CoordinatorLayout APIs (and no liftOnScrollTargetViewId), so this PR could be disabling the current...
> The ScrollingViewBehavior itself should definitely be set on the sibling, but technically CoordinatorLayout supports sending up nested scrolling events up the hierarchy via the behavior's APIs. It is, but...
> I'm trying to understand whether this will cause a regression for some cases where `appbar_scrolling_view_behavior` is set and there is a nested scrolling view (e.g. FrameLayout with `appbar_scrolling_view_behavior` and...
Well, it seems the words of a random dude on stackoverflow mean more than the documentation, so I have no choice but to add the desired behavior 😂.
Yes, I got it so I added that behavior in https://github.com/material-components/material-components-android/pull/3926/commits/fba8a749768db775d43aee8398cf9e88430c605e. Just in case, I rebased the branch again (https://github.com/material-components/material-components-android/commit/b3f08c2f6e282e2406e2aa34a8144d4727a158e8) and updated the description.
Also see https://github.com/material-components/material-components-android/issues/2682#issuecomment-1442049217.
I'm pretty sure `.post()` was added just because it was the easiest way to add mandatory system gesture inset support. There are no objective reasons to keep this approach.
Bump