Как работает математика AppBarLayout.ScrollingViewBehavior?

Question

Я бы посмотрел математический поток метода offsetChildAsNeeded в AppBarLayout.ScrollingViewBehavior при запуске изменений прокрутки.

Как частный метод и частный mOffsetDelta, как их программно контролировать?

(Это не ясно, каким образом метод использует offset тоже.)

private void offsetChildAsNeeded(CoordinatorLayout parent, View child, View dependency) { 
    final CoordinatorLayout.Behavior behavior = 
       ((CoordinatorLayout.LayoutParams) dependency.getLayoutParams()).getBehavior(); 
    if (behavior instanceof Behavior) { 
     // Offset the child, pinning it to the bottom the header-dependency, maintaining 
     // any vertical gap, and overlap 
     final Behavior ablBehavior = (Behavior) behavior; 
     final int offset = ablBehavior.getTopBottomOffsetForScrollingSibling(); 
     ViewCompat.offsetTopAndBottom(child, (dependency.getBottom() - child.getTop()) 
       + ablBehavior.mOffsetDelta 
       + getVerticalLayoutGap() 
       - getOverlapPixelsForOffset(dependency)); 
     } 
    } 

Примечание: приветствуются и могут быть приняты ответы и те, которые объясняют подробности о логике МАТЕМАТИКА о getTopBottomOffsetForScrollingSibling(), из (dependency.getBottom() - child.getTop()), и по содержанию mOffsetDelta

Answer 1

Вы можете перепроектировать этот код, но в конце концов это академическое, потому что мы простые смертные (т.е. не Google) программисты не могут получить доступ к в приведенных здесь. Я думаю, они полагают, что чем меньше их библиотеки, мы можем на самом деле использовать, тем меньше отчетов об ошибках мы будем записывать. Вздох.

Но вот краткое объяснение:

Прежде всего, что строки кода

final int offset = ablBehavior.getTopBottomOffsetForScrollingSibling(); 

, как представляется, рудиментарным остатком более ранней ревизии, поскольку offset фактически никогда не используется. Более новое выражение должно быть немного более точным в большем количестве случаев.

ViewCompat.offsetTopAndBottom() не является установленным (абсолютным) режимом работы, а является дополнительной (относительной) операцией. Итак, давайте предположим, что нормальная логика и считаем, что это поведение по существу ставит прокручиваемое представление непосредственно под маской панели приложения. Как правило, тогда нижняя часть панели приложений и верхняя часть прокрутки имеют одинаковое значение. Так как приложение бар макет (зависимость) изменился и вид скроллинга (ребенок) не имеет (пока), то

dependency.getBottom() - child.getTop() 

относительное количество, что вертикальные потребности офсетных ребенка быть скорректированы.

Если мое чтение кода верное, то mOffsetDelta в поведении макета панели приложения является отличным от нуля только в том случае, если макет панели приложений имеет смещенный интерполятор. Обычно панель приложения сама по себе не будет перемещаться в режиме параллакса, поэтому mOffsetDelta равен нулю практически для всех случаев, о которых мы заботимся. getVerticalLayoutGap и getOverlapPixelsForOffset дело с параметрами макета, как overlapTop.

Но получается, что вы можете сделать большую часть этого без этих крайних случаев в своем собственном поведении подклассу только делая это:

@Override 
    public boolean onDependentViewChanged(CoordinatorLayout parent, View child, 
              View dependency) { 
     // get the bottom of the app bar layout 
     int bottom = dependency.getBottom(); 

     // position the top of the scrolling view there 
     return setTopAndBottomOffset(bottom); 
    } 

я нахожу это немного легче работать с абсолютными смещениями, а не относительный смещения. Таким образом, внедрение поведения прокрутки в основном зависит от того, где находится зависимое представление и где на основе этого должно быть прокручиваемое представление.