Brief analysis: Android nested sliding mechanism (nestedscrolling)

After Google released the Android Lollipop version, Google has provided nestedscrolling features for the android sliding mechanism for a better user experience.

Where does the nestedscrolling feature go?

For example, you use the toolbar, the following scrollview, scroll up to hide toolbar, scroll down to show toolbar, here is logically a nestedscrolling--because you are scrolling through the view of the toolbar in the process of , and then nested scroll the inside of the ScrollView.

Before that, we knew that Android's distribution of touch events had its own set of mechanisms. There are basically three functions:

Dispatchtouchevent, Onintercepttouchevent and Ontouchevent.

This distribution mechanism allows mobile application security detection platform-love beta (ineice.com) to find a loophole, according to the love of the CTO introduction:

If the child view gets a chance to handle the touch event, the parent view has no chance to handle the touch event until the next finger is pressed again.

That is, when we slide the sub view, if the sub-view does not want to handle the sliding event, it can only discard the touch event, and not pass it to the parent view to handle.

But Google's new nestedscrolling mechanism is a good solution to this problem.

Let's see how to implement this nestedscrolling, first there are a few classes (interfaces) We need to focus on

Nestedscrollingchild

Nestedscrollingparent

Nestedscrollingchildhelper

Nestedscrollingparenthelper

The above four classes are available in the SUPPORT-V4 package, and the lollipop view default implements several methods.

Implementation of the interface is very simple, here I temporarily used the Nestedscrollingchild series method (because the parent is the coordinatorlayout provided by Support-design)

@Override

Publicvoid setnestedscrollingenabled (Boolean enabled) {

super.setnestedscrollingenabled (enabled);

mchildhelper.setnestedscrollingenabled (enabled);

}

@Override

Publicboolean isnestedscrollingenabled () {

Returnmchildhelper.isnestedscrollingenabled ();

}

@Override

Publicboolean startnestedscroll (int axes) {

Returnmchildhelper.startnestedscroll (axes);

}

@Override

Publicvoid Stopnestedscroll () {

Mchildhelper.stopnestedscroll ();

}

@Override

Publicboolean hasnestedscrollingparent () {

Returnmchildhelper.hasnestedscrollingparent ();

}

@Override

Publicboolean dispatchnestedscroll (int dxconsumed, int dyconsumed, int dxunconsumed,int dyunconsumed, int[] Offsetinwindow) {

Return Mchildhelper.dispatchnestedscroll (dxconsumed,dyconsumed, dxunconsumed, dyunconsumed, OffsetInWindow);

}

@Override

Publicboolean dispatchnestedprescroll (int dx, int dy, int[] consumed, Int[]offsetinwindow) {

Returnmchildhelper.dispatchnestedprescroll (dx, dy, consumed, offsetinwindow);

}

@Override

Publicboolean dispatchnestedfling (float Velocityx, float velocityy, Boolean consumed) {

Returnmchildhelper.dispatchnestedfling (Velocityx, velocityy, consumed);

}

@Override

Publicboolean dispatchnestedprefling (float Velocityx, float velocityy) {

Returnmchildhelper.dispatchnestedprefling (Velocityx, velocityy);

}

Yes, it's just as simple as that.

These interfaces are called by ourselves when we need them. What did Childhelper do? , take a look at the Startnestedscroll method

/**

*start a new nested scroll for this view.

*

*<p>this is a delegate method. Call it from your {@link Android.view.ViewView} subclass

*method/{@link Nestedscrollingchild} interface method with the same signature toimplement

*the Standard policy.</p>

*

* @param axes supported nested scroll axes.

* See {@linkNestedScrollingChild #startnestedscroll (int)}.

* @return True if a cooperating parent view was found and nested scrollingstarted successfully

*/

Publicboolean startnestedscroll (int axes) {

if (Hasnestedscrollingparent ()) {

Already in progress

return true;

}

if (isnestedscrollingenabled ()) {

Viewparent p = mview.getparent ();

View child = MView;

while (P! = null) {

if (Viewparentcompat.onstartnestedscroll (p, child, MView, axes)) {

Mnestedscrollingparent = p;

Viewparentcompat.onnestedscrollaccepted (P,child, MView, axes);

return true;

}

if (P instanceof View) {

Child = (View) p;

}

p = p.getparent ();

}

}

return false;

}

You can see here are some ways to help you achieve some interaction with nestedscrollingparent.

Viewparentcompat is a compatible class with the parent view interaction, it will determine the API version, if the lollipop above, is to use the view of the method, otherwise determine whether to implement the Nestedscrollingparent interface, The method to invoke the interface.

So how do we use this set of mechanisms? For example, a child view I need to notify the parent view that I have a nested touch event that we need to work with. So for one that contains only scroll interactions, it's the entire workflow:

First, Startnestedscroll

First, the child view needs to open the entire process (the main internal is to find the appropriate nestedscroll to accept the parent), notify the Father view, I want to cooperate with you to deal with TouchEvent

Second, Dispatchnestedprescroll

In the onintercepttouchevent or ontouch of the child view (typically in the Montionevent.action_move event), call this method to notify the parent view of the distance that the slider is sliding. The third and fourth parameter of the method returns the scroll length consumed by the parent view and the form offset of the child view. If the scroll is not consumed, then the child view takes care of some remaining distance, because the form moves, and if you record the last position of the finger, you need to calculate the offset according to the fourth parameter Offsetinwindow to ensure that the next touch event is calculated correctly.

If the parent view accepts its scrolling parameters and makes a partial consumption, the function returns True, otherwise false.

This function is usually called before the child view is processed scroll.

Third, Dispatchnestedscroll

Reports scrolling to the parent view, including the portion of the child view consumption and the portion of the child view that is not consumed.

If the parent view accepts its scrolling parameters and makes a partial consumption, the function returns True, otherwise false.

This function is typically called after a child view has processed scroll.

Iv. Stopnestedscroll

End the entire process.

The entire correspondence process is like this

Child View Parent View

Startnestedscroll Onstartnestedscroll, onnestedscrollaccepted

Dispatchnestedprescroll Onnestedprescroll

Dispatchnestedscroll Onnestedscroll

Stopnestedscroll Onstopnestedscroll

Typically a child view initiates the call, and the parent view accepts the callback.

The most we need to focus on is the consumed parameter in Dispatchnestedprescroll.

Publicboolean dispatchnestedprescroll (int dx, int dy, int[] consumed, int[]offsetinwindow);

It is an array of type int, the length is 2, the first element is the scrolling distance of the x direction consumed by the parent view, the second element is the scrolling distance in the y direction of the parent view consumption, and if the two values are not 0, the child view needs to make some corrections to the amount of scrolling. Because of this parameter, we have a clearer idea of how to handle a rolling event, and it will not be confused by a bunch of scrolling parameters as before.

Brief analysis: Android nested sliding mechanism (nestedscrolling)