Receiving a Notification

To register to receive notifications, you send one of two messages to the notification center.

let mp = MPMusicPlayerController.systemMusicPlayer
mp.beginGeneratingPlaybackNotifications()

NotificationCenter.default.addObserver(self,
    selector: #selector(nowPlayingItemChanged),
    name: .MPMusicPlayerControllerNowPlayingItemDidChange,
    object: nil)

@objc func nowPlayingItemChanged (_ n:Notification) {
    self.updateNowPlayingItem()
    // ... and so on ...
}

let ob = NotificationCenter.default.addObserver(
    forName: .MPMusicPlayerControllerNowPlayingItemDidChange,
    object: nil, queue: nil) { _ in
        self.updateNowPlayingItem()
        // ... and so on ...
    }

Unregistering

To unregister an object as a recipient of notifications, call the notification center’s removeObserver(_:) method. Alternatively, you can unregister an object for just a specific set of notifications with removeObserver(_:name:object:). The object passed as the first argument is the object that is no longer to receive notifications. What object that is depends on how you registered it in the first place:

You called addObserver(_:selector:name:object:)

You supplied an observer originally, as the first argument; that is the observer you will now unregister. This will typically be self.

You called addObserver(forName:object:queue:using:)

The call returned an observer token object typed as an NSObjectProtocol (its real class and nature are undocumented); that is the observer you will now unregister.

In the old days, if you failed to unregister an object as a notification recipient and that object went out of existence, your app would crash the next time the notification was sent — because the runtime was trying to send a message to an object that was now missing in action. But in iOS 9, Apple introduced a safety check. Nowadays, if the notification center tries to send a message to a nonexistent object, there is no crash, and the notification center helpfully unregisters the object for you.

What you need to do as you go out of existence depends, once again, on how you registered in the first place:

You called addObserver(_:selector:name:object:)

You probably don’t need to unregister the object passed as the first argument. If that object goes out of existence, and if the notification is posted subsequently, there won’t be any crash.

You called addObserver(forName:object:queue:using:)

You do need to unregister the observer, because otherwise the notification center keeps it alive and can continue to send notifications to it (which means that the attached function will continue to be called).

So the question now boils down to how you’re going to unregister the observer returned by a call to addObserver(forName:object:queue:using:). If you only need to receive a notification once, you can unregister from within the anonymous function that runs when the notification is received (because the observer is in scope within the anonymous function). Otherwise, you’ll have to keep a separate persistent reference to the observer object so that you can unregister it later.

What’s a good way to do that? Let’s assume you’re going to be calling addObserver(forName:object:queue:using:) many times from within the same class. Then you’re going to end up receiving many observer tokens, and you’ll need to preserve a reference to all of them. One obvious approach is to store the observers in an instance property that is a mutable collection. My favored approach is a Set property:

var observers = Set<NSObject>()

Each time I register for a notification by calling addObserver(forName:object:queue:using:), I capture the result and add it to the set:

let ob = NotificationCenter.default.addObserver(
    forName: .MPMusicPlayerControllerNowPlayingItemDidChange,
    object: nil, queue: nil) { _ in
        self.updateNowPlayingItem()
        // ... and so on ...
    }
self.observers.insert(ob as! NSObject)

When it’s time to unregister all observers, I enumerate the set and empty it:

for ob in self.observers {
    NotificationCenter.default.removeObserver(ob)
}
self.observers.removeAll()

Posting a Notification

Notifications can be a way of communicating between your own objects. You post a notification yourself (in one object) and receive it yourself (in another object). This is probably not a good way to compensate for a failure to devise proper lines of communication between objects, but it can be appropriate when the objects are conceptually distant or independent from one another, or when you need the flexibility of broadcasting to multiple recipients.

To post a notification, send post(name:object:userInfo:) to the notification center. You are defining the name: yourself, so you’ll have to coerce a string into a Notification.Name. There are two main places to do this:

In the name: argument

You perform the coercion directly in the method call. That’s simple but error-prone: you’ll need to perform the same coercion twice (to post the notification and to register to receive it), and the repeated string literal is an invitation to make a typing mistake and have things mysteriously go wrong.

As a globally available constant

You define a namespaced constant and use it both when posting the notification and when registering for it. This approach localizes the coercion in a single place; it’s a little more work than the first approach, but it’s more correct and you should use it.

For example, one of my apps is a simple card game. The game needs to know when a card is tapped. But a card knows nothing about the game; when it is tapped, it simply emits a virtual shriek by posting a notification. I’ve defined my notification name by extending my Card class:

extension Card {
    static let tappedNotification = Notification.Name("cardTapped")
}

When a card is tapped, it responds like this:

NotificationCenter.default.post(name: Self.tappedNotification, object: self)

The game object has registered for Card.tappedNotification, so it hears about this and retrieves the notification’s object; now it knows what card was tapped and can proceed appropriately.

Timer

A Timer (Objective-C NSTimer) is not a notification, but it behaves quite similarly. It gives off a signal (fires) after the lapse of a certain time interval. Thus you can arrange to get an event when a certain time has elapsed. The timing is not perfectly accurate, nor is it intended to be, but it’s good enough for most purposes.

A timer that is actively watching the clock is said to be scheduled. A timer may fire once, or it may be a repeating timer. To stop a timer, it must be invalidated. A timer that is set to fire once is invalidated automatically after it fires; a repeating timer repeats until you invalidate it by sending it the invalidate message. An invalidated timer should be regarded as dead: you cannot revive it or use it for anything further, and you should probably not send any messages to it.

For example, one of my apps is a game with a score; I want to penalize the user by diminishing the score for every ten seconds that elapses after each move without the user making a further move. So I create and schedule a repeating timer whose time interval is ten seconds. Whenever the timer fires, I diminish the score. Whenever the user moves, I invalidate the existing timer and start over with a new repeating timer.

The simplest way to create a timer is with a class method that also schedules the timer, so that it begins watching the clock immediately:

scheduledTimer(timeInterval:target:selector:userInfo:repeats:)

The target: and selector: determine what message will be sent to what object when the timer fires; the method in question should take one parameter, which will be a reference to the timer. The userInfo: is just like the userInfo: of a notification.

scheduledTimer(withTimeInterval:repeats:block:)

You provide a function to be called when the timer fires; the function should take one parameter, which will be a reference to the timer.

A repeating Timer is often maintained as an instance property, so that you can invalidate it later on. But be careful! There is a temptation to call scheduledTimer(timeInterval:target:selector:userInfo:repeats:) directly as the initializer in your declaration of a Timer instance property, like this:

class ViewController : UIViewController {
    var timer = Timer.scheduledTimer(timeInterval: 1, target: self,
        selector: #selector(timerFired), userInfo: nil, repeats: true)

If the target is self, that won’t work, because self doesn’t exist yet at the time you’re initializing the instance property. (In my opinion, Swift should warn you about this, and I regard its failure to do so as a bug.) Use deferred initialization instead (“Deferred initialization of properties”):

class ViewController: UIViewController {
    var timer : Timer!
    override func viewDidLoad() {
        super.viewDidLoad()
        self.timer = Timer.scheduledTimer(timeInterval: 1, target: self,
            selector: #selector(timerFired), userInfo: nil, repeats: true)
    }

Cocoa Delegation

As implemented by Cocoa, here’s how delegation works:

1. A built-in Cocoa class has an instance property, usually called delegate (it will certainly have delegate in its name).

2. The Cocoa class promises that at certain moments it will turn to its delegate for instructions by sending it a certain message.

3. One of those moments arrives! If the Cocoa instance finds that its delegate is not nil, and that its delegate is prepared to receive that message, the Cocoa instance sends the message to the delegate.

Delegation is one of Cocoa’s main uses of protocols (Chapter 10). In the old days, delegate methods were listed in the Cocoa class’s documentation, and their names were made known to the compiler through an informal protocol (a category on NSObject). Nowadays, a class’s delegate methods are usually listed in a genuine protocol with its own documentation. There are over 70 Cocoa delegate protocols, showing how heavily Cocoa relies on delegation. Most delegate methods are optional, but in a few cases you’ll discover some that are required.

To take advantage of Cocoa delegation, you’ll have one of your classes adopt a Cocoa delegate protocol, and you’ll set some Cocoa object’s delegate (typed as that protocol) to an instance of your class. You might form the connection in code; alternatively, you might do it in a nib by connecting an object’s delegate outlet to an appropriate object within the nib. Now you are the delegate, and you get to help determine the Cocoa object’s behavior.

Your delegate class will probably do other things besides serving as this instance’s delegate. Indeed, one of the nice things about delegation is that it leaves you free to slot delegate code into your class architecture however you like; the delegate type is a protocol, so the actual delegate can be an instance of any class.

Here’s a typical example. I want to ensure that my app’s root view controller, a UINavigationController, should appear only in portrait orientation when this view controller is in charge. But UINavigationController isn’t my class; my class is a different view controller, a UIViewController subclass, which acts as the UINavigationController’s child. How can the child tell the parent how to rotate?

Delegation to the rescue! UINavigationController has a delegate property, typed as UINavigationControllerDelegate (a protocol). It promises to send this delegate the navigationControllerSupportedInterfaceOrientations(_:) message when it needs to know how to rotate. So my view controller, very early in its lifetime, sets itself as the UINavigationController’s delegate. It also implements the navigationControllerSupportedInterfaceOrientations(_:) method. Presto, the problem is solved:

class ViewController : UIViewController, UINavigationControllerDelegate {
    override func viewDidLoad() {
        super.viewDidLoad()
        self.navigationController?.delegate = self
    }
    func navigationControllerSupportedInterfaceOrientations(
        _ nav: UINavigationController) -> UIInterfaceOrientationMask {
            return .portrait
    }
}

When you’re searching the documentation for how you can be notified of a certain event, be sure to consult the corresponding delegate protocol, if there is one. Suppose you’d like to know when the user taps in a UITextField to start editing it. You won’t find anything relevant in the UITextField class documentation; what you’re after is textFieldDidBeginEditing(_:) in the UITextFieldDelegate protocol.

Implementing Delegation

The Cocoa protocol-and-delegate pattern is very useful, and you’ll probably want to adopt it in your own code. Setting up the pattern takes some practice, and can be a little time-consuming. But it’s a clean solution to the problem of apportioning knowledge and responsibilities among your objects. I’ll demonstrate with an example from one of my apps.

The app declares a view controller, a UIViewController subclass called ColorPickerController; its view contains three sliders that the user can move to choose a color. Some other view controller will create and present the ColorPickerController instance, displaying its view. When the user taps Done or Cancel, the view should be dismissed and the ColorPickerController instance can go out of existence; but first, I need to send a message from the ColorPickerController instance back to the view controller that presented it, reporting what color the user chose.

Here’s the declaration for the message that I want the ColorPickerController to send before it goes out of existence:

func colorPicker(_ picker:ColorPickerController,
    didSetColorNamed theName:String?,
    to theColor:UIColor?)

The question is: where and how should this method be declared?

Now, it happens that in my app I know the class of the instance that will in fact present the ColorPickerController: it is a SettingsController. So I could simply declare this method in SettingsController and stop. But that would mean that the ColorPickerController, in order to send this message to the SettingsController, must know that the instance that presented it is a SettingsController. That’s wrong. Surely it is a mere contingent fact that the instance being sent this message is a SettingsController; it should be open to any class to present and dismiss a ColorPickerController.

Therefore we want ColorPickerController itself to declare the method that it itself is going to call; and we want it to send that message blindly to some receiver, without regard to the class of that receiver. That’s what a protocol is for!

The solution, then, is for ColorPickerController to define a protocol, with this method as part of that protocol, and for the class that presents a ColorPickerController to conform to that protocol. ColorPickerController will also need an appropriately typed delegate instance property; this provides the channel of communication, and tells the compiler that sending this message is legal:

protocol ColorPickerDelegate : AnyObject {
    // color == nil on cancel
    func colorPicker(_ picker:ColorPickerController,
        didSetColorNamed theName:String?,
        to theColor:UIColor?)
}
class ColorPickerController : UIViewController {
    weak var delegate: ColorPickerDelegate?
    // ...
}

(For the weak attribute and the AnyObject designation, see Chapter 5.) When my SettingsController instance creates and configures and presents a ColorPickerController instance, it also sets itself as that ColorPickerController’s delegate — which it can do, because it adopts the protocol:

extension SettingsController : ColorPickerDelegate {
    func showColorPicker() {
        let colorName = // ...
        let c = // ...
        let cpc = ColorPickerController(colorName:colorName, color:c)
        cpc.delegate = self
        self.present(cpc, animated: true)
    }
    func colorPicker(_ picker:ColorPickerController,
        didSetColorNamed theName:String?,
        to theColor:UIColor?) {
            // ...
    }
}

When the user picks a color, the ColorPickerController knows to whom it should send colorPicker(_:didSetColorNamed:to:) — namely, its delegate! And the compiler allows this, because the delegate has adopted the ColorPickerDelegate protocol:

@IBAction func dismissColorPicker(_ sender : Any?) { // user tapped Done
    let c : UIColor? = self.color
    self.delegate?.colorPicker(self, didSetColorNamed: self.colorName, to: c)
}

The Responder Chain

Whenever the user does something with a finger (sets it down on the screen, moves it, raises it from the screen), a touch object (UITouch) is used to represent that finger. UIEvents are the lowest-level objects charged with communication of touch objects to your app; a UIEvent is basically a timestamp (a Double) along with a collection (Set) of touch objects. As I said in the previous section, you can receive a UIEvent along with a control event, but you will rarely need to do so.

A responder is an object that knows how to receive UIEvents directly. It is an instance of UIResponder or a UIResponder subclass. If you examine the Cocoa class hierarchy, you’ll find that just about any class that has anything to do with display on the screen is a responder. A UIView is a responder. A UIWindow is a responder. A UIViewController is a responder. Even a UIApplication is a responder. Even the app delegate is a responder!

A UIResponder has four low-level methods for receiving touch-related UIEvents:

• touchesBegan(_:with:)

• touchesMoved(_:with:)

• touchesEnded(_:with:)

• touchesCancelled(_:with:)

These methods — the touch methods — are called to notify a responder that a touch event has occurred: the user has placed, moved, or lifted a finger from the screen. No matter how your code ultimately hears about a user-related touch event — indeed, even if your code never hears about a touch event directly — the touch was initially communicated to a responder through one of the touch methods.

The mechanism for this communication starts by deciding which responder the user touched. The UIView methods hitTest(_:with:) and point(inside:with:) are called until the correct view (the hit-test view) is located. Then UIApplication’s sendEvent(_:) method is called, which calls UIWindow’s sendEvent(_:), which now wants to call the correct touch method in some responder.

So now the runtime starts looking for a responder that implements the correct touch method, so that the touch event can be reported by calling it. That responder need not be the hit-test view! The hit-test view is just the starting place for the search. The search depends upon the fact that your app’s responders participate in a responder chain, which essentially links them up through the view hierarchy.

The responder chain, from bottom to top, looks roughly like this:

1. The UIView that we start with (here, the hit-test view).

2. If this UIView is a UIViewController’s view, that UIViewController.

3. The UIView’s superview.

4. Go back to step 2 and repeat! Keep repeating until we reach…

5. The UIWindow (and, new in iOS 13, the UIWindowScene).

6. The UIApplication.

7. The UIApplication’s delegate.

The next responder up the responder chain is a responder’s next responder, which is obtained from a responder through its next property (which returns an Optional wrapping a UIResponder). Thus the responder chain can be walked upward from any responder to the top of the chain.

Nil-Targeted Actions

A nil-targeted action is a UIControl target–action pair in which the target is nil. There is no designated target object, so the following rule is used: starting with the hit-test view (the view with which the user is interacting), Cocoa walks up the responder chain looking for an object that can respond to the action message:

• If a responder is found that handles this message, that method is called on that responder, and that’s the end.

• If we get all the way to the top of the responder chain without finding a responder to handle this message, nothing happens; the message goes unhandled, with no penalty.

Here’s a UIButton subclass that configures itself to call a nil-targeted action when tapped:

override func awakeFromNib() {
    super.awakeFromNib()
    class Dummy {
        @objc func buttonPressed(_:Any) {}
    }
    self.addTarget(nil, // nil-targeted
        action: #selector(Dummy.buttonPressed),
        for: .touchUpInside)
}

That’s a nil-targeted action. So what happens when the user taps the button? First, Cocoa looks in the UIButton itself to see whether it responds to buttonPressed. If not, it looks in the UIView that is its superview. And so on, up the responder chain. There is surely a view controller that owns the view that contains the button; if the view controller is the first responder encountered in the search whose class implements buttonPressed, tapping the button will cause the view controller’s buttonPressed to be called — even though the view controller is not the target!

It’s obvious how to construct a nil-targeted action in code: you set up a target–action pair where the target is nil, as in the preceding example. But how do you construct a nil-targeted action in a nib? The answer is: you form a connection to the First Responder proxy object (in the dock). That’s what the First Responder proxy object is for! The First Responder isn’t a real object with a known class, so before you can connect an action to it, you have to define the action message within the First Responder proxy object, like this:

1. Select the First Responder proxy in the nib, and switch to the Attributes inspector.

2. You’ll see a table (probably empty) of user-defined nil-targeted First Responder actions. Click the Plus button and give the new action a name; it must take a single parameter (so that its name will end with a colon).

3. Now you can Control-drag from a control, such as a UIButton, to the First Responder proxy to specify a nil-targeted action with the name you specified.

Registration and Notification

There are two different ways to configure KVO registration and notification. The first way is the Cocoa way; it basically just translates the Objective-C API directly into Swift. The second way is provided by Swift; it uses the Cocoa way under the hood, but it shields you from some of the messy details.

I’ll describe the Cocoa way just so that you understand the mess that the Swift way shields you from. In the Cocoa way, you call addObserver(_:forKeyPath:options:context:) on the object whose property you want to observe, using a Cocoa key path (Chapter 10). Subsequently, the observer’s observeValue(forKeyPath:of:change:context:) is called for every change for which this observer has been registered. This single observer method constitutes a nasty bottleneck, especially if this observer is observing more than one value, possibly in more than one observed object. That’s what the Swift way protects you from.

Here’s how the Swift way works. You register by calling observe(_:options:changeHandler:) on the object whose property you want to observe, with these parameters:

keyPath:

The first parameter is a Swift key path (Chapter 5), not a Cocoa key path.

options:

An NSKeyValueObservingOptions bitmask (an option set) specifying such things as when you want to be notified (only when the observed value changes, or now as well) and what information you want included in the notification (the old value, the new value, or both).

changeHandler:

A function to be called as a way of sending the notification. It will typically be an anonymous function, making it part of the registration. It should take two parameters:

The object

This will be the observed object with which we are registered.

The change

An NSKeyValueObservedChange object. Its properties give you information such as the old value and the new value if you requested them in the options: argument.

The call to observe(_:options:changeHandler:) also returns a value, an NSKeyValueObservation instance. That is the registered observer.

The Swift key–value observing API is a language feature, not an SDK feature. It puts a convenient mechanism in front of the Cocoa API, but it still uses the Cocoa API. When you call observe(_:options:changeHandler:), Swift calls addObserver(_:forKeyPath:options:context:) to register the observer with the observed object. And the NSKeyValueObservation object implements the bottleneck method observeValue(forKeyPath:of:change:context:) to receive notification messages, which it passes on to you.

Unregistering

Unregistration is performed through a message to the observed object, namely removeObserver(_:forKeyPath:context:). If the observer goes out of existence without unregistering, the observed object might later try to send a message to a nonexistent observer, resulting in a crash. So the observer needs to maintain a reference to the observed object and, at the latest, must unregister itself when going out of existence.

That can be a daunting responsibility — and is yet another thing that the Swift API helps you with. The NSKeyValueObservation object returned from the call to observe(_:options:changeHandler:) maintains a reference to the observed object, so you don’t have to; and it will unregister itself (by calling removeObserver(_:forKeyPath:context:) on the observed object) either if you send it the invalidate message or automatically when it itself is about to go out of existence.

Your job is to capture the NSKeyValueObservation object and maintain it, probably in an instance property of the observer. That’s all, because this means it will go out of existence, at the latest, when the observer does — and at that moment will unregister itself in good order. But you must capture and maintain that object somehow! If you don’t, it will go out of existence and unregister itself immediately — before a notification is ever sent — and you’ll never get any notifications in the first place.

Another problem is what happens if the observed object goes out of existence when observers are still registered on it. There are two cases:

In iOS 11 and later

Nothing happens. This isn’t anything to worry about.

In iOS 10 and before

Your app will crash immediately. To prevent that, if the observed object is about to go out of existence while the observer continues to exist, you must unregister the NSKeyValueObservation object explicitly by sending it invalidate.

Key–Value Observing Example

To demonstrate KVO, I’ll declare classes to play both roles, the observer and the observed.

First, the observed. My Observed class has a value instance property that we want other objects to be able to observe:

class Observed : NSObject { 
    @objc dynamic var value : Bool = false 
}

The observed object’s class must derive from NSObject; otherwise, you won’t be able to call observe(_:options:changeHandler:) on it. That’s because the mechanism for being observed is a feature of NSObject.

The property to be observed must be declared @objc in order to expose it to Objective-C — and it must also be declared dynamic. That’s because KVO works by swizzling the accessor methods; Cocoa needs to be able to reach right in and change this object’s code, and it can’t do that unless the property is dynamic.

The Observer class contains code that registers with an Observed to hear about changes in its value property:

class Observer {
    var obs = Set<NSKeyValueObservation>() 
    func registerWith(_ observed:Observed) {
        let opts : NSKeyValueObservingOptions = [.old, .new]
        let ob = observed.observe(\.value, options: opts) { obj,change in 
            if let oldValue = change.oldValue {
                print("old value was \(oldValue)")
            }
            if let newValue = change.newValue {
                print("new value is \(newValue)")
            }
        }
        obs.insert(ob) 
    }
}

Observer has an instance property for maintaining NSKeyValueObservation objects. As with Notification observer tokens (discussed earlier in this chapter), I like to use a Set for this purpose.

Observer (in its registerWith(_:) method) will register with an Observed instance by calling observe(_:options:changeHandler:), using a Swift key path to specify the value property. I’ve illustrated the use of NSKeyValueObservingOptions by asking for both the old and new values of the observed property when a notification arrives. That information will arrive into the notification function inside an NSKeyValueObservedChange object.

The call to observe(_:options:changeHandler:) returns an NSKeyValueObservation object. It is crucial to ensure the continued existence of this object; otherwise, it will go out of existence and unregister itself before the notification can ever arrive. Therefore, I immediately store it in the Set instance property that was declared for this purpose.

Presume now that we have a persistent Observer instance, observer, and that its registerWith(_:) has been called with argument observed, an Observed instance that is also persistent. So much for registration!

Now let’s talk about change and notification. Somehow, someone sets observed’s value to true, which changes it in a KVO compliant way. At that moment, the notification is sent and the anonymous function is called! The following appears in the console:

old value was false
new value is true

Finally, let’s talk about unregistering. As long as we are running in iOS 11 or later, there is nothing to talk about! It doesn’t matter whether observed or observer goes out of existence first; everything happens automatically and in good order:

• If observed goes out of existence first, there is no crash and there will be no further notifications.

• When observer goes out of existence, the obs property is destroyed, and so the NSKeyValueObservation object is destroyed — and at that moment, if observed still exists, the NSKeyValueObservation object unregisters itself (and if observed no longer exists, nothing bad happens).

In general your real-life use of KVO in programming iOS will likely be no more complex than that. Cocoa key–value observing, however, is a deep and complex mechanism; consult Apple’s Key-Value Observing Programming Guide in the documentation archive for full information.