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.

__block typeof(self) myself = self;
... ^{ // block that uses myself } ...


As noted on page 183, “if you reference an object inside of a block, the block automatically retains that object. If you reference self, a retain loop is created because self retains queue, which retains the block.”

This was correct for manual reference counting, but is not sufficient for ARC. With ARC, you need to add the __weak specifier as well, or you need to set the value to nil inside the block. As noted in the Transitioning to ARC Release Notes:

In manual reference counting mode, __block id x; has the effect of not retaining x. In ARC mode, __block id x; defaults to retaining x (just like all other values). To get the manual reference counting mode behavior under ARC, you could use __unsafe_unretained __block id x;. As the name __unsafe_unretained implies, however, having a non-retained variable is dangerous (because it can dangle) and is therefore discouraged. Two better options are to either use __weak (if you don’t need to support iOS 4 or OS X v10.6), or set the __block value to nil to break the retain cycle.

Thanks to Crispin Bennett for finding this error.

I wrote MKNetworkKit so that it would be super easy for developers to migrate from ASIHttpRequest. It’s feature rich, ARC only code based on NSURLConnection and supports pretty much everything that ASIHttpRequest supported.

MKNetworkKit also embraces the idea of writing cleaner view controller code that I discussed in the above mentioned chapters, 10 and 17.

You can read more about MKNetworkKit on the following blog posts.

Introducing MKNetworkKit

Advanced Networking with MKNetworkKit

Image Cache and Loading Thumbnails using MKNetworkKit

–

Mugunth

You’d think that NSURLCache would handle this for you, but it’s much more complicated than that. NSURLCache doesn’t cache everything you’d think it would. Sometimes this is because of Apple’s decisions in order to save space. Just as often, however, it’s because the HTTP caching rules explicitly prevent caching a particular resource.