Visibility Through an Instance Property

The problem of communication often comes down to one object being able to see another: the object Manny needs to be able to find the object Jack repeatedly and reliably over the long term so as to be able to send Jack messages. One obvious solution is an instance property of Manny whose value is Jack.

An instance property is appropriate particularly when Manny and Jack share certain responsibilities or supplement one another’s functionality. Here are some cases where one object needs to have an instance property pointing at another:

• The application object and its delegate

• A table view and its data source

• A view controller and the view that it controls

Manny may have an instance property pointing to Jack, but this does not necessarily imply that Manny needs to assert ownership of Jack as a matter of memory management policy (see Chapter 12):

• An object does not typically retain its delegate or its data source.

• An object that implements the target–action pattern, such as a UIControl, does not retain its target.

By using a weak reference and typing the property as an Optional, and then treating the Optional coherently and safely, Manny can keep a reference to Jack without owning Jack (while coping with the possibility that his supposed reference to Jack will turn out to be nil). On the other hand, sometimes ownership is appropriate and crucial. A view controller is useless without a view to control, and its view truly belongs to the view controller and to no one else; once a view controller has a view, it will retain it, releasing it only when it itself goes out of existence.

Objects can perform two-way communication without both of them holding references to one another. It may be sufficient for one of them to have a reference to the other — because the former, as part of a message to the latter, can include a reference to himself. Manny might send a message to Jack where one of the parameters is a reference to Manny; this might merely constitute a form of identification, or an invitation to Jack to send a message back to Manny if Jack needs further information while doing whatever this method does. Manny makes himself, as it were, momentarily visible to Jack; Jack should not wantonly retain Manny (especially since there’s an obvious risk of a retain cycle). Again, this is a common pattern:

• The parameter of the delegate message textFieldShouldBeginEditing(_:) is a reference to the UITextField that sent the message.

• The first parameter of a target–action message is a reference to the control that sent the message.

Visibility by Instantiation

Every instance comes from somewhere and at someone’s behest: some object sent a message commanding this instance to come into existence in the first place. The commanding object therefore has a reference to the new instance at the moment of instantiation. When Manny creates Jack, Manny has a reference to Jack.

That simple fact can serve as the starting point for establishing future communication. If Manny creates Jack and knows that he (Manny) will need a reference to Jack later on, Manny can keep the reference that he obtained by creating Jack in the first place.

Or it might be the other way around: Manny creates Jack and knows that Jack will need a reference to Manny later on, so Manny can supply that reference immediately after creating Jack, and Jack will then keep it. Delegation is a case in point. Manny may create Jack and immediately make himself Jack’s delegate, as in my example code in Chapter 11:

let cpc = ColorPickerController(colorName:colorName, color:c)
cpc.delegate = self

When Manny creates Jack, it might not be a reference to Manny himself that Jack needs, but to something that Manny knows or has. You will presumably endow Jack with a method or property so that Manny can hand over that information. In fact, if Jack simply cannot live without the information, it might be reasonable to endow Jack with an initializer that requires this information as part of the very act of creation.

This example (Chapter 11) comes from a table view controller. The user has tapped a row of the table. In response, we create a secondary table view controller, a TracksViewController instance; we hand it the data it will need, and display the secondary table view:

override func tableView(_ tableView: UITableView,
    didSelectRowAt indexPath: IndexPath) {
        delay(0.1) {
            let t = TracksViewController(
                mediaItemCollection: self.albums[indexPath.row])
            self.navigationController?.pushViewController(t, animated: true)
        }
}

In that code, I instantiate the TracksViewController by calling its initializer, init(mediaItemCollection:), which requires me to hand over the media item collection that the view controller will need as the basis of its table view. And where did this initializer come from? I made it up! I have deliberately devised TracksViewController to have a designated initializer init(mediaItemCollection:), making it virtually obligatory for a TracksViewController to have access, from the moment it comes into existence, to the data it needs.

In that example, I (self) create the TracksViewController instance, and so, for one brief shining moment, I have a reference to it. Therefore I take advantage of that moment to hand the TracksViewController instance the information it needs. There will be no better moment to do this. Knowing the moment, and taking care not to miss it, is part of the art of data communication.

Nib-loading is also a case in point. The loading of a nib is a way of instantiating objects from the nib. Proper preparation is essential in order to ensure that those objects are assigned to strong references, so that they don’t simply vanish in a puff of smoke (“Nib Loading and Memory Management”). At the moment the nib loads, the nib’s owner or the code that loads the nib is in contact with those objects; it takes advantage of that moment to secure those references.

Another key moment is when a segue in a storyboard is triggered. There are two view controllers that may need to meet — the view controllers at the two ends of the segue, the source view controller and the destination view controller. This is parallel to the situation where one view controller creates another view controller and presents it, but there’s an important difference: with a triggered segue, the source view controller doesn’t create the destination view controller. But it probably still needs a reference to the destination view controller, very early in the life of the latter, so that it can hand over any needed information. How will it get that reference?

At the moment the segue is triggered, the source view controller already exists, and the segue knows what view controller it is; and the segue itself instantiates the destination view controller. So the segue immediately turns to the source view controller and hands it a reference to the destination view controller — for example, by calling the source view controller’s prepare(for:sender:) method. This is the source view controller’s chance to obtain a reference to the newly instantiated destination view controller — and to make itself the destination view controller’s delegate, or hand it any needed information, and so forth.

Getting a Reference

A source of particular frustration arises when you know that another object exists somewhere out there but you don’t know how to refer to it.

Let’s say you’re a view controller and there’s some other view controller you need to talk to. But you didn’t instantiate the other view controller, and you are not the source view controller for the segue that instantiated the other view controller. You know a lot about this other view controller — you know what its class is, and you can probably see its view sitting there in the interface when you run the app — but you cannot get hold of it in code.

Here’s what not to do in that situation: You know the class of the view controller you’re looking for, so you make an instance of that class. That won’t do you any good! The instance you want to talk to is a particular instance that already exists. There’s no point making another instance. If you lose your car in a parking lot, the solution is not to build another car of the same model; the solution is to find your car.

For example, in a real-life iOS app, you will have a root view controller, which will be an instance of some type of UIViewController. Let’s say it’s an instance of the ViewController class. Once your app is up and running, this instance already exists. Now suppose we are in some other view controller, and we want to talk to the ViewController instance that is serving as the root view controller of the app. It would be counterproductive to try to speak to the root view controller by instantiating the ViewController class:

let theVC = ViewController() // legal but pointless

All that does is to make a second, different instance of the ViewController class, and your messages to that instance will be wasted, as it is not the instance of ViewController that you wanted to talk to. That particular instance already exists; what you want is to get a reference to that already existing instance. But how? Here are some considerations that will help you.

let app = UIApplication.shared

let window = app.windows.first

let vc = window?.rootViewController

func setHazyStripy () {
    let hs = UserDefaults.standard
        .object(forKey:Default.hazyStripy) as! Int
    self.hazyStripy.selectedSegmentIndex = hs
}

@IBAction func hazyStripyChange(_ sender: Any) {
    let hs = self.hazyStripy.selectedSegmentIndex
    UserDefaults.standard.set(hs, forKey: Default.hazyStripy)
}

override func draw(_ rect: CGRect) {
    let hazy : Bool = UserDefaults.standard
        .integer(forKey:Default.hazyStripy) == HazyStripy.hazy.rawValue
    CardPainter.shared.drawCard(self.card, hazy:hazy)
}

Notifications and Key–Value Observing

Notifications (Chapter 11) can be a way to communicate between objects that are conceptually distant from one another without bothering to provide any way for one to see the other. All they really need to have in common is a knowledge of the name of the notification. Every object can see the notification center — it is a globally visible object — so every object can arrange to post or receive a notification.

Using a notification in this way may seem lazy, an evasion of your responsibility to architect your objects sensibly. But sometimes one object doesn’t need to know, and indeed shouldn’t know, what object (or objects) it is sending a message to.

Recall the example I gave in Chapter 11. In a simple card game app, the game needs to know when a card is tapped. A card, when it is tapped, knowing nothing about the game, simply emits a virtual shriek by posting a notification; the game object has registered for this notification and takes over from there:

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

Here’s another example, taking advantage of the fact that notifications are a broadcast mechanism. In one of my apps, the app delegate may detect a need to tear down the interface and build it back up again from scratch. If this is to happen without causing memory leaks (and all sorts of other havoc), every view controller that is currently running a repeating Timer needs to invalidate that timer (Chapter 12). Rather than my having to work out what view controllers those might be, and endowing every view controller with a method that can be called, I simply have the app delegate shout “Everybody stop timers!” by posting a notification. All my view controllers that run timers have registered for this notification, and they know what to do when they receive it.

By the same token, Cocoa itself provides notification versions of many delegate and action messages. The app delegate has a method for being told when the app goes into the background, but other objects might need to know this too; those objects can register for the corresponding notification.

Similarly, key–value observing can be used to keep two conceptually distant objects synchronized with one another: a property of one object changes, and the other object hears about the change. As I said in Chapter 11, entire areas of Cocoa routinely expect you to use KVO when you want to be notified of a change in an object property. You can configure the same sort of thing with your own objects.

The Combine Framework

There is some commonality between mechanisms such as the notification center and key–value observing. In both cases, you register with some other object to receive a certain message whenever that other object cares to send it. Basically, you’re opening and configuring a pipeline of communication, and leaving it in place until you no longer need it. Looked at in that way, notifications and key–value observing seem closely related to one another. In fact, the target–action mechanism of reporting control events seems related as well. So does a Timer. So does delayed performance.

New in Swift 5.1 and iOS 13, the Combine framework offers to unify these architectures (and others) under a single head. At its heart, Combine depends upon an abstract notion of publish-and-subscribe, and reifies that abstraction with two protocols, Publisher and Subscriber:

Publisher

A publisher promises to provide a certain kind of a value, perhaps repeatedly, at some time in the future.

Subscriber

A Subscriber registers itself with (subscribes to) a Publisher to receive its value whenever it comes along.

When a Subscriber subscribes to a Publisher, here’s what happens:

1. The Publisher responds by handing the Subscriber a Subscription (yet another protocol).

2. The Subscriber can then use the Subscription to ask the Publisher for a value.

3. The Publisher can respond by sending, whenever it cares to, a value to the Subscriber. It can do this as many times as it likes.

4. In some situations, the entire connection can be cancelled when the Subscriber no longer wishes to receive values.

That’s a rather elaborate-sounding dance, but in most cases you won’t experience it that way. You won’t experience the dance at all! Instead, you’ll just hook up a built-in subscriber directly to a built-in publisher and all the right things will happen.

To illustrate, I’ll start with a trivial example. One of the simplest forms of publisher is a Subject. Every time you call send(_:) on a Subject, handing it a value, it sends that value to its subscribers. There are just two kinds of Subject:

PassthroughSubject

Produces the value sent to it with send.

CurrentValueSubject

Like a PassthroughSubject, except that it has a value at the outset, and produces it to any new subscriber.

Let’s make a Subject:

let pass = PassthroughSubject<String,Never>()
pass.send("howdy")

That compiles and runs, but we don’t know that anything happened because we have no subscriber. There are just two built-in independent subscribers, and each can be created with a convenience method sent to a publisher; the method subscribes the subscriber to the publisher and returns it:

sink

Takes a function to be called whenever a value is received. The function takes a single parameter, namely the value.

assign

Takes a Swift key path and an object. Whenever a value is received, assigns that value to the property of that object designated by the key path.

So here’s a complete publish-and-subscribe example:

let pass = PassthroughSubject<String,Never>()
let sink = pass.sink { print($0) }
pass.send("howdy") // howdy

A Subject can also be a subscriber — and that completes the list of built-in subscribers. There are, on the other hand, a lot of built-in publishers. We can divide these into two broad categories:

Origins

An origin (a term I’ve made up) is a true source of values. A number of Foundation types vend publishers that act as origins. Here are some:

• The notification center

• A KVO compliant property

• A computed property declared with the @Published property wrapper

• The Timer class

• A Scheduler (used for delayed performance; DispatchQueue, OperationQueue, and RunLoop are all Schedulers)

• A URLSession (for obtaining a value via the network)

Operators

An operator is a Publisher that is somewhat like a Subscriber. You attach it to a Publisher, and it produces another Publisher.

The real power of the Combine framework lies in the operators (of which there are a great many). By chaining operators, you construct a pipeline that passes along only the information you’re really interested in; the logic of analyzing, filtering, and transforming that information is pushed up into the pipeline itself.

To illustrate, I’ll use the notification center as my origin. Let’s go back to my example of a Card view that emits a virtual shriek when it is tapped by posting a notification:

static let tapped = Notification.Name("tapped")
@objc func tapped() {
    NotificationCenter.default.post(name: Self.tapped, object: self)
}

Now let’s say, for purposes of the example, that what the game is interested in when it receives one of these notifications is the string value of the name property of the Card that posted the notification. Getting that information is a two-stage process. First, we have to register to receive notifications at all:

NotificationCenter.default.addObserver(self,
    selector: #selector(cardTapped), name: Card.tapped, object: nil)

Then, when we receive a notification, we have to look to see that its object really is a Card, and if it is, fetch its name property and do something with it:

@objc func cardTapped(_ n:Notification) {
    if let card = n.object as? Card {
        let name = card.name
        print(name) // or something
    }
}

Now let’s do the same thing using the Combine framework. We obtain a publisher from the notification center by calling its publisher method. But we don’t stop there. We don’t want to receive a notification if the object isn’t a Card, so we use the compactMap operator to cast it safely to Card (and if it isn’t a Card, the pipeline just stops as if nothing had happened). We only want the Card’s name, so we use the map operator to get it. Here’s the result:

let cardTappedCardNamePublisher =
    NotificationCenter.default.publisher(for: Card.tapped)
        .compactMap {$0.object as? Card}
        .map {$0.name}

Let’s say that cardTappedCardNamePublisher is an instance property of our view controller. Then what we now have is an instance property that publishes a string if a Card posts the tapped notification, and otherwise does nothing. Do you see what I mean when I say that the logic is pushed up into the pipeline? Just for completeness, let’s arrange to receive that string by subscribing to the publisher:

let sink = self.cardTappedCardNamePublisher.sink {
    print($0) // the string name of a card
}

Here’s another example. You may have noticed that I didn’t list controls (UIControl) among the built-in publishers. This means we can’t automatically replace the control target–action mechanism using the Combine framework. However, with just a little modification, we can turn a control into a publisher. I’ll demonstrate with a switch control (UISwitch). It has an isOn property, which is changed when the user toggles the switch on or off. The target–action way to learn that this has happened is through the switch’s .valueChanged control event. Instead, let’s write a UISwitch subclass where we vend a publisher and funnel the isOn value through it:

class MySwitch : UISwitch {
    required init?(coder: NSCoder) {
        super.init(coder:coder)
        self.isOnPublisher = self.isOn
        self.addTarget(self,
            action: #selector(didChangeOn), for: .valueChanged)
    }
    @Published var isOnPublisher = false
    @objc func didChangeOn() {
        self.isOnPublisher = self.isOn
    }
}

That code illustrates the @Published property wrapper. This creates a publisher behind the scenes, and vends it through the property wrapper’s dollar-sign projectedValue (“Property Wrappers”). With our subclass, the way to be kept informed about changes to the switch’s isOn property is to subscribe to its publisher, namely $isOnPublisher. Suppose we have an outlet to the switch:

@IBOutlet var mySwitch : MySwitch!

Then we can subscribe with sink once again:

let sink = self.mySwitch.$isOnPublisher.sink {
    print($0)
}

But wait — doesn’t that look awfully familiar? Yes, it does — and that’s the point. Using Combine, we’ve effectively reduced the notification center mechanism and the control target–action mechanism to the same mechanism. Moreover, we made our UISwitch send us messages when a property changes, without bothering to use key–value observing. We could use key–value observing — there is an NSObject publisher(for:) method that lets us specify a key–value observable property — but it’s simpler to use the @Published property wrapper, and unlike key–value observing, it works without our object being an NSObject (or even a class).

The real power of the Combine framework emerges when we build complex pipelines. To illustrate, let’s combine (sorry about that) the notification center pipeline and the switch pipeline. Imagine that our interface consists of Cards along with a switch. When the switch is on, the cards are interactive: the user can tap one, and we hear about it. When the switch is off, the user’s taps do nothing.

To implement this, we can put the notification center publisher and the switch publisher together into a single pipeline. The Combine publisher that does that is CombineLatest:

lazy var combination =
    Publishers.CombineLatest(
        self.cardTappedCardNamePublisher, self.mySwitch.$isOnPublisher)

What we now have is a publisher that channels the pipelines from our other two publishers into one. It remembers every value that last arrived from either source, and when it gets a new value, it emits a tuple consisting of both values. In our case, that’s a (String,Bool).

However, that’s not what we actually want to have coming down the pipeline at us. We still want just the string name of the tapped card. So we’ll use the compactMap operator to extract it:

lazy var combination =
    Publishers.CombineLatest(
        self.cardTappedCardNamePublisher, self.mySwitch.$isOnPublisher)
            .compactMap { $0.0 }

Now we’re getting just the string name, but we’re getting too many string names; the switch isn’t having any effect. The pipeline is emitting values in response to user taps even when the switch is off! The whole idea of combining these two publishers was to eliminate any output when the switch is off. So we’ll interpose the filter operator to block any tuples whose Bool is false:

lazy var combination =
    Publishers.CombineLatest(
        self.cardTappedCardNamePublisher, self.mySwitch.$isOnPublisher)
            .filter { $0.1 }
            .compactMap { $0.0 }

This is looking much better. If the user taps while the switch is on, we get the card name. If the user taps while the switch is off, nothing happens. But there’s still one little problem. The CombineLatest publisher publishes if it gets a value from either of its source publishers. That means we don’t just get a value when the user taps a Card; we also get a value when the user toggles the switch. We don’t want that value to come out the end of the pipeline; we just want to use it to allow or prevent the arrival of the Card name.

What we want to do here is compare two values: the new tuple coming down the pipeline, and the previous tuple that came down the pipeline most recently. If the difference between the new tuple and the old tuple is merely that the Bool changed, we don’t want to emit a value from the pipeline. The way to compare the current value with the previous value is with the scan operator. I’ll use that operator to replace the card name string with nil whenever the Bool changes; the compactMap operator will catch this nil and block it from coming out the end of the pipeline:

lazy var combination =
    Publishers.CombineLatest(
        self.cardTappedCardNamePublisher, self.mySwitch.$isOnPublisher)
            .scan((nil,true)) { $0.1 != $1.1 ? (nil,$1.1) : $1 }
            .filter { $0.1 }
            .compactMap { $0.0 }

Our goal is accomplished. If the user taps a Card while the switch is on, the pipeline produces its name. If the user taps a Card while the switch is off, or toggles the switch, nothing happens.

These examples have only scratched the surface of what the Combine framework can do; but they demonstrate its spirit. And the potential benefits are profound. In Chapter 11 I complained that the event-driven nature of the Cocoa framework means that you’re bombarded with events through different entry points at different times, so that state has to be maintained in shared instance properties, and understanding the implications of any single entry point method call can be difficult. The Combine framework offers the potential of funneling events into pipelines whose logic can be manipulated internally, so that what comes out is just the information you need when you need it.

The Promise of SwiftUI

The SwiftUI framework is a wholesale alternative to Cocoa. Whether it talks to Cocoa under the hood or replaces it altogether isn’t clear and doesn’t matter. It operates on a programming paradigm that’s completely different from Cocoa’s, and offers the promise of writing iOS apps in a totally different way — not to mention that the same code might be reusable on Apple TV, Apple Watch, and desktop Macs. SwiftUI as a whole is outside the scope of this book; it needs a book of its own. The subject here is how objects see and communicate with one another.

To illustrate how SwiftUI deals with communication, let’s start with the prototypical “Hello World” app:

struct ContentView : View {
    var body: some View {
        Text("Hello World")
    }
}

That code puts the text “Hello World” in the middle of the screen. But how? It doesn’t seem to contain any runnable code. Well, actually it does: body is a computed property, and the curly braces that surround Text("Hello World") are its getter (with return omitted). The interface is constructed in code and returned. But that’s not quite accurate; it isn’t the interface that’s returned — it’s a description of the interface.

In SwiftUI, there is no storyboard; there are no nibs; there are no outlets. There is no UIViewController; there isn’t even a UIView. Text is a mere struct, and View is just a protocol. A SwiftUI View is extremely lightweight, and is barely persistent. There are no entry points other than the body property getter, which is merely the answer to an occasional question, “What should this view look like at this moment?”

The most pervasive object-oriented pattern in SwiftUI is that one View instantiates another View. Our simple “Hello World” app consists entirely of our ContentView instantiating a Text object in its body getter. This is the same pattern of visibility by instantiation that I discussed at the start of this chapter: when Manny creates Jack, Manny has a reference to Jack and can hand Jack any information that Jack needs in order to do his job. We do not have to get a reference to something in order to customize its appearance; we customize its appearance as part of its initialization. There is no need for the ContentView to get a reference to the Text in order to tell it what its visible content (“Hello World”) should be; the ContentView creates the Text, and creates it with that content.

struct ContentView : View {
    var body: some View {
        HStack {
            Text("Hello World")
            Spacer()
            Button("Tap Me") {
                // does nothing
            }
        }.frame(width: 200)
    }
}

HStack {
    Text("Hello World")
    Spacer()
    Button("Tap Me") {
        // does nothing
    }
}.frame(width: 200)
    .padding(20)
    .background(Color.yellow)

struct ContentView : View {
    @State var isHello = true 
    var greeting : String {
        self.isHello ? "Hello" : "Goodbye" 
    }
    var body: some View {
        HStack {
            Text(self.greeting + " World")
            Spacer()
            Button("Tap Me") {
                self.isHello.toggle() 
            }
        }.frame(width: 200)
            .padding(20)
            .background(Color.yellow)
    }
}

struct ContentView : View {
    @State var isHello = true
    var greeting : String {
        self.isHello ? "Hello" : "Goodbye"
    }
    var body: some View {
        VStack {
            Text(self.greeting + " World")
            Spacer()
            Toggle("Friendly", isOn: $isHello) // *
        }.frame(width: 150, height: 100)
            .padding(20)
            .background(Color.yellow)
    }
}

struct ContentView : View {
    @State var isHello = true
    var greeting : String {
        self.isHello ? "Hello" : "Goodbye"
    }
    @State var showSheet = false
    var body: some View {
        VStack {
            Button("Show Message") {
                self.showSheet.toggle()
            }.sheet(isPresented: $showSheet) {
                Greeting(greeting: self.greeting)
            }
            Spacer()
            Toggle("Friendly", isOn: $isHello)
        }.frame(width: 150, height: 100)
            .padding(20)
            .background(Color.yellow)
    }
}
struct Greeting : View {
    let greeting : String
    var body: some View {
        Text(greeting + " World")
    }
}

@State var name = ""

@Binding var username : String

Button("Show Message") {
    self.showSheet.toggle()
}.sheet(isPresented: $showSheet) {
    Greeting(greeting: self.greeting,
             username: self.$name)
}

TextField("Your Name", text:$username)
    .frame(width:200)
    .textFieldStyle(RoundedBorderTextFieldStyle())

class Defaults : ObservableObject {
    let objectWillChange = ObservableObjectPublisher()
    var username : String {
        get {
            UserDefaults.standard.string(forKey: "name") ?? ""
        }
        set {
            self.objectWillChange.send()
            UserDefaults.standard.set(newValue, forKey: "name")
        }
    }
}

@ObservedObject var defaults = Defaults()

Text(self.defaults.username.isEmpty ? "" :
    greeting + ", " + self.defaults.username)

Button("Show Message") {
    self.showSheet.toggle()
}.sheet(isPresented: $showSheet) {
    Greeting(greeting: self.greeting,
             username: self.$defaults.username)
}

@Environment(\.timeZone) var timeZone

window.rootViewController =
    UIHostingController(
        rootView: ContentView()
           .environmentObject(Defaults())
)

@EnvironmentObject var defaults : Defaults