NSNotificationCenter with blocks considered harmful
sealedabstract.com
NSNotificationCenter with blocks considered harmful
1–10 of 39 posts
Re: NSNotificationCenter with blocks considered harmful
#2This really applies equally to any block that captures self. Blocks are, IMHO, the one place where ARC really falls down versus garbage-collection.
Re: NSNotificationCenter with blocks considered harmful
#3This really applies equally to any block that captures self. Blocks are, IMHO, the one place where ARC really falls down versus garbage-collection.
Yes, it's just a retain cycle. Self retains block, block retains self.
The only thing that makes this case confusing is that self only holds the block implicitly (via the notification center instead of any obvious ivar). Otherwise it's a design pattern that every reference counted language user must understand to avoid memory leaks. Weak references to self in blocks are a very common design pattern that all Objective-C programmers should know.
Re: NSNotificationCenter with blocks considered harmful
#4There's nothing really magical about this – don't cause retain cycles, everyone knows __block semantics changed with ARC, keep the returned value from the block-based NSNotificationCenter method, etc. Standard stuff.
The only thing that surprised me was the reference cycle in NSAssert. Then again, given Apple's poor regard for TDD, that shouldn't surprise me.
Re: NSNotificationCenter with blocks considered harmful
#5There's nothing really magical about this – don't cause retain cycles, everyone knows __block semantics changed with ARC, keep the returned value from the block-based NSNotificationCenter method, etc. Standard stuff. The only thing that surprised me was the reference cycle in NSAssert. Then again, given Apple's poor regard for TDD, that shouldn't surprise me.
By the way, you can prevent the retain cycle in NSAssert using libextobjc's @weakify and @strongify macros.
Re: NSNotificationCenter with blocks considered harmful
#6A little off topic:
If you over-do it then NSNotifications easily can become distributed goto. Once I had to add features to a Mac application that made heavy (ab)use of NSNotifications. Following code paths was a nightmare.
I tend to prefer the delegate pattern because there the relationships between objects are clear. Even if it means more work (creating glue code) - your sanity is worth it.
Re: NSNotificationCenter with blocks considered harmful
#7Nice post! Are you always testing Apple's implementation details in your TDD? To me it seems the actual notification submission shouldn't be tested, only that it was called with the proper value?
Just a heads up though: The code snippet were hard to read because of the indentation. May I suggest
cleanupObj = [[NSNotificationCenter defaultCenter]
addObserverForName:notificationName
object:nil
queue:nil
usingBlock:^(NSNotification *note) {
// Code!
}];
Re: NSNotificationCenter with blocks considered harmful
#8This really applies equally to any block that captures self. Blocks are, IMHO, the one place where ARC really falls down versus garbage-collection.
Yes, it's just a retain cycle. Self retains block, block retains self. The only thing that makes this case confusing is that self only holds the block implicitly (via the notification center instead of any obvious ivar). Otherwise it's a design pattern that every reference counted language user must understand to avoid memory leaks. Weak references to self in blocks are a very common design pattern that all Objective…
Not to mention that using 'self' in a block is just not a good idea to start with. Conceptually a block is not a method, so it doesn't have a well-defined self. Instead we are relying on the lexical scope capturing of blocks. The thing is, the documentation is very clear about what happens when you access self in a block[1]:
"When a block is copied, it creates strong references to object variables used within the block. If you use a block within the implementation of a method:
If you access an instance variable by reference, a strong reference is made to self;
If you access an instance variable by value, a strong reference is made to the variable."
Drew also gets bitten by NSAssert using self. I would suggest that it is NSAssert that is doing something dodgy here - it's trying to have an implicit self, as though it was a method, when it most definately isn't a method - and Drew just got bitten by the impedence mismatch. Macros - just say no.
Re: NSNotificationCenter with blocks considered harmful
#9There's nothing really magical about this – don't cause retain cycles, everyone knows __block semantics changed with ARC, keep the returned value from the block-based NSNotificationCenter method, etc. Standard stuff. The only thing that surprised me was the reference cycle in NSAssert. Then again, given Apple's poor regard for TDD, that shouldn't surprise me.
By the way, you can prevent the retain cycle in NSAssert using libextobjc's @weakify and @strongify macros.
Indeed, the NSAssert cycle surprised me too.
libextobj is great.
Re: NSNotificationCenter with blocks considered harmful
#10On a related note, I've run into a similar problem in C++, but opposite effect. A lambda won't keep my object alive if I try to capture a shared_ptr member, because C++ lambdas, similarly to blocks, by default capture implicit reference to "this", rather than individual instance variables.