Interface activity interactive response of Android system programming introduction series

In the previous article, we learned that the drawing of the interface activity completely depends on the loaded view component view. In addition, each touch operation of the user can be received and responded in the interface activity, or directly passed to a view response. How should the user respond to the user's operation? Does the same operation act on the interface or a sub view in the interface? In view of the different interaction modes generated by the user's operation objects, this paper will introduce them respectively.

When it comes to interface interaction, it is easy to think of the user's touch operation on the device screen. But how do you determine where the user touches when the screen is so large? The Android system defines a set of screen coordinate rules, which are not only applicable to the current screen interaction, but also applicable to the animation drawing and other screen related operations mentioned later. This rule takes the upper left corner of the screen as the origin of the screen coordinates, the direction extending from the upper left corner to the upper right corner as the X axis of the screen coordinates, and the direction extending from the upper left corner to the lower left corner as the Y axis of the screen coordinates.

With a measurement standard for the touch position of the screen, can you do touch operation according to different positions? When it comes to touch operation, it also needs to be processed separately after refinement. Android system roughly divides user operation behavior into three types: pressing behavior, sliding behavior, lifting and releasing behavior. In this way, the system can make separate response processing according to each operation behavior.

In addition, in addition to the hardware device screen mentioned above, the user's operation object also has the keys of the hardware device (including hardware keys and virtual keys). However, there are only two kinds of key operation behaviors: press behavior and lift release behavior, and the key operation does not need to use the relevant contents of screen coordinates.

Based on the above introduction, the following three methods can be rewritten in the interface activity to respond to the user's interface operation interaction.

Relatively speaking, the view response in the interface is more cumbersome, and the effect can be more diversified. When the view is used as the user's operation object, the above three methods of interface response can still be rewritten, but the system view often encapsulates a layer of simpler and crude response methods.

There are two code implementations for rewriting the three methods in the interface response. First, for the defined view class, you can call monitoring methods such as setontouchlistener (view. Ontouchlistener L) to implement relevant response methods in the monitoring class. Or take the defined view as the parent class and re create a custom view. In the new custom view, you can directly override the relevant response methods. Where the original view class is declared, modify it to use the new custom view class. Generally, only mode 1 implementation can be used for classes declared final.

Why encapsulate a layer of response methods? The user's operations on the view are often fixed operation types such as clicking (pressing and lifting release actions are executed in a short time), long pressing (waiting for a period of time after pressing and then lifting and release actions), dragging (sliding and then lifting and release actions are executed after pressing and then sliding). If each view needs to subdivide the user's operation behavior, there will be a large number of redundant operation type judgment codes, so the Android SDK defines a series of interfaces corresponding to the user's operation types. If a view needs to respond to an operation, it only needs to set the instantiated object of its operation type interface and implement the relevant methods in the object. These interfaces mainly include the following three.

In addition, different system views may have separate response methods, or custom views may also provide separate response methods. For example, how to respond after a row of data in the list view is clicked separately, these should be found and used according to the specific view class, which will not be repeated here.

Among the three interface response methods mentioned above, the precondition for their callback time is that the sub view is not processed, that is, the return result of the interface response method of the sub view is false. This involves the event delivery mechanism of Android system. We know that after the interface activity is created, it will call setcontentview (int layoutid) to load the root view, and a layer of sub views can be embedded in the root view. Then, if the user touches his finger on the screen, the pressing behavior will be triggered. The behavior will be first passed to the root view as an event, and then the root view will pass the event to the child view, and the child view will pass the event to the child view of the child view. In this way, the events will be passed layer by layer according to the nesting order during loading, which is called event distribution. Until the event is passed to the last layer of child view, or a layer view does not continue to pass the event, the event will be processed first in the last layer view. After receiving the passed in event, each layer view has two ways to choose, either continue to pass the event to the child view or handle the event by itself. If the second way is selected, it will not continue to pass the child view, but handle the event by itself, which is called event interception. Once a layer view processes the event, its parent layer view will continue to process the event, and then the parent layer view of the parent layer will process the event. The event is processed at such a layer until the root view processes the event, which is called event processing. After event distribution and event processing, such an event delivery mechanism is completed. This is true for every event mentioned above.

The implementation of the above process in the code only needs to define a rewritable method for event distribution, event interception and event processing respectively. The places where this method can be rewritten are mainly in android.app.acitivty and android.view.view. Since event interception only occurs in the transfer process of sub views and is not required in the interface, the method corresponding to event interception can only be rewritten in android.view.groupview.

The above describes the interactive response to an interface activity. How do two interface activities interact? This uses the android.content.intent intent intent class used to start the activity in the loading interface article. Unlike the interaction between users and interfaces, the interaction between interfaces is mainly the sharing of variable data, so the types of interactive data supported by intent are limited.

Before starting an interface activity, create an intention object. Call putextras (bundle bundle) method on the intention object to package the data to be sent into an instance of android.os.bundle.

The data types that the bundle object can store include eight basic data types: Boolean, char, byte, short, int, float, double and long, string type and any type that implements the Parcelable interface, its [] array or ArrayList array, and some other infrequent types. These data are saved in the bundle object in the form of key value pairs. For different data types to be saved, call the corresponding putt (string key, t value) series methods respectively, that is, you can store them in the form of parameter 1 key and parameter 2 value. Similarly, you can call the corresponding gett (string key) series methods to get the value data corresponding to the specified parameter 1 key. T here generally refers to the different data types supported. In addition, you can also directly call putextra (string key, t value) series methods in the created intention object to store the data to be sent directly in the form of key value pairs. Similarly, you can also use gettextra (string key) series methods to retrieve the value data corresponding to a specified parameter key. T here also generally refers to different data types supported by the bundle.

After packaging all the data, you can continue to call the startactivity (intent intent) series methods in the current interface activity to start another interface activity specified in the intent intent parameter. The startactivity (intent) method here is the simplest startup method. In addition, startactivity (intent, bundle) packages the data to be sent during startup and passes it in as parameter 2. Or startactivityforresult (int requestcode, int requestcode) passes a unique value as parameter 2 during startup to distinguish the intention of starting different interfaces. After the started interface activity returns, the system will call the onactivityresult (int requestcode, int resultcode, int data) method in the current interface activity, so you can override this method. According to the uniqueness of parameter 1, different interface intentions started before are distinguished. Parameter 2 is the result value returned according to different closing states of the startup interface. The default value is android.app.activity.result_ Canceled, or android.app.activity.result_ FIRST_ User and android.app.activity.result_ OK, its value needs to be set when the startup interface returns. Parameter 3 is the intent type returned from the startup interface. It mainly uses the bundle to package data type objects. Similarly, its value can be set when returning from the startup interface.

As the startup interface for receiving data, after binding the context environment, the activity can use the getintent() method to obtain the passed intent object in the oncreate (bundle savedinstancestate) method. After obtaining the object, the packaged data can be obtained through getbextras() or a series of gettextra (string key), In this way, the variable data in the previous interface Activiy before startup can be used in the startup interface.

When the startup interface activity is returned by user operation, the system will call back the onbackpressed () method of the startup interface, and then remove the activity from the stack and destroy it. So you can rewrite the onBackPressed () method, and call setResult (int resultCode, Intent data) in this method to set the parameter of the return time mentioned above. Alternatively, in the activity code of the startup interface, you can actively call the finish () method to close the current interface. Therefore, before calling the finish () method, you can call setresult (int resultcode, intent data) to set the return parameters.