Introduction to event handling in iPhone Development Guide

IPhone DevelopmentGuideEventProcessing introduction is the content to be introduced in this article, mainly to explain about the iphoneEventFirst, let's look at the details.

Event Processing

This chapter describes the event types in the iPhone operating system and explains how to handle them. We also discussed how to copy and paste data in an application and between applications using the mechanism provided by the UIPasteboard class, which was introduced in iPhone OS 3.0.

Event and Event Type

An event is an object that represents a user event, that is, user actions detected by the iPhone OS, such as finger touch or device jitter. In Cocoa Touch, an event is an instance of the UIEvent class. When a user event occurs-for example, touch the screen with a finger or slide over the surface-the system will continuously send the event object to the application for processing.

IPhone OS currently supports two types of events: Touch events and motion events. The UIEvent class is extended in iPhone OS 3.0. It not only supports these two types of events, but also can accommodate more types of events in the future. Declared enumerated constants are listed in Table 3-1.

Constant of event type and event subtype

 
 

  
  
typedef enum {  
  
  
    UIEventTypeTouches,  
  
  
    UIEventTypeMotion,  
  
  
} UIEventType;  
  
  
typedef enum {  
  
  
    UIEventSubtypeNone        = 0,  
  
  
    UIEventSubtypeMotionShake = 1,  
  
  
} UIEventSubtype; 
 
 

Each event has the event type and the associated subtypes. You can access the event by using the type and subtype attributes of UIEvent. Event types include touch and motion events. In iPhone OS 3.0, there is only one vibration-motion subtype (UIEventSubtypeMotionShake), and a touch event always contains one UIEventSubtypeNone subtype.

You shouldn't retain a UIEvent object in the code. If you need to maintain the current status of an event object for future use, you should copy and save these status bits in an appropriate way, such as using an instance variable or a dictionary object ).

Submit event

The event submission follows a specific path. As described in "Core Application Architecture. When a user touches a device screen, the iPhone OS identifies the touch Event Sequence and packs it into a UIEvent object and places it in the event queue of the currently activated application. If the system interprets the device vibration as a motion event, the Objects representing the event will also be placed in the event queue of the application.

Manage the application's single-piece UIApplication object to get an event from the top of the queue and dispatch it. Generally, it sends the event to the key window of the application-a window that accepts the focus of the user event-and then the UIWindow object representing the window sends the event to an initial object for processing. This object is different for touch events and motion events.

Touch events. The window object uses click detection hit-testing) and response chain responder chain) to find the view that receives the touch event. In click detection, a window calls hitTest: withEvent: In the top view of the view level. If YES is returned for this method, pointInside is recursively called on each view of the view level: withEvent:. This continues until the child view within the scope of the touch event is found. This view becomes the hit-test view.

If the hit-test view cannot process this event, the event will be traced back based on the response Chain, as described in "Responder Objects and the Responder Chain, until the system finds a view that can process it. A Touch object is described in "Touch Events") is associated with its hit-test view in its lifecycle, even if the Touch represented by this object is moved beyond the view. "Hit-Testing" discusses the programming meaning of click detection.

Sports Events. This window object sends motion events to the first responder for processing. The first Responder is described in "Responder Objects and the Responder Chain ).

Although the hit-test view and the first responder are usually the same view object, this is not required.

The UIApplication object and each UIWindow object distribute Events in the "Touch Events" method. (These classes use the same signature to declare a method ). Because these methods are the funnel points of events entering an application, You Can subclass UIApplication or UIWindow and override) sendEvent: method to monitor events that few programs need to do this ). If you override these methods, make sure to call the implementation of the superclass, that is, [super sendEvent: theEvent]); never play with event distribution.

Response object and response chain

The previous discussion mentioned the concept of the responder. So what is a responder and how does it work in the architecture of event submission?

Responder object) is an object that can respond to events and process them. UIResponder is the base class of all the response objects. It not only defines the programming interface for event processing but also for public responder behavior. UIApplication, UIView, and all the following UIView directly or indirectly inherited from UIResponder's UIKit class including UIWindow), then their instances are the response objects.

The first responder) is a UIView object in an application. This object is specified as the first receiver of a non-touch event. A UIWindow sends these events to the first responder in the message and sends them the first shot during processing. To receive these messages, the responder object must implement canBecomeFirstResponder and return YES; it must also receive a becomeFirstResponder message that can be triggered by itself ). The first responder is the first view of a window to receive the following types of events and messages:
Motion event-by calling the UIResponder Motion processing method, the Motion Events are described in detail.

Action message-a message is sent when a user operates a control, such as a button or slide bar. No target is specified for the action message.

Menu editing message-this message is sent when you click the edit menu command (detailed descriptions are provided in "Copy, Cut, and Paste Operations)

The first responder also works in text editing. A text view or text box in the editing focus is used as the first responder, which causes the virtual keyboard to be displayed.

Note: The application must explicitly set a first responder to handle Motion Events, action messages, and menu editing messages. UIKit automatically sets the text box and Text View clicked by the user as the first responder.

If the first responder or click check hit-test) view does not process an event, it may pass the event through the message) to the next responder in the response chain to see if it can be processed.

A response chain is the connection sequence of a responder object. Events, action messages, or menu editing messages are transmitted in turn. It allows the respondent to forward the event handling responsibilities to other higher-level objects. The application finds the appropriate processing object by passing an event up. Because the click detection view is also a response object, applications can also use the response chain when handling touch events. The response chain consists of a series of next responders, as shown in 3-1:

Figure 3-1 response chain in iPhone OS

When the system submits an event, it first sends it to a specific view. For touch events, this specific view is the one returned by hitTest: withEvent:. For motion events and action messages, this view is the first responder. If this initial view does not process this event, it will trace the response chain in a specific path:

1. Click the detection view or the first responder to send an event or action message to its view controller. If there is one, the view controller is passed to its parent view superview ).

2. If a view or its view controller cannot process this event or action message, it will be passed to the parent view of the view.

3. In this view level, each subsequent parent view follows the above pattern if it cannot process this event or action message.

4. If the top-level view cannot process this event or action message, it is passed to the UIWindow object for processing.

5. If the UIWindow object cannot be processed, it is passed to the single-piece application object UIApplication.

If the application object cannot process this event or action message, it will be discarded.

If you implement a custom view to process events or action messages, you should not directly forward the event or message to nextResponder to backtrack the response chain. Instead, we should call the superclass implementation of the current event processing method-and let the Uikit process the traversal of the response chain.

Adjust event submission

UIKit provides programming methods for applications to simplify event processing or completely disable event streams. The following list summarizes these methods:

1) Submit closed touch events

By default, the view receives touch events, but you can set its userInteractionEnabled attribute to no to close event submission. The view does not receive events when hidden or transparent.

2) Close the submission of touch events within a period of time

The application can call the UIApplication method beginIgnoringInteractionEvents and call the endIgnoringInteractionEvents method later. The first method completely stops the application from receiving touch event messages, and the second method resumes receiving messages. Sometimes you want to disable event reception, such as executing an animation.

3) enable multi-touch submission

By default, the view ignores all events except the first touch in the multi-touch event sequence. If you want to process multi-touch views in this view, you must enable this function for this view. Set the multipleTouchEnabled attribute of your view to YES by programming, or set the relevant attribute in the inspector of the view of Interface Builder.

4) restrict the submission of events to a single view

By default, the exclusiveTouch attribute of a view is set to NO, which means that the view does not block other views in the window from receiving touch events. If you set this attribute to YES, you can mark this view so that when it tracks touch, it is the only view in the current window that can trace touch. Other views in the window cannot receive touch events. However, a view marked as "exclusive touch" cannot receive touch events related to other views in the same window. If a finger is exposed to an exclusive-touch view, this touch event will be submitted only when this view is the only view that tracks the finger in the current window. If one finger touches a non-exclusive view, this touch event is submitted only when no other finger is tracked by an exclusive-touch view.

5) restrict the submission of events to the subview

A custom UIView class can override hitTest: withEvent: to restrict multi-point touch.EventSubview submitted to it. Please refer to the "Hit-Testing" discussion about this technology ".

Summary:IPhone DevelopmentGuideEventI hope this article will help you with the introduction!