Perfect solution of Android sliding conflict

Android sliding is a necessary operation on smart phones, but when developing, do you often encounter the problem of sliding conflict like me? For example, the simplest thing is to add a side sliding action in listview. At this time, the conflict is inevitable. How can we solve this problem? First, let's talk about how to solve the sliding conflicts.

Scenario 1: similar to the effect that viewpager nested fragmnet and nested a listview in fragmnet, you can switch or trigger the display of other views by sliding left and right. However, this conflict has been handled inside the viewpager, so we will find that the viewpager nesting fragnet is very smooth. If we use Scrollview instead of viewpager, we need to take the initiative to deal with this conflict; Scenario 2: this situation is more complicated, that is, the view and the nested view need to slide in the same direction. At this time, when the user slides the view, the system does not know which view the user wants to slide, and the problem jumps out involuntarily; Scenario 3: scenario 3 is the most complex one, i.e. scenario 1 and scenario 2. The superposition of the two situations requires dealing with internal and central, central and external conflicts.

The problem has come out. How can we solve it?

Since the view can slide, there is a sliding law. Generally speaking, when the user slides, the external view needs to intercept the click event. When the user slides up and down, the internal view needs to intercept the click event of the view. At this time, we can deal with the conflict event according to whether it slides up and down or left and right. For scenario 2 and scenario 3, the general idea is the same. Modify the relevant sliding rules.

1. External interception:

The so-called external interception means that click events are intercepted by the parent container first. If necessary, they are intercepted, otherwise they are not intercepted. In this way, the problem of scenario 1 can be simply handled.

The above code is the most basic external interception logic. You can modify the conditions required by the parent container for different situations. When clicking and releasing the view, we don't need to handle the sliding operation. We just need to intercept when dragging the view.

2. Internal interception:

Internal interception is the opposite of external interception, which means that all events are passed to the child view for processing. If necessary, the child view will be consumed directly, otherwise it will not be consumed. Here, consumption means that the child view handles the events passed by the parent container. This method needs to be combined with the requestdisallowinterceptedtouchevent method:

Except for the child view that needs to be processed, the parent container intercepts all events except the press event by default, so that the parent container can continue to intercept other events when the child view calls the requestdisallowunterceptedtouchevent method. This is a typical internal interception processing scheme. Here you may wonder why the parent container cannot intercept action_ What about the down event? That's because of action_ The down event is not affected by flag_ DISALLOW_ Interrupt this flag controls if the parent container intercepts the action_ Down event, then all events cannot be passed to the child view, and such interception can not achieve our purpose at all.

As for the solution of scenario 3, fine tune scheme 1 and scheme 2 according to different situations.

There are so many solutions to sliding conflicts, and the problems mentioned at the beginning can obviously be solved by using one solution.