Before we complete our discussion of events, we’d like to cover a few more topics of interest. We’ll explore how to regulate the report of events in a variety of ways and then describe some deficiencies in the event model.
Regulating events
As we mentioned earlier, there are some ways that you can modify how events are reported (and whether they are at all). As you’ll see, three different objects give you access to this sort of regulation: UIResponder, UIView, and UIApplication. We’ve listed all the notable options we’ll discuss in table 6.4.
Because UIView is a subclass of UIResponder, you generally have access to the methods from both classes in most UIKit objects. You’ll need to do some additional work to access the UIApplication methods.
Table 6.4 Properties in various objects allow for additional control of when events are monitored.
|
Method or property |
Type |
Summary |
|
nextResponder |
UIResponder method |
Returns the next responder in the chain by default but can be modified |
|
hitTest:withEvent: |
UIView method |
Returns the deepest subview containing a point by default but can be modified |
|
exclusiveTouch |
UIView property |
A Boolean set to NO by default; controls whether other views in the same window are blocked from receiving events |
|
multipleTouchEnabled |
UIView property |
A Boolean set to NO by default; controls whether multitouches after the first are thrown out |
|
beginIgnoringInteractionEvents |
UIApplication method |
Turns off touch event handling |
|
endIgnoringInteractionEvents |
UIApplication method |
Turns on touch event handling |
|
isIgnoringInteractionEvents |
UIApplication method |
Tells whether the application is ignoring touch events |
UIRESPONDER REGULATION
You’ve already seen that UIResponder is the source of the methods that let you capture events; as shown here, it’s also the home of the methods that control how the responder chain works.
Most of the responder chain-related methods aren’t directly used by your code; instead, they typically appear deep in frameworks. becomeFirstResponder and resignFirstResponder (which control who the first responder is) and canBecome-FirstResponder, canResignFirstResponder, and isFirstResponder (which return Booleans related to the information in question) all typically fall into this category.
The last UIResponder method, nextResponder, may be of use in your programs. As defined by UIResponder, nextResponder returns the next responder, per the normal responder chain. You used it in the example to pass your touches up.
If you want to change the normal order of the responder chain, you can do so by creating your own nextResponder function in a subclass. This new function overrides its parent method and allows your program to take a different path up your responder chain.
UIVIEW REGULATION
When you move into the UIView class methods, you can take the opposite approach by overriding hitTest:withEvent:. This method is passed a CGPoint and an event, and by default it returns the deepest subview that contains the point. By writing a new method, you can cause your responder chain to start at a different point.
The two UIView properties that we noted both work as you’d expect. exclusive-Touch declares that the view in question is the only one that can receive events (which is an alternative way you could have managed the eventreporter example, where you didn’t want anything but the reportView to accept events). Meanwhile, multiple-TouchEnabled starts reporting of multitouch events, which are otherwise ignored.
UIAPPLICATION REGULATION
Finally, we come to the UIApplication methods. These lie outside the normal hierarchy of objects, and thus you can’t get to them from your view objects. Instead, you need to call them directly from the UIApplication object, as shown here:
[[UIApplication sharedApplication] beginIgnoringInteractionEvents];
As you may recall from topic 3, sharedApplication is a UIApplication class method that provides a reference to the application object. Typically, you use its return as the receiver for the beginIgnoringInteractionEvents message.
Each of the three methods listed under UIApplication works as you’d expect when you know the secret to accessing them.
Other event methods and properties
We’ve spent a lot of time on events, but at the same time we’ve only scratched the surface. Events give you low-level access to user input, but you won’t use events much. Instead, you’ll use the device’s many control objects (and thus actions) in order to accept almost all user input.
As a result, this topic offers you a compromise: a solid look at how events work that should suffice for those times when you do need to descend to touch management, but not all of the intricacies. The thing that we’ve most clearly left out is how to work with multitouch events. For that, we point you, as usual, to the Apple iOS SDK developer website. A good tutorial on multitouch events is available as part of the iOS Programming Guide; you should read if you’re one of that smaller percentage of developers—such as programmers creating games and novelties—who may need access to multitouches and more complex gestures.
