Now that you have some experience with Objective-C and the iOS SDK, how would you add the colorize-on-shake and invert-color-on-rotate features? You would probably write a method that would loop over every line, perform some calculations with that line’s data, and then set its color.
// A candidate for colorizeOnShake as implemented by TouchDrawView
- (void)colorizeOnShake
{
for(Line *l in completeLines) {
UIColor *clr = [self computeColorForLine:l];
[l setColor:clr];
}
[self setNeedsDisplay];
}
Then, you would write a similar method for inverting the current color of a Line.
// A candidate for invertOnShake as implemented by TouchDrawView
- (void)invertOnRotate
{
for(Line *l in completeLines) {
// The method called to compute the color
// is the only difference in this method
// versus the previous one.
UIColor *clr = [self invertedColorForLine:l];
[l setColor:clr];
}
[self setNeedsDisplay];
}
Now, this is a fine approach, but notice the redundancy between the two methods. Imagine if you wanted to add another coloring scheme to your application; for example, a double tap could reset all of the lines to black. This method would repeat the same general form as the previous two (looping over all of the lines and giving them a color) with slightly different details (the calculations to determine the color).
It would be much cooler to write the general form once and plug in different sets of details. With blocks, you can. In TouchDrawView.m, implement a stub for the following method. This method will eventually take care of the generic part of the process.
- (void)transformLineColorsWithBlock:(UIColor * (^)(Line *))colorForLine
{
// You'll fill in the body for this method in a bit.
// The crazy syntax of the argument for this method
// deserves some discussion first.
}
Scary syntax, huh? It’s actually not that bad when you break it down. The method transformLineColorsWithBlock: accepts one argument: a block. This block must return an instance of UIColor, and its only argument is of type Line.
The syntax of a block is made even scarier because it is being used as an argument to a method, which adds an additional set of parentheses around the block. You will get used to it.
The name of the block variable in the scope of this method is colorForLine. A block, being a piece of executable code, can be called just like a C function. Therefore, you can run the code in this block like so:
UIColor *c = colorForLine(someLine);
The goal of the method transformLineColorsWithBlock: is to change the color of every line in the completeLines given a block that defines how they should be colored. Thus, the implementation of this method will iterate over every Line in completeLines and set its color to the return value of the block. Update this method in TouchDrawView.m.
- (void)transformLineColorsWithBlock:(UIColor * (^)(Line *))colorForLine
{
for(Line *l in completeLines) {
UIColor *c = colorForLine(l);
[l setColor:c];
}
[self setNeedsDisplay];
}
Build your application to make sure there are no errors. It will still run the same because you have yet to invoke this method.
Now, you will implement a method that will be invoked when the user shakes the device. It will create a block that will be sent to transformLineColorsWithBlock:; which executes the block for each of the completeLines. This block will do some simple geometry to compute a color for a given Line. You will use the difference between the x and y components of the start and end points to compute the red and green values of the color, and the length of the line for the blue component. Define this method in TouchDrawView.m.
- (void)colorize
{
// Vertical means more red, horizontal means more green,
// longer means more blue
// A block variable named colorScheme is created here:
UIColor * (^colorScheme)(Line *) = ^(Line *l) {
// Compute delta between begin and end points
// for each component
float dx = [l end].x - [l begin].x;
float dy = [l end].y - [l begin].y;
// If dx is near zero, red = 1, otherwise, use slope
float r = (fabs(dx) < 0.001 ? 1.0 : fabs(dy / dx));
// If dy is near zero, green = 1, otherwise, use inv. slope
float g = (fabs(dy) < 0.001 ? 1.0 : fabs(dx / dy));
// blue = length over 300
float b = hypot(dx, dy) / 300.0;
return [UIColor colorWithRed:r green:g blue:b alpha:1];
};
// Pass this colorScheme block to the method
// that will iterate over every line and assign
// the computed color to that line
[self transformLineColorsWithBlock:colorScheme];
}
We’re back in scary syntax land, again. Let’s break it down. The ultimate goal of this method is to create a block that takes a Line as an argument and returns a UIColor. This block will then be passed to the method transformLineColorsWithBlock:, which will execute this block for each line and set its color. Therefore, we must create a block and a block variable that holds a reference to that block.
The actual block is the part that follows the assignment operator (=). A block is defined by the ^ character and parentheses that contain the arguments that must be passed to this block when it is called, followed by curly brackets where the block body is entered. Objective-C, C, and C++ code can make up the body of a block.
A block variable, which holds a reference to a block, is the part before the assignment operator. A block variable is just like any other variable: it has a type and a name. The only difference is that the variable declaration is a bit ugly. Typically, variable definitions follow the following form:
type varname = ...; // Example int counter = 0;
The syntax for a block variable, however, mixes the name of the variable in the middle of the type of the block. The form is the return type, followed by parentheses that contain the ^ character along with the name of the variable and another set of parentheses that contain all of the arguments for this block.
The assignment of colorScheme to the block defined in colorize is valid because the block it references has the same arguments and return type. (You don’t have to include the return type when defining the block in this way; the compiler will figure it out.) Try changing the block to have a different argument list to see the compiler complain:
// The compiler will not like this: the block variable
// and defined block are of different types.
UIColor * (^colorScheme)(Line *) = ^(Line *l, int foo) {
...
};
Change the block back to the working version.
Now you have a method, colorize, that, when executed, will create a block that computes a color given a line. This block is sent via the message transformLineColorsWithBlock: to the instance of TouchDrawView. In TouchDrawView.m, set up TouchDrawView so it is sent the message colorize when the device is shaken by implementing the following code.
- (BOOL)canBecomeFirstResponder
{
return YES;
}
- (void)didMoveToWindow
{
[self becomeFirstResponder];
}
- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event
{
[self colorize];
}
Build and run your application. Draw some lines then shake the device. (If you are on the simulator, choose Shake Gesture from the Hardware menu.)
You may have some warnings about colorize or transformLineColorsWithBlock:. You can ignore these warnings for now; you’ll fix them later. If your application is throwing an exception about unrecognized selectors, make sure you have spelled these two method names correctly in their implementation and use.
So far, blocks look a lot like C function pointers. However, there is one major feature of blocks that separates it from function pointers: it captures variables. In the last section, the block created all of its variables inside its definition. What happens if you use a variable inside a block that wasn’t declared in that block? For example:
- (void)method
{
// A variable created in the scope of this method
// aka, not inside aBlock
int value = 5;
// Create a block with no arguments or return value
void (^aBlock)() = ^(void)
{
// This block simply prints out value,
// a variable declared outside the block
NSLog(@"%d", value);
};
// Call the block
aBlock();
}
This, as you may expect, will print the number 5 to the console. However, so will this:
- (void)method
{
int value = 5;
void (^aBlock)() = ^()
{
NSLog(@"%d", value);
};
// Change value's value before calling block
value = 10;
// Call the block, value = 10 in the scope of this method
// but the block prints 5 when invoked
aBlock();
}
When a block is created, the current values of any variables it references are captured. Any time this block is executed in the future, it uses the captured values of those variables. This applies to more than just primitives – pointers to objects can be captured, too.
Let’s use that knowledge. Whenever the user double-taps the screen, all lines are immediately removed from the screen. It would look nicer if these lines faded off the screen instead. The easiest way to do this is to create a full-screen layer that matches the background color of the TouchDrawView and animate its opacity from transparent to opaque. When the animation completes, all of the lines will be removed from the screen along with the layer, restoring the user interface to its initial state.
To focus on the interesting parts of this exercise, let’s get the animation stuff out of the way. Add QuartzCore.framework to your project. Then, at the top of TouchDrawView.m, import the top-level header from this framework.
#import <QuartzCore/QuartzCore.h>
Change the implementation of clearAll to create a layer and apply a fade-in animation to it. In TouchDrawView.m, replace the following method:
- (void)clearAll
{
// Create a new layer that obscures the whole view
CALayer *fadeLayer = [CALayer layer];
[fadeLayer setBounds:[self bounds]];
[fadeLayer setPosition:
CGPointMake([self bounds].size.width / 2.0,
[self bounds].size.height / 2.0)];
[fadeLayer setBackgroundColor:[[self backgroundColor] CGColor]];
// Add this layer to the layer hierarchy on top of
// the view's layer
[[self layer] addSublayer:fadeLayer];
// Create an animation that fades this layer in over 1 sec.
CABasicAnimation *animation = [CABasicAnimation
animationWithKeyPath:@"opacity"];
[animation setFromValue:[NSNumber numberWithFloat:0]];
[animation setToValue:[NSNumber numberWithFloat:1]];
[animation setDuration:1];
[fadeLayer addAnimation:animation forKey:@"Fade"];
}
Build and run the application. Draw some lines and then double-tap. The screen will fade to white. However, you won’t be able to create any new lines (the fadeLayer is obscuring them and hasn’t been removed), and the Lines in completeLines are still there. You will need to remove the layer from its superlayer and remove the lines from completeLines after the animation completes.
In order to do this, you could give the animation object a delegate. Then, you would implement the method animationDidStop:finished: to remove the layer from the screen along with all of the lines. There are two problems with this. The first is that the delegate method will be in a location other than where this animation was setup. For the purposes of code clarity, it would be nicer if you could somehow define what happens when the animation ends in the same chunk of code where the animation is kicked off.
The other problem is that, in order to remove fadeLayer from the layer hierarchy, you must keep a pointer to it (you have to send it removeFromSuperlayer to take it out of the layer hierarchy). Your only option, without blocks, is to create an instance variable in TouchDrawView that points to this layer. That’s kind of a pain for what is essentially just a temporary object. Fortunately, you can solve both of these problems using a block and the class CATransaction.
In the Chapter 23 chapter, you used CATransaction to turn off implicit animations for any layer modifications occurring within the transaction. Another feature of CATransaction is a completion block. You can pass a block to a CATransaction, and when the animations in the transaction finish, that block will be executed.
Knowing that a block will capture its variables, you will have access to fadeLayer, completeLines, linesInProcess, and even self when the block is executed (a full second after it is created). In TouchDrawView.m’s clearAll method, wrap the animation addition in a transaction and define the completion handler for that transaction.
CABasicAnimation *animation = [CABasicAnimation
animationWithKeyPath:@"opacity"];
[animation setFromValue:[NSNumber numberWithFloat:0]];
[animation setToValue:[NSNumber numberWithFloat:1]];
[animation setDuration:1];
[CATransaction begin];
// Set the completion block of this transaction
// this method requires a block that returns no
// value and accepts no argument: (void (^)(void))
[CATransaction setCompletionBlock:^(void)
{
// When the animation completes, remove
// the fadeLayer from the layer hierarchy
[fadeLayer removeFromSuperlayer];
// Also remove any completed or in process
// lines
[linesInProcess removeAllObjects];
[completeLines removeAllObjects];
// Redisplay the view after lines are removed
[self setNeedsDisplay];
}];
[fadeLayer addAnimation:animation forKey:@"Fade"];
[CATransaction commit];
}
This block will capture fadeLayer, linesInProcess, completeLines, and self. When the block executes, these variables will point at the exact same objects they point at in clearAll.
Build and run the application. Draw some lines and double-tap. The lines will fade out (although we know that a big layer is actually fading in on top of them). After the fade completes, the canvas will be cleared and you can go back to drawing.
How does this actually work? The compiler is smart enough to notice any references to variables when the block is defined – these values are copied into the memory for the block. For pointers to objects that are referenced, the pointer is copied, not the object itself. In cases where the block is kept around for use later, any objects referenced in the block are sent the message retain. In other words, the block takes ownership of those objects to make sure they exist when the block is executed. (See the section called “For the More Curious: Memory Management and Blocks” at the end of this chapter for more details.)
When the block is destroyed, it releases ownership of any objects it captured.
Blocks are so useful that many built-in classes have methods that accept blocks as arguments. One example is NSArray’s enumerateObjectsUsingBlock:. When given a block, this method will loop through the array and perform that block on each element. The block that is applied to each object in the array is of the following form:
void (^)(id obj, NSUInteger idx, BOOL *stop)
The block you define, then, must have these three arguments and not return a value. You will use the enumerateObjectsUsingBlock: to replace the for loop in transformLineColorsWithBlock:. Implement this in TouchDrawView.m.
- (void)transformLineColorsWithBlock:(UIColor * (^)(Line *))colorForLine
{
[completeLines enumerateObjectsUsingBlock:^(id line, NSUInteger idx, BOOL *stop) {
[(Line *)line setColor:colorForLine(line)];
}];
[self setNeedsDisplay];
}
Notice how you are creating another block here for the argument passed to enumerateObjectsUsingBlock:. You don’t necessarily have to declare a block variable to hold a block if you are just passing it in a message because you don’t need to use that block elsewhere. Now, when this method is invoked, the objects in the array are enumerated over by this block. The block gets a reference to the object currently being enumerated (line), the index in the array of that object, and a stop flag that you can set to YES if you want to stop enumerating. For each Line, you call the block passed into the method and then set the color of that line given the result of the block.
Build and run the application again. The behavior should remain the same.
Another form of enumerateObjectsUsingBlock: exists for NSArray named enumerateObjectsWithOptions:usingBlock:. The options you can supply to this method will allow you to enumerate the array in reverse, and more importantly, enumerate the array concurrently. The runtime knows how to divvy up a number of block operations among the different CPU cores when told to.
On current iOS devices, there is only one CPU with one core. For the time being, you will see no performance boost from concurrently running a number of blocks. However, on future iOS devices, there will most likely be more than one core per CPU. Each core will be able to execute a block in parallel, speeding up the enumeration by a factor equal to the number of cores.
NSNotificationCenter also knows how to use blocks. When you have used the notification center before, you would add an observer and selector for a given notification name. Then, you would implement a method with a matching selector somewhere else in your implementation file. As you continue to write code, the method to handle that notification gets moved around, and you end up spending time looking for it when you want to update or check it. Using blocks, you can define the code that gets executed within the same chunk of code you add the notification observer.
You will add an observer that gets notified when the device orientation changes. When this happens, you will execute a block that inverts the color of all the lines. In initWithCoder: of TouchDrawView.m, add the following code.
- (id)initWithCoder:(NSCoder *)aDecoder
{
self = [super initWithCoder:aDecoder];
if (self) {
linesInProcess = [[NSMutableDictionary alloc] init];
completeLines = [[NSMutableArray alloc] init];
[self setMultipleTouchEnabled:YES];
[[UIDevice currentDevice] beginGeneratingDeviceOrientationNotifications];
[[NSNotificationCenter defaultCenter]
addObserverForName:UIDeviceOrientationDidChangeNotification
object:nil
queue:nil
usingBlock: ^(NSNotification * note) {
[self transformLineColorsWithBlock:^(Line *l) {
// Note that extract_invertedColor doesn't
// exist yet, you will implement this soon.
return [[l color] extract_invertedColor];
}];
}];
}
return self;
}
Whenever TouchDrawView is notified of an orientation change, it executes the block passed as the argument paired with usingBlock:. The argument to this block must be an NSNotification because that is what the method addObserverForName:object:queue:usingBlock: expects.
This block invokes the method transformLineColorsWithBlock: with another block. The coloring block here is defined inline (there is no variable to hold it), and it will return the inverted value of the current color of the line.
However, there is no extract_invertedColor for UIColor because you’ve yet to define it.