iOS Recipes - Matt Drance [18]
self.center = tempCenter;
return YES;
}
The recognizedCircle method calculates the distance between the touch points stored in the outlier variables LowX, HighX, LowY, and highY, the longest of these being taken as the diameter. From this, the center point and radius are easily calculated. A deviant value is then calculated based on the radius and the deviation property. To ensure that a full circle was recognized, the first and last touch points must not be too far apart (twice the deviant value); if they are, the state property will be set to UIGestureRecognizerStateFailed. Each of the points in a points array is validated by ensuring that the distance between the point and the circle center point is not more or less than the radius plus or minus the deviant. If all our points are validated, then the radius and center properties are set, and the return value is set to YES, signifying success. The touchesEnded:withEvent: method then sets the state property to UIGestureRecognizerStateRecognized.
When successful, the base class code triggers a call to the delegate action selector, which is specified when the gesture recognizer is instantiated—in this case, the circleFound method in mainViewController.m. In our example here, a smiley face, sized to match the radius and position of the recognized circle, is drawn to the UIView that was attached to the recognizer.
Though the code here is specific to recognizing a circle gesture, you can easily adapt this technique to recognize any type of gesture that you require.
Recipe 9 Create Self-contained Alert Views
Problem
The UIAlertView class gives you an easy, consistent interface for presenting important information to your users. The logic for responding to user input in those views, however, can be cumbersome and error-prone. Wouldn’t it be great to have a version of UIAlertView that is self-contained, easy to use, and easy to interact with from any controller code?
Solution
UIKit has a generous library of Apple-designed controls that are ready to use in any app, and UIAlertView is a great example: you get an Apple-designed dialog with a title, message, and buttons, and it even dims the screen to draw the user’s attention to the alert.
Creating an alert is easy enough: you initialize it and call show, and Apple does the rest. If all you’re doing is giving the user a message, with no action to be taken, this is a straightforward flow. If you present the user with choices, however, and need to respond to those choices, you have some more work to do: set your code as the alert view’s delegate, and implement one or more of the UIAlertViewDelegate protocol methods such as ‑alertView:clickedButtonAtIndex:.
It’s inside this delegate method where things can get not only cumbersome but dangerous. You need to determine which button was tapped in order to respond accordingly. But what’s the best way? You have a few choices:
Do a hard-coded comparison/switch against the button indexes
Send ‑buttonTitleAtIndex to the alert view, and compare the strings
The buttonIndex passed to your delegate method isn’t particularly useful, because you initially passed the button titles as varargs to the standard ‑initWithTitle:message:... method. Perhaps you’ve recorded the indices as constants elsewhere, but then you’ve introduced undesirable coupling into your code.
The second option—comparing button titles—is much less risky: provided you’ve defined the strings as globals or localized strings, the code should still work even after rearranging the button titles.
Either of these approaches carries some refactoring headaches and requires a nontrivial amount of scaffolding every time you want to throw up an alert view. It can get particularly ugly if your view controller presents multiple alerts based on the situation: now it’s not just “which button,” but “which button in which alert?”
PRPAlertView/ScrapCode.m
- (void)alertView:(UIAlertView *)alertView
willDismissWithButtonIndex:(NSInteger)buttonIndex {
NSString *buttonTitle = [alertView buttonTitleAtIndex:buttonIndex];