[[UIColor redColor] setStroke];
CGContextSaveGState(UIGraphicsGetCurrentContext());
[[UIColor blackColor] setStroke];
CGContextRestoreGState(UIGraphicsGetCurrentContext());
UIRectFill(CGRectMake(10, 10, 100, 100)); // Red

The calls to setStroke should be setFill. Thanks to Tan Yuguo for finding this.

The syntax for creating a new NSDictionary was written as

 
NSDictionary *dict = @[@"key1":@"value1", @"key2":@"value2", @"key2":@"value2"]

The correct syntax is

 
NSDictionary *dict = @{
@"key1":@"value1", 
@"key2":@"value2", 
@"key3":@"value3"
}

Curly braces are used for creating dictionaries and square brackets are used for creating arrays.

In Object Subscripting section,
when you access a element in an array using a subscript, you get a NSNumber

So the correct code that compiles without a warning is as below.

NSArray *array = @[@1, @2, @3, @4, @5]
NSNumber *elementAt3 = array[3];

Thanks to Luca Bernardi for pointing this out.

–
Mugunth

enum {
    kCCPRFHmacAlgSHA1 = 1,
    kCCPRFHmacAlgSHA224 = 2,
    kCCPRFHmacAlgSHA256 = 3,
    kCCPRFHmacAlgSHA384 = 4,
    kCCPRFHmacAlgSHA512 = 5,
};

SHA224-SAH512 are just specific sizes of SHA-2.

Note that while SHA-1 is “broken,” the issues don’t impact the security of HMAC (let alone PBKDF2). SHA-1 still serves this function perfectly well. Even MD5 is still fine in this use. Intuitively, PBKDF2 doesn’t need a collision-resistant hash function at all because its goal is to waste time in a way that is difficult to short-cut with parallelization. (On the security proof side, HMAC does not require a strongly collision-resistent hash function in order to remain a PRF, and PBKDF2 only requires a PRF to maintain its security. See Mihir Bellare’s paper for details.)

As good security housekeeping, I would recommend that new implementations use SHA256 to help move the world from SHA-1 to SHA-2 a little faster. But I wouldn’t recommend expending much effort to retrofit old implementations at this time.

I haven’t yet done any timing analysis to determine a good number of PBKDF2 iterations for SHA256. SHA1 needs 10k iterations to give 80ms on a iPhone 4. ~100ms is a pretty good target IMO.

Thanks to Daniel McGloin for pointing this issue out to me.

http://blog.mugunthkumar.com/products/ios-6-programming-pushing-the-limits/

I started to have doubts, though, that CGLayer was always a great win. What if your layers were too large to store in GPU textures? CGLayer is advertised for use as a “stamp” that you repeatedly draw. Moving data to and from the GPU is expensive. Maybe CGLayer doesn’t make sense unless you draw it a certain number of times. The docs give no guidance on this. So I asked the Core Graphics team “When should I be using CGLayer?”

“Never.”

… ??? Never? But for stamping right?

Never.

So we talked some more. It appears that CGLayer was one of those things that sounded great on paper, but just doesn’t always work in practice. Sometimes it’s faster. Sometimes its slower. There’s no easy rule for when it’s going to be faster. Over time it seems they’ve quietly abandoned it without actually deprecating it. I’ve asked that the docs be updated to match Apple’s current recommendation. The CGLayer Reference hasn’t been updated since 2006.

The recommendation I received was to use CGBitmapContext or CALayer for stamping. For the specific example given on pages 131-132, CATextLayer would probably be the best tool. Remember that you can easily clone a CALayer using initWithLayer:.

In the example code, the view retains an infinitely-repeating NSTimer, for which the view is the target. This is a retain loop, since NSTimer retains its target. There are various ways to fix this, but my favorite is to use a GCD timer with a weak reference to self:

__weak id weakSelf = self;
double delayInSeconds = 0.25;
_timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0,
                                dispatch_get_main_queue());
dispatch_source_set_timer(_timer, dispatch_walltime(NULL, 0), 
                          (unsigned)(delayInSeconds * NSEC_PER_SEC), 0);
dispatch_source_set_event_handler(_timer, ^{
  [weakSelf updateValues];
});
dispatch_resume(_timer);

It’s a little verbose, and you often may want to wrap it up in a helper function. But it’s nicely self-contained. The sample code has been updated.

Thanks to Johan Kool (@johankool) for pointing out the original retain loop.

The code in the book is

for(NSString *path in cachedItems) {
[[NSFileManager defaultManager] removeItemAtPath:path error:nil];
}

The path variable in this code is just the file name and not the full path and as such, doesn’t delete the cached data file. Thanks to Brian for pointing this out.

You should use the following code instead.

for(NSString *path in cachedItems) {
NSString *fullPath = [[self cacheDirectory] stringByAppendingPathComponent:path];
[[NSFileManager defaultManager] removeItemAtPath:fullPath error:nil];
}

–
Mugunth

The first call to removeObsever:forKeyPath: removes both previous observers. The second call will crash. This may sound contrived, but consider the case where both you and your superclass are observing the same object’s property. There is no easy way to implement that without special knowledge about your superclass’s implementation. If your superclass is a UIKit class, you don’t have the source code to even find out what it’s observing. You just have to hope it doesn’t collide with you now or in the future.

There are two problems here. First, there’s a typo on the first line. That should be removeObserver:forKeyPath: (thanks to Sean Whitsell for catching my missing “r”).

Second, and more critical, this paragraph isn’t true. If you and your superclass have both observed this object, you may remove the wrong observation (i.e. the wrong context may be removed), but it won’t crash. You can (and must) balance an equal number of calls to addObserver:... and removeObserver:.... I have no idea why I made this mistake. Thanks to Ben Shanfelder for pointing it out to me.

As a side note, iOS 5 finally adds removeObserver:forKeyPath:context:.

+ (id)sharedManager
{
  static id sharedManager;
  static dispatch_once_t once;
  dispatch_once(&once, ^{
    sharedManager = [[self alloc] init];
  });
  return sharedManager;
}

While I believe avoiding a leading underscore was valuable in the past for the other reasons listed (particularly avoiding some KVC magic), with the move to auto-synthesized ivars this recommendation has become more trouble than its worth. In the future, our recommendation is to follow Xcode’s lead: readwrite ivars should have a leading underscore. readonly ivars should have a leading double-underscore. This double-underscore also fixes the KVC concern, so it wins in several ways.

Thanks to Mark Dalrymple (@borkware) for pointing out this issue.