This article has to cooperate with: event distribution analysis – copy jingdong home page two linkage + event distribution detailed food.

Event distribution and issues

Details: juejin.cn/post/697614…

Event distribution is top-down: Activity -> viewGroup -> View event consumption is bottom-up: View -> viewGroup -> Activity

Problem: When you need to implement nested sliders like this. There are two general solutions to event conflicts: internal interception and external interception. But no matter what the solution, (while the head can still slide, father consumption, let the head slide first. Otherwise son consumption, slide below). Can’t resolve a slide event (one Down – multiple moves, front of the Move slide father. But the back of the father slipped, have to slide son), namely let the father consumption and let the son consumption. (That is, to slide the head, you have to raise your hand to slide once, to slide the son)

NestedScrollView

Because the Move in an event cannot be distributed to both the father and the son. Such nested sliders, Google in Material Design gave a NestedScrollView to solve nested sliders.

NestedScrollView is divided into NestedScrollingParent and NestedScrollingChild

You need to implement both NestedScrollingParent and NestedScrollingChild to nest sliders

Where you want to nest the slide, if you resolve to a control that implements the NestedScrollingChild, it will walk up the parent tree until it reaches a control that implements the parent NestedScrollingParent, and then bind (it will continue to look up because there may be multiple levels of nesting). If the father is not found, then nested sliders are not supported.

When you’re dealing with a rolling event, the son makes the request and the father receives it, so the son is dispatch, start, and so on, and the father is onXXX

Conclusion: Kong Rong lets the pear Kong Rong has a pear (event), but Kong Rong is more filial, so: 1. Kong Rong dispatchNestedPreScroll asked father whether to eat –> Father: 1. Eat up (the event ends) 2. Take a bite, there is still something left. After eating (the event is over) 2. Take a bite, there is still a surplus 3. There is still a surplus, Kong Rong Dispatcher stedScroll asked father whether to eat -> Father: 1. (the event is over) 2. Have a bite, there is still some left. 4.

Initialization phase: the son StartNestedScroll looks up for his father and binds. (The starting point is actually the son’s onTouchEvent Down)

Pre-rolling phase: sonboolean dispatchNestedPreScrollThe first time I asked my father if he was spending, my fatheronNestedPreScrollReceive and process the event (starting from the son’s onTouchEvent Move)

Rolling phase: sonboolean dispatchNestedScrollThe second time I asked my father if he was spending, my fatheronNestedScrollReceive processing events

NestedScrollingChild

NestedScrollingChild and NestedScrollingParent are interfaces.

The comments are pretty clear.

NestedScrollingChild and NestedScrollingChild2

The difference is that NestedScrollingChild2 has an extra int type. There are two types, Touch and Fling

NestedScrollingParent

NestedScrollingParent has nothing to say, just like Child

NestedScrollingChildHelper and NestedScrollingParentHelper

Helper classes can start and end by calling methods in the helper instead of writing them yourself. (StartNestedScroll, onStopNestedScroll, etc.) write their own mainly is the intermediate pre-scrolling stage, the scrolling stage (dispatchNestedPreScroll, onNestedPreScroll, etc.).

The method to realize they don’t all threw NestedScrollingChildHelper, then only to achieve your need

CoordinatorLayout The CoordinatorLayout

CoordinatorLayout is used when you need to deal with generating relationships between child controls and child controls. (Drag a control, another control changes color, position, etc.) It’s a step up from NestedScrollView, which is all about sliding, and the relationship between parent and child controls. CoordinatorLayout, however, can generate relationships between child controls and has the following four functions.

1. Handle the dependent interaction between child controls 2. Handle the nested sliding between child controls 3. Handle the measurement and layout of child controls. 4. Handle event interception and response of child controls

These features are built on top of the Behavior plug-in.

The main methods are as follows

Behaviors plug-in

The Behavior plug-in is designed to insert whatever functionality it needs, like pluginization. It saves space.

The principle is the observer mode. The depandency control has a List child that is subscribed to. When the observer changes, it determines the layoutDependsOn and sends a message. This is the child receives method (onDependentViewChanged/onDepe ndentViewRemoved).

CoordainatorLayout can also send messages to ChildView within the nested slider.

Child controls under CoordainatorLayout can interact with multiple sibling controls.

The onMeasureChild and onLayoutChild methods of the child control

View lifecycle (emphasis)

View lifecycle OnCreate -> setcontentView(Layout) LayoutInflater. Inflate XML -> View onFinishInflater add Content DecorView

activity ->window ->view

Attach time new PhoneWindow

Resume has makevisible methods, phoneWindow.addView (DecorView)

Setview -> WMS (WindowsManagerService) -> SurfaceFling -> Skia

View refresh mechanism: performTraversals measure -> layout -> draw

activity onCreate

[Change visibility] –> Construct View() –> onFinishInflate() –> onAttachedToWindow() –> onMeasure() –> onSizeChanged() –> onLayout() –> onDraw() –> onDetackedFromWindow()