For example, the following Swift snippet will compile perfectly:
NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("itemAdded:"),
name: MyNotificationItemAdded, object: nil)
even though at runtime it will fail unless self has a method named itemAdded that takes exactly one parameter (leaving off that last colon in the selector will turn this line into a no-op). Plus, this method gives you no way to take advantages of Swift's closures, which would allow the observer to access local variables in the method that adds the observer and would eliminate the need to create a dedicated method to handle the event.
A better way to do this is to use blocks. And NSNotificationCenter does include a block-based API:
NSNotificationCenter.defaultCenter().addObserverForName(MyNotificationItemAdded, object: nil, queue: nil) { note in
// ...
}
This is much nicer, especially with Swift's trailing closure syntax. There are no method names to be looked up at runtime, we can refer to local variables in the method that registered the observer and we can perform small bits of logic in reaction to events without having to create and name dedicated methods.
The catch comes in resource management. It's very important that an object remove its event observers when it's deallocated, or else NSNotificationCenter will try to invoke methods on invalid pointers.
The traditional target-action method has the one advantage that we can easily handle this requirement with a single call in deinit:
deinit {
NSNotificationCenter.defaultCenter().removeObserver(self)
}
With the block API, however, since there is no explicit target object, each call to addObserverForName returns "an opaque object to act as observer." So your observer class would need to track all of these objects and then remove them all from the notification center in deinit, which is a pain.
In fact, the hassle of having to do bookkeeping on the observer objects almost cancels out the convenience of using the block API. Frustrated by this situation, I sat down and created a simple helper class, NotificationManager:
class NotificationManager {
private var observerTokens: [AnyObject] = []
deinit {
deregisterAll()
}
func deregisterAll() {
for token in observerTokens {
NSNotificationCenter.defaultCenter().removeObserver(token)
}
observerTokens = []
}
func registerObserver(name: String, block: (NSNotification -> Void)) {
let newToken = NSNotificationCenter.defaultCenter().addObserverForName(name, object: nil, queue: nil, usingBlock: block)
observerTokens.append(newToken)
}
func registerObserver(name: String, forObject object: AnyObject, block: (NSNotification -> Void)) {
let newToken = NSNotificationCenter.defaultCenter().addObserverForName(name, object: object, queue: nil, usingBlock: block)
observerTokens.append(newToken)
}
}
A client of this class can simply keep a member variable of type NotificationManager and use it to register its observers. When the parent class is deallocated, the deinit method will automatically be called on its NotificationManager member variable, and its observers will be properly disposed of:
class MyController: UIViewController {
private let notificationManager = NotificationManager()
override init() {
notificationManager.registerObserver(MyNotificationItemAdded) { note in
println("item added!")
}
super.init()
}
required init(coder: NSCoder) {
fatalError("decoding not implemented")
}
}
When the MyController instance is deallocated, its NotificationManager member variable will be automatically deallocated, triggering the call to deregisterAll that will remove the dead objects from NSNotificationCenter.
Another benefit of using my own wrapper around NSNotificationCenter is that I can add useful functionality, like group observers: an observer that's triggered when any one of a group of notifications are posted:
struct NotificationGroup {
let entries: [String]
init(_ newEntries: String...) {
entries = newEntries
}
}
extension NotificationManager {
func registerGroupObserver(group: NotificationGroup, block: (NSNotification -> ()?)) {
for name in group.entries {
registerObserver(name, block: block)
}
}
}
This can be a great way to easily set up an event handler to run when, for example, an item is changed in any way at all:
let MyNotificationItemsChanged = NotificationGroup(
MyNotificationItemAdded,
MyNotificationItemDeleted,
MyNotificationItemMoved,
MyNotificationItemEdited
)
notificationManager.registerGroupObserver(MyNotificationItemsChanged) { note in
// ...
}
What is the difference
ReplyDelete"block(note)"
and
"block(note)
()" ??
This is an artifact of an earlier beta of Swift. I've updated the code so that the blocks simply return "Void" - those extra unit values are no longer necessary. Thanks for bringing this to my attention!
DeleteAwesome stuff :) Have you thought about making a cocoapod out of this?
ReplyDeleteI always prefer importing and giving credit for code written by others instead of copy-pasting and commiting in my own name.
Quick comment about the code:
Trailing closures are a nice feature, but IMHO not the right fit for this. I think it would be better style to pass the block argument on directly, instead of wrapping it in another block:
let newToken = NSNotificationCenter.defaultCenter().addObserverForName(name, object: nil, queue: nil, usingBlock: block)
Thanks a lot for sharing this!
Great suggestion - thanks!
DeleteAnyone implementing this should be aware that referencing self will cause a retain cycle in the handler unless it's marked as weak.
ReplyDeleteThat's standard behavior for a closure, not specific to my code.
Delete@Solomon, yep, I just encountered this issue and came back here to comment, but you beat me to it :). As you mention, I had to add [unowned self] to the closure declaration to avoid leaking my viewController.
ReplyDeleteThat's standard behavior for a closure, not specific to my code.
DeleteThis comment has been removed by the author.
ReplyDeleteWhy the implicitly unwrapped optionals? I'm guessing just a artifact from betas that can now be removed. I removed and it seems to work but just wanted to check to see if you thought of something I had not. (I think this will even be disallowed in Swift 3)
ReplyDeleteHi Lucas,
DeleteThat's correct - this was written for a version of Swift that's almost a year old now. Thanks for pointing this out - I just updated the post to match the code I'm actually using these days.