Building Reactive Applications With RxSwift is a practical introduction to reactive programming. Reactive programming asks for a new mindset. You need to think differently and that may take a bit of time. Reactive programming changes how you think about code and that is what trips up many developers that are new to reactive programming.

Swift isn't a reactive programming language, but there are a handful of libraries and frameworks available to reactify Swift. We focus on RxSwift in this series, the most commonly used reactive library for Swift. It doesn't matter if you use RxSwift, Combine, or ReactiveCocoa, Building Reactive Applications With RxSwift explores the fundamental concepts of reactive programming using the Swift programming language.

What Is Reactive Programming?

Coming up with a definition for reactive programming is surprisingly challenging and some definitions make your head spin. I would like to start with a very simple definition and show you what reactive programming is with an example. What is reactive programming?

Reactive programming is working with asynchronous streams of data.

There's more to reactive programming than that, but this definition is sufficient for now. Let's use an example to better understand this definition of reactive programming.

Streams of Data

I have created a simple application to illustrate the fundamental concepts of reactive programming. The application shows a table view and a button in the top right. Every time the user taps the button, the view controller adds a row to the table view. Each row shows the date and time the user tapped the button.

How does this example relate to reactive programming? Let's revisit the definition of reactive programming. Reactive programming is working with asynchronous streams of data. Let's start with streams of data.

Streams of data are the fundamental building blocks of a reactive application. A stream of data is nothing more than a sequence of events ordered in time. The button in the top right illustrates this. It generates a stream of tap events. Every time the user taps the button, an event, a tap in this example, is emitted. The view controller listens for these events and it responds by adding a row to its table view every time an event is emitted. The Objective-C runtime works differently, but that isn't the focus of this episode.

Let me explain this with a diagram. The horizontal line represents time. Each circle on the line represents an event, the user tapping the button in this example. The view controller listens for these events and responds every time an event is emitted. This representation is also known as a marble diagram.

Asynchronous

The view controller is notified asynchronously when the user taps the button. What does that mean? This is something many developers struggle with. It simply means that the view controller is notified independently of the main application flow. Take a moment to let this sink in because it's an important concept of reactive programming.

Observer Pattern

It's time for a bit of theory. The pattern that drives reactive programming is the observer pattern. You may be new to reactive programming, but the observer pattern should be familiar. Chances are that you have used the observer pattern in some, if not most, of your projects. Notifications are an example of the observer pattern and even delegation can be considered an example of the observer pattern.

The observer pattern is easy to understand. It defines subjects and observers. The observer is interested in the changes of the subject. Every time the subject changes, the observers of the subject are notified. That's the observer pattern in a nutshell.

Let's use notifications to illustrate the observer pattern. In the viewDidLoad() method of the ViewController class we invoke the addObserver(forName:object:queue:using:) method on the application's default notification center. The addObserver(forName:object:queue:using:) method accepts four arguments. We are interested in the second argument and the fourth argument. The second argument is the subject the view controller observes, the UIApplication singleton in this example. The fourth argument is the observer, a closure that is executed every time a notification is posted by the subject.

// MARK: - View Life Cycle

override func viewDidLoad() {
    super.viewDidLoad()

    // Observe Did Enter Background Notification
    NotificationCenter.default.addObserver(forName: UIApplication.didEnterBackgroundNotification, object: UIApplication.shared, queue: nil) { (_) in
        print("did enter background")
    }
}

The advantage of the observer pattern is that subjects and observers are loosely coupled. The subject and the observer don't have a strictly defined relationship. It's the responsibility of the observer to subscribe to changes of the subject. The observer unsubscribes when it is no longer interested in changes of the subject.

Terminology

Before we move on, we need to become familiar with the terminology of reactive programming. The observer pattern defines subjects and observers. In reactive programming, the stream of data is the subject and it is commonly referred to as an observable sequence or observable for short. The button generates a stream of data to which the view controller listens. Listening in reactive programming is better known as subscribing. The closure, function, or method that is executed when an event is emitted is the observer. That's it.

Observables, observers, and subscribing are three key keywords you need to remember. We use them throughout this series.

Asynchronous Streams of Data

Let's revisit the definition of reactive programming. Reactive programming is working with asynchronous streams of data. With what we learned in this episode, we can rephrase this definition. Reactive programming is working with observable sequences that asynchronously emit or produce events to which an observer can subscribe.

Why Should You Use It?

If you're new to reactive programming, then you may still be wondering why you should adopt reactive programming. You're interested, but you're not sure if it's for you. Truth be told, I wasn't convinced the first time I came across reactive programming.

One of the most compelling benefits is that reactive programming makes asynchronous programming less complex. Why that is becomes clear later in this series.

Reactive code is often more concise and easier to understand because you describe what you would like to accomplish. This is also known as declarative programming.

Another benefit I enjoy immensely is that reactive applications manage less state. A reactive application observes and reacts to streams of data. It doesn't hold onto state. This results in code that is easier to understand and maintain.

What's Next?

Don't worry if you're still a bit confused. It takes time to let these concepts sink in. At this point, it's important that you understand what reactive programming is and what it's about. Reactive programming can be challenging to learn if you skip the basics. In the next episode, we take a look at ReactiveX, RxSwift, and RxCocoa.