NSNotificationCenter on Andrew Bancroft

NSNotificationCenter vs Delegation – An Analysis

Thu, 05 Feb 2015 13:00:26 +0000

In Fundamentals of NSNotificationCenter in Swift, a commenter asked me to elaborate on a response I’d given to a dialog going on below the blog post. I had stated:

If you need a more structured environment around your [instance]-to-[instance] communication, delegates … are probably a better choice [than NSNotificationCenter].

I’ve been thinking for some time since I responded with that comment. What do I mean when I say “if you need a more structured environment”… What does that even look like? Why are delegates a better choice when I need such “structure”?

Structured environment? What’s that?

“Structured environment” may be a bit vague. Here’s what I was thinking when I wrote it: At the time of the comment, I was imagining what a solution implemented with NSNotificationCenter, and a solution implemented with a delegate look like….

Questions

First, I tried to step into the role of each instance, and in a role-playing sort of way, ask:

As a notifier / delegator instance: “What do I expect to happen as I send this notification or invoke this method on my delegate? What clues from my execution context inform that expectation?”
As a notifier / delegator instance: “What control do I appear to have over the sequence of events that happen as a result of sending this notification or invoking this method on my delegate?”
As a listener / delegate instance: “What impact does acting on this notification or executing this delegate method have on the system as a whole?”

And then shifting out of the role-playing mentality, stepping back and asking a question of clarity:

“Which strategy seems to provide greater clarity and structure to the entire application environment?”
“Which strategy would most help another developer who might see this code and try to trace the logic and impact of the code?”

The measurement of a more or less “structured environment”, then, would be influenced by the answers to the questions of expectations, perceived control, impact, and clarity.

Let’s explore some of those answers from the perspective of each communication strategy, starting with NSNotificationCenter.

Answers from the NSNotificationCenter Perspective

With NSNotificationCenter as an instance-to-instance communication strategy, we have the following environment:

Note that Listeners 1 to n may or may not exist. The graphic is assuming that 1+ Listener instances have “tuned in” to a particular notification key.

Expectations

What do I expect to happen? Well, the most reasonable thing I (as a “notifier instance”) can expect is for some other “listener instance” somewhere to tune in to the notification key I’m broadcasting. I have no way of knowing what would happen after that. It’s up to the listener to do something intelligent with the notification that [x event] occurred. I, as a notifier, can expect nothing more.

Perceived Control

It appears that I, as a notifier, have no control over the sequence of events that would occur as a result of my broadcast. That’s by design – the interaction between me and any listener is weak at best.

This can be a fantastic thing! There’s freedom in saying “Hey! This happened!” and then being done. But it’s also “less structured”, as I’m terming it.

Impact

The impact on the system as a whole has the potential to be significant. With NSNotificationCenter, it depends on how many listener instances there are and what each of them does in response to the notification. One could design the system to localize the impacts to the context of the listening instance. I’ve heard of and seen ugly situations that trigger cascading effects that make deciphering the impact of a notification much harder.

Clarity

We lose a good deal of clarity when heavy usage of NSNotificationCenter occurs in an application. There may be appropriate times to use NSNotificationCenter in your app. Keep in mind that it becomes much more difficult to sort out various interactions when more and more listener instances are responding a notification. Trying to reason about how the system as a whole arrived at its current state isn’t as easy when NSNotificationCenter enters the picture. Other developers with less knowledge of the app as a whole would suffer from this loss of clarity.

Answers from the Delegate Perspective

With a delegate, we have a significantly different strategy at hand. To put it before us:

Expectations

The delegation strategy deals with protocols. Protocols by nature give us reliable a way to…

Count on the implementation of needed/expected behavior, and
Predict what the behavior of the adopter of that protocol will be. By practicing good naming conventions, I, as a delegator, find it reasonable to expect that invoking a method on my delegate will do whatever the name of that method implies.

Perceived Control

It would appear that as a delegator, I can control the sequence of events that need to take place by choosing when to invoke methods on my delegate. A strategy using NSNotificationCenter can only send out a notification into the ether, and hope that something acts on it. A strategy using delegation has a delegate which adopts a protocol. Every method is at my disposal to call in whatever order makes sense.

Impact

The impact on the system as a whole still has the potential to be significant. Since there’s one-to-one communication going on between a delegator and its delegate, the determining factor on how broad the impact is tends to lean on the design of the system as a whole. Design patterns that minimize or eliminate global state reduce this potentially broad impact.

One advantage that the delegation pattern has is that the delegate conforms to a protocol and a protocol, along with its specified methods, have names. However small that knowledge is, it could give us clues about what impact of executing the delegate’s methods might have on the system.

Clarity

With the advantage of dealing with intelligently named protocols and clearly outlined method names, the delegation strategy would win the battle of clarity in my opinion. I can look at the delegator instance and say, “When execution of this instance’s logic gets to this point, reliance on the delegate kicks in and [x, y, and z] happens. I can jump over to the delegate’s implementation and say, “[x] does this, [y] does that, and [z] does this other thing.” Other developers with less knowledge of the app as a whole would enjoy this added clarity quite readily.

In Summary

Here, I’ve analyzed NSNotificationCenter, side by side with the delegation pattern, by imagining myself in the role of each instance (notifier, listener | delegator, delegate). I assessed each strategy in terms of expectations, perceived control, impact, and clarity, attempting to shed light on what it means for an environment to be “more structured” or “less structured”. My hope was to shed light on my use of the term “structured environment”, and to share my thoughts on some of the implications of using each strategy.

Fundamentals of NSNotificationCenter in Swift

Wed, 08 Oct 2014 18:27:47 +0000

Updated on September 19, 2016 – Xcode 8 & Swift 3.0

The goal of this post is to help you grasp the fundamentals of using NSNotificationCenter in your Swift iOS app. The topic isn’t necessarily new, and there’s no difference except syntax between Objective-C and Swift implementations involving NSNotificationCenter. Even still, I’m hoping to add to the understanding of this useful tool by giving a fully-working example on GitHub (Swift 2.3 and Swift 3.0), and by sharing the insight that’s clicked in my own brain as I explain the example.

Note: Code in the main article below is written in Swift 3.0, but code examples for Swift 2.3 are found in the example project.

First things first: What is this thing?

When I first heard NSNotificationCenter, I thought “push notifications”. However, NSNotificationCenter has nothing to do with sending or receiving push notifications in iOS. Rather, it is a communication tool internal to your app. It provides a way for one instance of a class/struct to notify one or more other class/struct instances about something. The goal in doing this is to enable those 1+ other class or struct instances to take appropriate action based the communication they receive. An common analogy comes to mind: think “radio tower”. NSNotificationCenter is the central hub that acts as a broadcaster of notifications. If that still seems vague, hang tight – seeing the example below should help it all come together for you.

Should I use it?

Before diving into the basic workflow, it’s worth asking, “Should I use NSNotificationCenter, or is there some other option that’s more appropriate for my app’s internal communication needs?”

It is often the case that there is more than one way to solve a problem in software development, and it’s no different with NSNotificationCenter. There is more than one way to accomplish instance-to-instance communication at run-time. I’ve written about two such forms of communication in my post titled NSNotificationCenter vs Delegation – An Analysis. It may be worth reading up on, just to make sure you’re using the right tool for the right kind of communication.

Basic Workflow

NSNotificationCenter.default is at the center of it all when it comes to this discussion.

The basic workflow of using NSNotificationCenter goes something like this:

Since `NSNotificationCenter` is in the business of broadcasting notifications, the first thing to do is to specify a way to uniquely identify a notification. This is most easily accomplished by defining a constant string value (using `let` syntax in Swift) at a globally-visible scope. The string constant you define here will serve as a “notification key”. If you have several notification keys that you need to define, perhaps creating a new .swift file called “NSNotificationCenterKeys.swift” is a clean way to do this.
Steps 2 and 3 of the workflow go hand-in-hand. Without implementing the one, implementing the other doesn’t make much sense… Step 2 is to post a notification to `NSNotificationCenter.default` identified by the key that was created in step 1. In radio terms, the class or struct instance desiring to post a notification asks the default notification center to broadcast the notification key defined in step 1… this class or struct instance chooses the right situations to request that the notification key be sent out based on business logic specific to the project’s requirements.
Step 3 is to set up 1+ class or struct instances to be listeners, or more properly, observers of a particular notification. Such an observer will be able to tell that it’s “heard” the notification, because it will be “listening for” a notification that uses the same key that was created in step 1, which is the key used in step 2 to post the notification. In radio terms, the listener is tuned in to the default notification center’s station that’s identified by that special key defined in step 1 and posted in step 2. So you see now why steps 2 and 3 go hand-in-hand. With no posts to the notification center on that station, tuning in will do no good. Likewise, posting a notification but having no listeners accomplishes nothing.
Finally, what should the observing instance do once it’s detected the notification? Well, when signing up to be an observer, the instance must also specify the name of a function that will be called upon receipt of the notification it’s listening for. Whatever action or routine is appropriate to perform at that time is what that function’s implementation should contain.

Visualizing NSNotificationCenter by Example

If you’re like me, you need less talk and more example, so I’ve created a simple Xcode project that you can grab over at GitHub (Swift 2.3 and Swift 3.0). Running the project will allow you to click through a series of tabs in a tab view controller, post a notification, and see the results. It looks much like this:

Working back through the basic workflow with this example you can find the following key aspects of implementing a NSNotificationCenter solution (lines of code to pay special attention to will be highlighted).

Steps 1 and 2:

I’ve chosen my FirstViewController class to be the one that defines the global constant with a unique notification key and tells the default notification center to post that notification when the “Notify!” button is tapped:

 1// 1. Globally define a "special notification key" constant that can be broadcast / tuned in to...
 2let mySpecialNotificationKey = "com.andrewcbancroft.specialNotificationKey"
 3
 4class FirstViewController: UIViewController {
 5    @IBOutlet weak var sentNotificationLabel: UILabel!
 6    
 7    override func viewDidLoad() {
 8        super.viewDidLoad()
 9        NotificationCenter.default.addObserver(self, selector: #selector(FirstViewController.updateNotificationSentLabel), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
10    }
11
12    // 2. Post notification using "special notification key"
13    @IBAction func notify() {
14        NotificationCenter.default.post(name: Notification.Name(rawValue: mySpecialNotificationKey), object: self)
15    }
16    
17    func updateNotificationSentLabel() {
18        self.sentNotificationLabel.text = "Notification sent!"
19    }
20}

Steps 3 and 4:

Both of these steps are implemented in very similar ways in my SecondViewController and ThirdViewController classes. The code should speak for itself:

 1class SecondViewController: UIViewController {
 2    @IBOutlet weak var notificationLabel: UILabel!
 3    
 4    override func viewDidLoad() {
 5        super.viewDidLoad()
 6
 7        // 3.  Observe (listen for) "special notification key"
 8        NotificationCenter.default.addObserver(self, selector: #selector(SecondViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
 9    }
10
11    // 4.  Implement function to act on that notification
12    // The name of this function must match the selector argument you specified when you called addObserver()
13    func actOnSpecialNotification() {
14        self.notificationLabel.text = "I heard the notification!"
15    }
16}
17
18
19class ThirdViewController: UIViewController {
20    @IBOutlet weak var notificationLabel: UILabel!
21    
22    override func viewDidLoad() {
23        super.viewDidLoad()
24        NotificationCenter.default.addObserver(self, selector: #selector(ThirdViewController.actOnSpecialNotification), name: NSNotification.Name(rawValue: mySpecialNotificationKey), object: nil)
25    }
26    
27    func actOnSpecialNotification() {
28        self.notificationLabel.text = "I heard the notification, too!"
29    }
30}

Finally, to reiterate the explanation in visual form and for easy reference, I’ve annotated a screen shot taken from the project’s code:

Removing an observer

One final requirement for working with NSNotificationCenter is to remove an observer when it no longer needs to listen for notifications. When might this situation arise?

When the observer is no longer referenced and thus deallocated from memory, it should tell the default notification center that it can be removed
When some condition occurs in your application that renders it no longer relevant for an instance to listen for notifications

The first situation is the most common, and is for sure the scenario that we want to protect against, so that the default notification center doesn’t continue to manage observers that are no longer capable of actively listening. To satisfy the requirement of removing an observer when an instance is deallocated, we could provide something like the following deinit method:

1deinit {
2    NSNotificationCenter.default.removeObserver(self)
3}

For the second bullet point, you can simply write the same line of code that’s highlighted in the above snippet, wherever it makes sense for you to tell the default notification center when it’s appropriate to stop sending messages to the instance in question.

Summary

NSNotificationCenter is particularly useful when there are multiple class or struct instances that need to take action based on something that happens elsewhere in your application. For this type of scenario, NSNotificationCenter can be a great tool to wield as you develop apps in Swift for iOS.