Detailed explanation of the implementation idea of traceless transition pull-down refresh control developed by Android

I believe you are no longer familiar with pull-down refresh. There are a wide range of pull-down refresh on the market. However, there are many slight defects in my opinion. Next, I will explain the existing defects, and then provide an idea to solve this defect. Don't talk too much nonsense! Look down!

1. Demonstration of common defects of some pull-down refresh controls in the market

Take the live bar app as an example:

Case 1:

When the sliding control is in the initial 0 position, the gesture slides down and then up. You can see that the sliding control cannot slide when sliding to the initial position.

reason:

The pull-down refresh control responds to the touch event, and a series of subsequent events are handled by it. When the sliding control reaches the top, the sliding events are consumed by the pull-down refresh control, and cannot be passed to its child control, that is, the sliding control, so the sliding control cannot slide.

Case 2:

When the sliding control slides to a non-0 position, when it is pulled back to the 0 position, you can see that the pull-down refresh header is not pulled out.

reason:

The sliding control responds to the touch event, and a series of subsequent events are handled by it. When the sliding control reaches the top, the sliding events are consumed by the sliding control. The parent control, the pull-down refresh control, cannot consume the sliding event, so the pull-down refresh head is not pulled out.

Most people may think it's irrelevant. Just lift your fingers and pull them down. But for me with obsessive-compulsive disorder, it's the most logical operation to provide a traceless transition, so let me explain the idea of implementation.

2. Explanation of implementation ideas

2.1. Introduction to event distribution mechanism (from Android development art exploration)

Relationship pseudocode for dispatchtouchevent, onintercepttouchevent, and ontouchevent methods

1. It can be seen from the code that if the current view intercepts an event, it will be handed over to its own ontouchevent for processing, otherwise it will be lost to the child view to continue the same process.

2. Event transmission sequence: activity - > window - > view. If the view is not processed, it will eventually be processed by the ontouchevent of the activity. It is an implementation of the responsibility chain mode.

3. Normally, an event sequence can only be intercepted and consumed by one view.

4. Once a view decides to intercept, this event sequence can only be processed by it, and its onintercepttouchevent will not be called again

5. Do not consume action_ Down, the event sequence will be processed by its parent element.

2.2. Implementation idea of general pull-down refresh

First, as a container, the drop-down refresh control needs to override the methods onintercepttouchevent and ontouchevent, and then judge the action in onintercepttouchevent_ Down event: judge according to the sliding distance of the child control. If it has not been slid, onintercepttouchevent returns true to indicate that it intercepts the event, and then perform the logic processing of displaying and hiding the header of pull-down refresh in ontouchevent; If the child control slides too far and does not intercept the event, onintercepttouchevent returns false, and the hidden logic processing of the subsequent drop-down refresh header display cannot be called.

2.3. Implementation idea of traceless transition pull-down refresh control

As can be seen from 2.2, in order to achieve seamless transition, the pull-down refresh control cannot intercept events. At this time, you may ask, since the event is given to the child control, how to implement the subsequent pull refresh header logic?

At this time, the event distribution method dispatchtouchevent, which is generally ignored, will be used. This method returns true by default in ViewGroup to distribute events. Even if the child control intercepts the event, the dispatchtouchevent of the parent layout will still be called, because the event is passed down, and this method must be called.

Therefore, we can judge the sliding distance of the child control during dispatchtouchevent, deal with the logic of the drop-down refresh header here, and set the action of the event to action before calling return super.dispatchtouchevent (event)_ Cancel so that child controls do not respond to sliding operations.

3. Code implementation

3.1. Determine requirements

Any control needs to be adapted, such as recyclerview, listview, viewpager, WebView and ordinary view that cannot slide

Cannot affect the original event logic of a child control

Exposure method provides manual call refresh function

You can set the disable pull-down refresh function

3.2. Code explanation

Required variables

During initialization, the head is created, the hidden value animation is performed, the head is added to the layout, and the head is hidden by setting paddingtop

Take out the content control after filling the layout

Here comes the play. Distribute the special handling of drop-down refresh:

1. Mcontentviewoffset is used to judge the sliding distance of the content page. The pull-down refresh operation is processed only when there is no offset value;

2. Set mcontentviewoffset= 0 is the first moment when the content page slides. It is forced to change the move event to down because the previous moves have been intercepted. If the content page is not given a down to reset the sliding starting point, there will be a pit father effect of sliding for a long distance in an instant.

Logic for handling events: get the drop-down offset, and then dynamically set the paddingtop value of the header to display and hide; When the finger is raised, it determines whether to refresh the display or directly hide the head according to the state

You may ask, how do you know this mcontentviewoffset? The next step is the processing method. I will set the monitoring of their sliding distance for different sliding controls. There are various methods. I can judge the type of view by handletargetoffset and adopt different strategies; Then you might think what if I want to monitor that control? This is simple. You can inherit the listener I have implemented and supplement the functions you want. At this time, you can't adjust the handletargetoffset method.

Finally, refer to Google's swiperefreshlayout, which provides setrefreshing to turn on or off the refresh animation. Why should openheader post (runnable)? I believe anyone who has used swiperefreshlayout to directly call setrefreshing (true) when oncreate knows this pit without a small circle!

3.3. Effect display

In addition to the above three, listview, viewpager, Scrollview and nestedscrollview are implemented in the demo. See the code for details

Demo address: GitHub: refreshlayoutdemo. If you think it's good, give it to star.

The above is a detailed explanation of the implementation idea of traceless transition pull-down refresh control for Android development introduced by Xiaobian. I hope it will be helpful to you. If you have any questions, please leave me a message and Xiaobian will reply to you in time. Thank you very much for your support for the programming tips website!