Android development art Exploration Study Notes (3), android art Exploration

Android development art Exploration Study Notes (3), android art Exploration

Chapter 3 View Event System

3. 1 basic View knowledge

　　3.1.1 what is view

View is the base class of all controls in Android. It is an abstraction of controls at the interface layer. It represents a control.

　　3.1.2 View location parameters

The position of a View is determined by its four vertices, which correspond to the four attributes of the View: top, left, right, bottom; note that these coordinates are relative to the parent container of the View. (In Android, the positive direction of the X axis and Y axis is right and bottom, respectively ).

3.0 New Attributes

X-view horizontal coordinates in the upper left corner;

Y-view vertical coordinates in the upper left corner;

Horizontal offset of the upper left corner of the translationX-view to the parent container;

Vertical offset of the upper left corner of the translationY-view to the parent container;

In the translation process, top and left indicate the location information of the original upper left corner, and the value does not change. In this case, x, y, translationX, translationY.

　　3.1.3 MotionEvent and TouchSlop

1 MotionEvent

The getX and getY Methods return the x and y coordinates in the upper left corner of the current View, while the getRawC and getRawY Methods return the x and y coordinates relative to the upper left corner of the mobile phone screen.

2 TouchSlop

TouchSlop is the minimum sliding distance that can be identified by the system. It is a constant and can be obtained through the following method: ViewConfiguration. get (getContext (). getScaledTouchSlop ();

　　3.1.4 VelocityTracker, GestureDetector and Scroller

1 VelocityTracker

VelocityTracker-Speed Tracking: tracks the speed of the finger in the Sliding Process (horizontal and vertical). Note that the speed can be negative. When the finger slides from right to left, the horizontal speed is a negative value.

2 GestureDetector

GestureDetector-gesture detection, used to detect users' clicks, slides, durations, double-clicks, and other behaviors.

Suggestion: If you only want to listen for slide-related information, implement it in onTouchEvent. If you want to listen for double-click behavior, use GestureDetector.

3 Scroller

Scroroller-elastic sliding is used to achieve the elastic sliding of a View (sliding with a transitional effect). It must be used with the View computeScroll method.

　　3.2 slide of View

Three ways to achieve View sliding:

1. slide through the scrollTo/scrollBy method of the View itself;

2. Slide the View by applying a translation effect to the animation;

3. By changing the LayoutParams of the View, the View is displayed as a slide;

　　3.2.1 use scrollTo/scrollBy

The source code of scrollTo/scrollBy is as follows:

public void scrollTo(int x ,int y){if(mScrollX!=x||mScrollY!=y){    int oldX=mScrollX;    int oldY=mScrollY;    mScrollX=x;    mScrollY=y;    invalidateParentCaches();    onScrollChanged(mScrollX,mScrollY,oldX,oldY);    if(!awakenScrollBars()){    postInvalidateOnAnimation();　　　　}　　}}public void scrollBy(int x,int y){    scrollTo(mScrollX+x,mScrollY+y);}

Among them, the value of mScrollX is always equal to the horizontal distance between the left edge of the View and the left edge of the View content, and the value of mScrollY is always equal to the vertical distance between the top edge of the View and the top edge of the View content;

ScrollTo/scrollBy can only change the position of the View content, but cannot change its position in the layout.

That is to say, using scrollTo/scrollBy to slide the View can only move the View content, and cannot move the View itself.

　　3.2.2 use Animation

Animation is used to move a View, mainly to operate the translationX and translationY attributes of the View. (Traditional View animation and attribute animation)

A View animation is an image operation on a View. It does not really change the position parameters of the View, including width and height.

　　3.2.3 change layout Parameters

It is mainly implemented by changing the LayoutParams of the View. The following code shows how to reset LayoutParams for a mButton1:

MarginLayoutParams params = (MarginLayoutParams) mButton1.getLayoutParams (); params. width + = 100; params. leftMargin + = 100; mButton1.requestLayout ();
// Or mButton1.setLayoutParams (params)

　　3.2.4 comparison of various Sliding Modes

ScrollTo/scrollBy: simple to operate and suitable for sliding the View content;

Animation: easy to operate, mainly applicable to views without interaction and complex animation effects;

Change layout parameters: the operation is slightly complicated and suitable for interactive views.

　　3.3 elastic sliding

　　3.3.1 Use scroroller

Note that the slide generated by scroroller is the slide of the View content, rather than the change of the View position.

The typical use of Scroller is as follows:

Scroller scroller = new Scroller (context); // scroll slowly to the specified position private void smoothScrollTo (int destX, int destY) {int scrollx = getScrollX (); int deltaX = destX-scrollX; // slide to destX within Ms. startScroll (scrollX, 0, deltaX,); invalidate () ;}@ Overridepublic void computeScroll () {if (scroller. computescroloffset () {scrollTo (scroller. getCurrX (), scroller. getCurrY (); postInvalidate ();}}

Scroroller's working mechanism: scroroller itself cannot achieve the sliding of the View. It needs to work with the View computeScroll method to achieve the elastic sliding effect. It constantly redraws the View, each re-painting has a time interval from the start time of the slide. Through this time interval Scroller, the Current Slide Position of the View can be obtained, you can use the scrollTo method to View the sliding position. In this way, each re-painting of a View will cause the View to slide in a small margin, and multiple small slides constitute an Elastic Slide.

　　3.4 View time distribution mechanism

　　3.4.1 Click Event transfer rules

The distribution process of click events is mainly completed in three methods.

DispatchTouchEvent (): used for event distribution. If an event can be passed to the current View, this method will be called. The returned results will be affected by the onTouchEvent of the current View and the dispatchTouchEvent method of the lower View, indicates whether to consume the current event.

OnInterceptTouchEvent (): it is called within the dispatchTouchEvent method to determine whether to intercept an event. If the current View intercepts an event, this method will not be called in the same event sequence, the returned result indicates whether to intercept the current event.

OnTouchEvent (): called in the dispatchTouchEvent method to process click events. The returned result indicates whether to consume the current event. If not, it is in the same event sequence, the current View cannot receive other events again.

Event Sequence refers to a series of events generated during the process from the moment the finger contacts the screen to the moment the finger leaves the screen. The event sequence starts with a down event, there are a number of unfixed move events in the process, and the event ends with an up event.

The working process of these three methods also understands the event distribution mechanism. Pseudocode indicates the relationship between the three methods as follows:

public boolean dispatchTouchEvent(MotionEvent ev){    boolean consume=false;    if(onInterceptTouchEvent(ev)){         consume=onTouchEvent(ev);          }else{         consume=child.dispatchTouchEvent(ev);        }     return consume;     }

Specific transfer rules: for a root ViewGroup, after a click event is generated, it is first passed to it, and its dispatchTouchEvent will be called, if the onInterceptTouchEvent method of this ViewGroup returns true, it indicates that it wants to intercept the current event, and the event will be handed over to this ViewGroup for processing, that is, its onTouchEvent method will be called, if the onInterceptTouchEvent of this ViewGroup returns false, it indicates that it does not intercept the current event. Then the current event will be passed to its child element, and the dispatchTouchEvent method of the child element will be called, this is repeated until the event is finally handled.

When a click event is generated, the transfer process follows the following sequence: Activity-> Window-> View, that is, the event is always first transmitted to the Activity, and the Activity is passed to the Window, finally, the Window is passed to the top-level View. After receiving the event, the top View distributes the event according to the event distribution mechanism. Consider one case. If the onTouchEvent of a View returns false, the onTouchEvent of its parent container will be called, and so on. If none of the elements used process the event, the event is finally passed to the Activity for processing, that is, the onTouchEvent method of the Activity is called.
Several important conclusions:

Under normal circumstances, an event sequence can only be intercepted and consumed by one VIew, because once an element intercepts an event, all the events in the same event sequence will be directly handled by it, therefore, the events in the same event sequence cannot be processed by two views at the same time, but they can be handled by special means. For example, a View forcibly transmits the events that should have been handled by itself to other views for processing through onTouchEvent.

Once a View is intercepted, this event sequence can only be handled by it, and its onInterceptTouchEvent will not be called.

Once a View starts to process events, if it does not consume ACTION_DOWN events (onTouchEvent returns false), other events in the same event sequence will not be handed over to it for processing, the event will be processed by its parent element again, that is, the onTouchEvent of the parent element will be called. This means that once an event is handed over to a View for processing, it must be consumed; otherwise, the remaining events in the same event sequence will not be handed over to it for processing.

If the View does not consume events other than ACTION_DOWN, the click events will disappear, and these click events will be passed to the Activity for processing.

By default, ViewGroup does not intercept any events.

View does not have the onInterceptTouchEvent method. Once an event is passed to it, its onTouchEvent method will be called.

By default, the OnTouchEvent method of View consumes events (true is returned ).

The enable attribute of View does not affect the default return value of onTouchEvent.

OnClick occurs only when the current View is clickable and receives down and up events.

The transfer process of an event is from the external, that is, the event is always passed to the parent element, and then the parent element is distributed to the Child View, the requestDisallowInterceptTouchEvent method can be used to intervene in the event distribution process of the parent element in the child element, except for the ACTION_DOWN event. (The requestDisallowInterceptTouchEvent method mainly sets the FLAG_DISALLOW_INTERCEPT flag in the parent element. Once set, ViewGroup cannot intercept click events other than ACTION_DOWN)

　　3.5 sliding conflict of View

Common slide conflicts

　　　　

Methods To resolve sliding conflicts: External interception and internal interception.

1. External Interception Method

Click events are first intercepted by the parent container. If the parent container requires this event, the event will not be intercepted if it is not required.

The implementation method is to override the onInterceptTouchEvent method of the parent container. The Code is as follows:

@ Override public boolean onInterceptTouchEvent (MotionEvent event) {boolean intercepted = false; int x = (int) event. getX (); int y = (int) event. getY (); switch (event. getAction () {case MotionEvent. ACTION_DOWN: intercepted = false; break; case MotionEvent. ACTION_MOVE: if (the parent container requires the current Click Event) {intercepted = true;} else {intercepted = false;} break; case MotionEvent. ACTION_UP: intercepted = false; break; default: break;} mLastXIntercept = x; mLastYIntercept = y; return intercepted ;}

2 internal interception method

The parent container does not intercept any event, and all the events used are passed to the child element. If the child element requires this event, it will be directly consumed; otherwise, it will be handled by the parent container. You must use the requestDisallowInterceptTouchEvent method to work normally. At the same time, rewrite the dispatchTouchEvent method of the child element. The Code is as follows:

Child element:

@ Override public boolean dispatchTouchEvent (MotionEvent event) {int x = (int) event. getX (); int y = (int) event. getY (); switch (event. getAction () {case MotionEvent. ACTION_DOWN: getParent (). requestDisallowInterceptTouchEvent (true); break; case MotionEvent. ACTION_MOVE: int deltaX = x-mLastX; int deltaY = y-mLastY; if (the parent container needs to click the event currently) {getParent (). requestDisallowInterceptTouchEvent (false);} break; case MotionEvent. ACTION_UP: break; default: break;} mLastX = x; mLastY = y; return super. dispatchTouchEvent (event );}

Parent element:

    @Override    public boolean onInterceptTouchEvent(MotionEvent event) {        int action=event.getAction();        if (action==MotionEvent.ACTION_DOWN){            return false;        }else{            return true;        }    }

 

The above is the typical code for processing sliding conflicts. when facing different sliding policies (scenario 1, 2, 3), you only need to modify the conditions.