However, I have to dismiss a large part of the article simply due to the fact that you don’t remove observers in dealloc.

That’s a no-no. Why IN THE WORLD would you rely on an object being deallocated to do that? You want to have some reliably in and out for adding/removing observers – viewWillAppear and viewWillDisappear for example, or if it’s a non-view object, then add an observer once and just keep it around forever or as long as your object is around.

Introducing a dependency on an object being collected is basically hard-wiring your logic to the entire rest of the program. Who knows what will be – legitimately – holding on to that object? Who can predict?

Relying on dealloc is basically the equivalent of a goto: statement, or relying on a global variable. Don’t do it.

cheers thanks 😉

Yeah, I’ve noticed!

Had to go into my code base and dig this one up. I added this kind of hacky piece of code and call it manually to make the damned AVCamCaptureManager dealloc:

(void) removeLeakyObservers
{
NSNotificationCenter *notificationCenter = [NSNotificationCenter defaultCenter];
[notificationCenter removeObserver:[self deviceConnectedObserver]];
[notificationCenter removeObserver:[self deviceDisconnectedObserver]];
}

And thanks for this dive into the (at least for me) good old weakSelf & strongSelf dance that came as a little nasty side effect of ARC’s new way of handling variables defined as __block. Though the ARC documentation does describe (with examples) this well, it is a nasty little change in the way things worked earlier.

I wonder why LLVM automatically create weak references to ‘self’ within a block by default. Not sure if it is too difficult for LLVM folks to bring it in.

Because that would be at least as wrong. All Objective-C object references are captured strongly, that’s the API contract. If self was special cased to be weak, this would break:

[[thing sendRequest:r withCallback:^(id value) {
[self parseValue:value];
  [self save];
}];

Since self is captured strongly, we’re guaranteed to live at least as long as this request, even if all other references to the self object have been released except this block, so that we can definitely handle the response unless the request is explicitly cancelled.

Special casing self to be weak wouldn’t help in this situation, either:

id manager = …;
[manager onFailure:^{
[manager cleanup];
}];

Retain cycle!

So maybe we can go so far as to say all objc values should be captured weakly?

NSArray *array = @[@1];
[thing sendRequest:r withCallback:^(id response){
[response doSomethingWithNonNilObject:array];
}];

Nope, crash.

So, the current behavior of strong capture of every Objective-C object is the sanest solution, but is problematic since we don’t have garbage collection to take care of cycles. Harsh life as a programmer. We have to learn our tools very thoroughly and learn how to handle these cases correctly instead. ARC made life easier but it’s not a panacea.

You have to create a strong variable within the block that’s a copy of the weak reference, and dereference that.

__weak __typeof(self) weakSelf = self;
[something doSomething:^{
__strong __typeof(weakSelf) strongSelf = weakSelf;
if(strongSelf)
strongSelf->_ivar++;
}];

Also, this whole blog article is rather over the top. Yes, memory management in blocks is difficult. That’s the price to pay for not having a garbage collector. That doesn’t mean you can just ignore the rules, and it doesn’t mean that block-using APIs are bad. It just means you don’t know how to use blocks. (and I know you don’t know how to use block because you made an instance variable __block. That doesn’t even mean anything. And you didn’t do what the documentation said — it implied that you should’ve made the reference to self weak, not the reference to the ivar.)

It’s also worth to note that if you don’t unregister from notifications with the target-action API, you’ll crash. There’s plenty of code using that API incorrectly too, and that’s just as bad.

The rest of this is terrifying.

Thanks
Shripada

Since I first started iOS programming, I’ve been using ZAssert
http://www.cimgf.com/2010/05/02/my-current-prefix-pch-file/ by Marcus Zarra. It doesn’t reference self.

I would consider the real bug to be on NSAssert, which should not reference self. Or be documented to not be used in a block.

If you do weakSelf = nil; inside the block after you are done it will break the retain cycle. You have to be careful if you use dispatch_asyncs that reference the weakSelf, make sure to nil it out inside the dispatch and not right after it.

Apple sample code is generally of low quality and should not be trusted.

Thank you for the warning about NSAssert, most of us did not see that one coming…