How to improve NSNotification

In iOS there are different ways to pass data. There is the delegate pattern and then there is NSNotification. The delegate pattern makes the reference from one object to another clear. This is helpful for debugging, because it is much easier to discover who is calling the delegate method.

NSNotification on the other hand is a little more magical. One source can broadcast a message to one or more listeners. There is no direct reference back to the broadcaster, which can make debugging more challenging.

What can we do to make NSNotification much better?

What super powers can Swift bestow?

Think for a moment, is NSNotification actually magical? If you had to create one on your own, do you think you would produce anything as sophisticated as NSNotification? These questions led me to producing my own and surprisingly, there is no surpise. When a magic trick is revealed the magic doesn’t seem like magic any longer.

What I created is a short framework — Its less then 50 lines of code — that I call SwiftyNotification.

SwiftyNotification improves on the goal that NSNotification had by:

1. Removing the stringy API.
2. Using Generics to provide useful type information.
3. Providing 2-way communication (No mystery caller)

Take a look a this framework in action!

Let’s break it down:

1. I declare a SwiftyNotification instance and provide 3 types: String, String, and Int. The first two will be used as the key and value types respectively for the info dictionary and the last one is the return type of the response (more on this later).
2. In order for the notification to be heard, someone needs to listen. I call that someone a subscriber and that subscriber provides a closure that will be called when the notification is heard.
3. Printing the info dictionary of type [String:String] described in point 1
4. n is an inout variable that can be set. This value can be used by the broadcaster of the notification. Setting this value is optional.
5. The broadcaster can send an info dictionary. In this case I am sending [“hello”:”world”]. When the broadcastNotification(with:) method finishes it returns an array of responses. In our example when the n variable is set, that value is added as one of the responses.

NSNotification is great for sending one message to multiple listeners, but is isn’t very good at getting back a response. SwiftyNotification can also send one message (called broadcasts) to multiple listeners (called subscribers), but unlike NSNotification, each subscriber has the privledge to reply back.

The best traits of delegate and NSNotification have become one.

While a SwiftyNotification object is good by itself, where is it suppose to live? You could add it to your UIViewController subclass and use it appropriately, but there is another way. What can make it even better is a hub to provide a place for each of the instances to live in.

1. LOL, the hub is empty! The magic box you thought was filled (with a rabbit) was actually, well, nothing. Those magicians sure are clever! SwiftyNotificationCenter is analogous to NSNotificationCenter.
2. Elsewhere in your project, we can add all of our SwiftyNotification instances. This provides a globally accessible way to broadcast and subscribe.

This endevor to unravel the mysteries of NSNotification proved quite fruitful. I’ll never look at NSNotification again. I sincerely doubt the real implementation of NSNotification center is any more complex then SwiftyNotification; if it is then perhaps swift really is the future.

Thank you for taking the time to read until the very end! The full implementation as well as a sample project can be found on GitHub. I hope this artical provided some refreshing ideas and I look forward to hearing from you, the readers. If you enjoyed the article, leave a like (❤️), it will make me more enthusiastic about writing the next article.