- Touches
- Recipe: Adding a Simple Direct Manipulation Interface
- Recipe: Adding Pan Gesture Recognizers
- Recipe: Using Multiple Gesture Recognizers Simultaneously
- Recipe: Constraining Movement
- Recipe: Testing Touches
- Recipe: Testing Against a Bitmap
- Recipe: Drawing Touches Onscreen
- Recipe: Smoothing Drawings
- Recipe: Using Multi-Touch Interaction
- Recipe: Detecting Circles
- Recipe: Creating a Custom Gesture Recognizer
- Recipe: Dragging from a Scroll View
- Recipe: Live Touch Feedback
- Recipe: Adding Menus to Views
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Recipe: Testing Touches
Most onscreen view elements for direct manipulation interfaces are not rectangular. This complicates touch detection because parts of the actual view rectangle may not correspond to actual touch points. Figure 1-2 shows the problem in action. The screenshot on the right shows the interface with its touch-based subviews. The shot on the left shows the actual view bounds for each subview. The light gray areas around each onscreen circle fall within the bounds, but touches to those areas should not “hit” the view in question.
)
Figure 1-2. The application should ignore touches to the gray areas that surround each circle (left). The actual interface (right) uses a clear background (zero alpha values) to hide the parts of the view that are not used.
iOS senses user taps throughout the entire view frame. This includes the undrawn area, such as the corners of the frame outside the actual circles of Figure 1-2, just as much as the primary presentation. That means that unless you add some sort of hit test, users may attempt to tap through to a view that’s “obscured” by the clear portion of the UIView frame.
Visualize your actual view bounds by setting its background color, for example:
dragger.backgroundColor = [UIColor lightGrayColor];
This adds the backsplashes shown in Figure 1-2 (left) without affecting the actual onscreen art. In this case, the art consists of a centered circle with a transparent background. Unless you add some sort of test, all taps to any portion of this frame are captured by the view in question. Enabling background colors offers a convenient debugging aid to visualize the true extent of each view; don’t forget to comment out the background color assignment in production code. Alternatively, you can set a view layer’s border width or style.
Recipe 1-5 adds a simple hit test to the views, determining whether touches fall within the circle. This test overrides the standard UIView’s pointInside:withEvent: method. This method returns either YES (the point falls inside the view) or NO (it does not). The test here uses basic geometry, checking whether the touch lies within the circle’s radius. You can provide any test that works with your onscreen views. As you see in Recipe 1-6, which follows in the next section, that test can be expanded for much finer control.
Be aware that the math for touch detection on Retina display devices remains the same as that for older units. The extra onboard pixels do not affect your gesture-handling math. Your view’s coordinate system remains floating point with subpixel accuracy. The number of pixels the device uses to draw to the screen does not affect UIView bounds and UITouch coordinates. It simply provides a way to provide higher detail graphics within that coordinate system.
Recipe 1-5. Providing a Circular Hit Test
- (BOOL) pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
CGPoint pt;
float HALFSIDE = SIDELENGTH / 2.0f;
// normalize with centered origin
pt.x = (point.x - HALFSIDE) / HALFSIDE;
pt.y = (point.y - HALFSIDE) / HALFSIDE;
// x^2 + y^2 = radius^2
float xsquared = pt.x * pt.x;
float ysquared = pt.y * pt.y;
// If the radius <= 1, the point is within the clipped circle
if ((xsquared + ysquared) <= 1.0) return YES;
return NO;
}