99.99% of Android custom view series realizes QQ sideslip deletion effect. Detailed example code

First of all, it is stated that this article is modified based on the swipemenulistview of "baoyongzhang" on GitHub. The project address is:

https://github.com/baoyongzhang/SwipeMenuListView

It can be said that this sideslip deletion effect is the best and more flexible project I have seen, not one of them!!!

However, before using it, you need to pay attention to two points:

1. The project supports gradle dependency, but the project corresponding to the dependency address provided by the author is not the latest project. The code after dependency is inconsistent with that used in the demo. It will prompt that there is no basewidelistadapter class, because this class is submitted by other developers, so if you want to use the latest code, you still have to download the code, Then copy the library file to your project for use

The following figure is the dependent address provided by the author, not the latest, so friends who want to use the latest code should download the code directly to the local area

2. The second note should be a bug. If you have tested the demo given by the author, you will find that if an item has been pulled out, slide the listview up or down to move the pulled item out of the screen, and then move it back. The pulled item will directly return to the non pulled state. This will make users feel very confused, I have clearly pulled out this menu. Why is it missing again? Then I may have the idea that the software is really junk, and then I may uninstall your software. As shown in the figure below:

For the above two precautions, the first one has nothing to say. What about the second one? Don't worry, that's what we're going to say today

First of all, we can study the sideslip deletion effect of QQ. Speaking of this, you can open your QQ to see its specific effect

You will find that if an item is pulled out, when your finger is placed on another item, it will directly close the pulled item first, and the subsequent events of the current action will no longer respond. Unless you put your finger on the screen again, it will respond to the relevant events. If your finger is placed on the currently pulled item, it will not hide the item, And can normally respond to left and right sliding events

OK, after analyzing the effect of QQ, let's discuss its implementation principle:

1. If an item has been pulled out, how to implement it?

First, we need to judge whether the item we currently press is the one pulled out. If not, we need to close it. If yes, we don't care. The code is as follows:

2. How to realize it?

This is very simple. According to the event distribution principle of view, if false is returned in a touch event, the subsequent events of the event will not be handed over to him for processing, that is, if we are in action_ If false is returned during down, the subsequent action_ MOVE,ACTION_ Up and other events will not respond, so to achieve this effect, we only need to return false after closing the menu. The complete code is as follows:

These lines of code realize the first half of the QQ effect just analyzed, that is, if an item is pulled out, it will respond to relevant events

The above lines of code are modified based on the swipemenulistview class. The complete modified swipemenulistview code is as follows:

In this way, the effect of QQ is not very simple, but thanks to the good writing of the original author, it is easier for me to modify it

In other words, when the pressed item is not the pulled item, the corresponding effect has been achieved. If the pressed item is exactly the pulled item, how can the effect be achieved?

In fact, the original author has actually achieved this effect, but the implementation is not good enough. There are some problems. I fix this problem here

The problem is: if you slide left and right on the currently pulled item, when you lift your finger and the sliding direction is toward the pulling direction, there is a great chance that the pulled item will be closed. For example, if you set the sliding to the left is the pulling direction, when you slide left and right on the pulled item, And you slide to the left the moment before you lift your finger. It makes sense that this item should be in the state of being pulled apart, but in fact, there is a great chance that when you lift your finger, this item will be closed, so this is a problem that affects the user experience. In fact, an item is a swipemenulayout. In the swipemenulayout class, there is an onswape method, The parameter motionevent of this method is passed from the ontouchevent method of swipemenullistview. As mentioned earlier, problems will occur only when the finger is raised. Let's look at action directly_ The implementation code in up,

The following code is problematic:

Let's analyze it. Isfliing doesn't need to look at it. The problem is not here. Let's look at the following judgment logic: when the absolute value of the sliding distance in the x-axis direction is greater than half of the menu width and the sliding direction is toward the opening direction, an item will be opened. Not all other situations will directly enter the else statement to close the item. The problem is here, The problem mentioned above is also caused by this. Imagine a situation, because the current item has been pulled out. If the absolute value of our sliding distance does not exceed half of the menu width, but our sliding direction is towards the direction in which the item is pulled out, it makes sense that our item should continue to be displayed in the pulled out state, However, according to the judgment logic in the code, this situation is directly entered into the else statement, that is, the item is directly closed, so there is a big problem in the logical judgment here. The effect we want is: since you have been pulled out, as long as you continue to slide in the pull-out direction, I will not enter the else, but directly judge the sliding distance in the if. This logic is correct, In order to avoid problems during the first sliding, we have to do corresponding operations for the first sliding

Therefore, the modified code logic is as follows:

In this way, we perfectly realize the second effect of QQ, that is, if your finger is placed on the currently pulled item and can normally respond to left and right sliding events

The code of the completely modified swipemenulayout class is as follows:

Well, since our title name is 99.99% to achieve the sideslip deletion effect, let's take a look at the effect picture to see if it is the same as 99.99%:

QQ renderings:

Modified rendering:

The above two renderings may not show anything, especially the effects we mentioned above. The main reason is that after the video screen is converted to GIF, the card playback speed is fast, so if you want to compare the effect of QQ with our own effect, you'd better download the demo and compare it yourself. I can only say that the effect after the change is basically the same as that of QQ. Gaga~~