For example, it can be used to describe code that was written before the requirements were fully understood and is found to be lacking once more information is available. Rather than rewrite the code from scratch (which is likely better in the long term), developers often hack around the substandard code’s limitations (which can be better in the short term.)

Another form is code that exists to implement a feature that is no longer needed. Disabling a feature generally only requires deleting a single line of code which renders hundereds of other lines obsolete.

Technical debt is an inevitable part of any evolving software system. There is rarely a business case to remove dead code or rewrite a whole module into a more efficient version, and developers rarely have the patience to do the kind of analysis necessary to remove all debt even when they have the time.

Too much technical debt makes software hard to update, slowing developers down. However, spending an inordinate amount of time removing the debt will also slow developers down. Therefore, it is something that developers must manage. When adding features to a project, and especially when fixing bugs, developers must allow extra time to remove some of the debt.

When velocity is high, project managers must prepare themselves for the inevitable complaints of too much debt buildup and should build in a “slow down” period, encouraging developers to attack the debt. When velocity is low, it would be helpful to determine if it’s because of debt buildup. If so, then allow for the velocity to slow even further to give the developers a chance to attack the built up debt.

Knowing exactly how much debt is acceptable, and what debt is most costly, is not something that the industry has found a way to quantify. To date, developers use subjective feelings about the state of the code rather than any hard metrics on how much is too much, or when too much time is being spent removing debt.

In my opinion, having general stories with titles like “pay down debt” or “refactor code” are a mistake. It encourages developers to cast around looking to clean up the low hanging fruit. But if a developer is complaining about a particular module being a pain to work with, that’s a good time to create a story to replace that particular module with something that has been better designed. Also, when determining story points, developers should be encouraged to consider if there is any already existing code that the new feature depends on which could use a going over, and bump up the points for the story to give them a chance to do that. This is especially true when it comes to fixing bugs. A bug in the code is a great time to realize that the module containing the bug likely has too much debt and the developer should consider doing more than just making the code work again.

Making a Resource

All this is pretty abstract though. What does it look like in practice? I recently was working on a screen that played audio files. One way to do that is to use the AVAudioPlayer class; a resource.

final class AudioSession: Disposable {
    let audioPlayer: AVAudioPlayer
    init(url: URL) throws {
        audioPlayer = try AVAudioPlayer(contentsOf: url)
        audioPlayer.play()
    }
    func dispose() {
        audioPlayer.stop()
    }
}

When the above resource is created, it will make the audio player and start playing. When the resource is disposed, it will stop the audio player. Now we can use it in the using operator like so:

let session = Observable.using({
    try AudioSession(url: url)
}, 
observableFactory: { audioSession in
    Observable<Never>.never()
})

When you subscribe to session it will create the AudioSession resource, and thus start playing the sound file. When you dispose that subscription, it will stop playing the sound file and delete the audio player object.

Getting Information Out of a Resource

As written, the above observable doesn’t emit anything. Its only reason for existence is to create and dispose the resource, but it can emit information about the observable. For example, you could have it emit the current play time:

return Observable<Int>.interval(
    .milliseconds(100),
    scheduler: MainScheduler.instance
)
.flatMap { _ in
    Observable.just(audioSession.audioPlayer.currentTime)
}

Putting the above code into the observableFactory closure will let you know something about what’s going on with the resource. More information can be added as well.

Sending Information Into a Resource

You can also send information into the resource using an Observable. For example toggling from the play/pause state.

If you give your resource a dispose bag, you can add yet more to that closure:

togglePlay // an Observable<Void>
.subscribe(onNext: audioSession.audioPlayer.toggle)
.disposed(by: audioSession.disposeBag)

(The toggle() function is an extension I wrote to toggle between play and pause.)

Other Uses for using

So any time you need to create and release resources in your Rx code, the using operator is there to help you. However, it can be used for even more. Anytime you want to call some code during subscription and call other code during dispose, the using operator is your friend.

One of the most interesting ideas I’ve had for the operator is when I treated a UIViewController as a resource. Resource creation makes the view controller and presents it, and disposing the resource dismisses the view controller.

Examples

I have created a generic Resource type that makes it easier to wrap resources along with several examples. If you make resources that you would like to share, by all means send a pull request and I’d love to add it.

Check out my RxResource repository for more.

The way you convert the delegate into Observables depends very much on the kinds of delegate methods and some of them simply can’t be converted. Not all methods can be converted; sometimes the delegate method requires that a calculation be made on the spot in order to return a value and Observables don’t allow that.

The Basics

First let’s cover the basic structure of every delegate proxy. Given a class that uses the delegate and a protocol that defines the delegate from some library:

class Thing: NSObject {
    weak var delegate: ThingDelegate? = nil
}

@objc
protocol ThingDelegate: AnyObject {
    // some number of methods
}

You first have to create the Proxy class. It’s easier to do this if your Thing type can conform to RxCocoa’s HasDelegate protocol, but it’s not a problem if you can’t make that work, it just means implementing a couple of extra methods in your proxy and the compiler will insert the stubs for you.

Here’s the basic shell of every delegate proxy class:

class ThingDelegateProxy
    : DelegateProxy<Thing, ThingDelegate>
    , DelegateProxyType
    , ThingDelegate {

    init(parentObject: Thing) {
        super.init(
            parentObject: parentObject, 
            delegateProxy: ThingDelegateProxy.self
        )
    }

    public static func registerKnownImplementations() {
        self.register { ThingDelegateProxy(parentObject: $0) }
    }
}

extension Reactive where Base: Thing {
    var delegate: ThingDelegateProxy {
        return ThingDelegateProxy.proxy(for: base)
    }
}

Using the above as a base, everything else that is needed will depend on what methods are on the delegate. Are they optional or required? Do they pass a value to the delegate as one or more parameters or do they expect the delegate to return a value? Let’s try to cover each use case.

Optional Method, Passes a Parameter

The most common use case is that the method is optional and it passes one or more parameters to the delegate:

@objc
protocol ThingDelegate: AnyObject {
    @objc optional func thing(
        _ thing: Thing, 
        hasDoneSomething param1: String, 
        with value: Int
    )
}

In cases where the delegate receives the Thing, you can ignore the thing passed back to the delegate because the Rx system creates a different delegate object for each thing. The other value(s) passed into the method should be included in the Observable for use. Simply add something like this to your proxy and you are done:

var hasDoneSomething: Observable<(param1: String, value: Int)> {
    delegate.methodInvoked(
        #selector(ThingDelegate.thing(_:hasDoneSomething:with:))
    )
    .map { ($0[1] as! String, $0[2] as! Int) }
}

Required Method, Passes a Parameter

The next use case is when the method is required.

@objc
protocol ThingDelegate: AnyObject {
    func thing(
        _ thing: Thing, 
        hasDoneSomething param1: String, 
        with value: Int
    )
}

In this case the function may or may not be an @objc method; it doesn’t matter your code will be the same. When confronted with a required method, your delegate proxy must implement the method and it should use a Subject to forward the value(s) on to the Reactive operator.

So you add this to the proxy itself:

func thing(
    _ thing: Thing, 
    hasDoneSomething param1: String, 
    with value: Int
) {
    hasDoneSomething.onNext((param1, value))
}

fileprivate let hasDoneSomething = 
    PublishSubject<(param1: String, value: Int)>()

And add this to the reactive extension:

var hasDoneSomething: Observable<(param1: String, value: Int)> {
    delegate.hasDoneSomething
}

Method Returns a Value

This use case requires you to return a value:

protocol ThingDelegate: AnyObject {
    func thingNeedsSomething(_ thing: Thing) -> String?
}

In this case, it doesn’t matter whether the method is optional or not, you have to handle it the same way. These sorts of methods must be implemented in the delegate proxy and need to be converted into an Observer instead of an Observable.

Here’s what needs to go in your proxy. Notice that you have to provide a default value. Be sure that is the value that the caller uses if the method isn’t implemented.

func thingNeedsSomething(_ thing: Thing) -> String? {
    relay.value
}

fileprivate let needsSomethingRelay = 
    BehaviorRelay<String?>(value: nil)

And then in the Reactive extension put this:

var needsSomething: Binder<String?> {
    Binder(delegate) { del, value in
        del.needsSomethingRelay.accept(value)
    }
}

Method both Passes a Parameter and Returns a Value

Here’s where it gets tricky and you may not be able to provide an Observable. You can only do it if you know ahead of time all the values that will be passed in.

For example if the method looks like this:

protocol ThingDelegate: AnyObject {
    func thingNeedsSomething(
        _ thing: Thing, 
        for item: String) -> Int
}

You would have to know all the possible values that might be passed to item and what you would want to return in order to implement this method as an Observer.

Add this code to your proxy:

func thingNeedsSomething(_ thing: Thing, for item: String) -> Int {
    relay.value[item] ?? 0
}

fileprivate let relay = BehaviorRelay<[String: Int]>(value: [:])

And then in your reactive extension add this code:

var needsSomething: Binder<[String: Int]> {
    Binder(delegate) { del, value in
        del.relay.accept(value)
    }
}

Epilogue

Creating a proxy for your delegates can be a bit of a pain sometimes but they really clean up the point of use and make everything much easier to understand. The next time you are confronted with a new delegate, instead of casting about on the internet trying to find a solution, you now have the knowledge to make the proxy yourself!

As far as I know VIPER was first described in Architecting iOS Apps with VIPER back in June 2014. I decided to revisit this pattern and see how it can be adapted to live in our new, more functional and reactive world.

I have re-implemented the sample that came with the article above, but I also want to take this time to discuss a bit about the process of developing a program with the idea of documenting some of the non-code processes involved in creating an application. (This first part is a reprise of my previous article with specific details about this particular project.)

Definition Phase

For the purposes of this application, we only have one user type and one entity type. The former we will call User and the latter will be ToDo. Now let’s consider the actions. Since this is just a sample app we will only allow the create and read actions. Here are our user stories.

• As a User, I can create a ToDo.
• As a User, I can read all ToDos due this week and next.

Design Phase

In our case, we are expecting two screens. We will call them the List and Add screens. In the process of drawing them out, we have identified another user story as well as steps for all of them. The new story acknowledges the fact that creating a ToDo is a multistep process from the user’s perspective and gives the user the ability to abort the create action.

(-) As a User, I can create a ToDo.
    From the List screen:
        1) Tap the add button to display the Add screen.
        2) Enter a title and date of a ToDo (both are required.)
        3) Tap save button to save ToDo and dismiss ToDo screen.
(-) As a User, I can cancel the create ToDo action.
    From the Add screen:
        1) Tap cancel button to dismiss Add screen without saving.
(-) As a User, I can read all ToDos due this week and next.
    From the List screen:
        * ToDos should be in date order.
        * ToDos should be grouped in the following categories:
            Today, Tomorrow, Later This Week, and Next Week.

Development

We have a solid understanding now of what the user can do and we know what order we are going to develop those features in. We also have detail designs for the screens needed (at least for the first user story) and a list of fonts and colors that will be used throughout the app. Now it’s time to start development.

Before talking about how to adapt VIPER to Rx, I want to clear up a misconception about the architecture. Some people assume that there must be a VIPER (View, Interactor, Presenter, Wireframe) stack for every screen, but that is not at all true. Sometimes a single screen might be involved in multiple user stories at the same time and so will have several interactors. Sometimes a screen might be used for several different stories and have multiple Wireframes and Presenters associated with it. Lastly, sometimes multiple screens might be involved in a single user story and then one Wireframe will display several screens.

Story 1, Step 1: Tap the add button to display the Add screen.

In the first commit, I am implementing the first step of the first user story, “Tap the add button to display the Add screen.” Of course a lot has to be done for this simple step because in order to tap that add button, we need an application. Since the user story starts on the List screen, we need to create that as well, but only in so far as to give it an add button. Notice I haven’t fleshed out the rest of the screen. I went ahead and laid out the entire Add screen since I know I need it for the rest of this story. Also, since this is the step that displays the Add screen and the detail-design calls for a special presentation animation I did that here.

With the original conception of VIPER, each component was a class with several functions. In Rx things are a bit different. Here each component tends to be a single function. So I have the files named based on the component they represent, but each file only contains a single exposed function and possibly some private helper functions.

When the app starts up, the flow is as follows:

1. The ListWireframe is given control.
2. Since the storyboard has already displayed the List screen, the wireframe only needs to install the presenter into the view controller’s buildOutput function.
3. The ListViewController eventually loads, creates its Input object and then passes that input to the buildOutput function.

When the user taps the add button, the flow is as follows:

1. The addItem emits a next event to the list presenter.
2. The list presenter maps that to an add ListAction and emits that to the wireframe.
3. The list wireframe catches the add action and calls displayAdd which is in the AddWireframe.swift file.
4. The add wireframe instantiates the add view controller and presents it.

Story 1, Step 2: Enter a title and date of a ToDo (both are required.)

Much of the functionality of this commit was actually added in the last commit since I laid out the Add screen. However, to help ensure the stipulation that both title and date are required for saving, this is a good time to make sure the save button is only enabled if there is valid input. This is our first real bit of logic so I went ahead and added tests. Tests aren’t often added to sample code so I thought it would be a nice touch.

You will see that the logic is all in the presenters so that’s what is tested. In a properly constructed VIPER system, all of the logic will be in the presenters and interactors. I expect to have a test case for each user story.

Story 1, Step 3: Tap save button to save ToDo and dismiss ToDo screen.

For this step, we created our first interactor. We have also discovered a path not mentioned in the user stories. We need to outline what happens if the save fails. As mentioned, we update the user stories with this newly discovered information.

(-) As a User, I can create a ToDo.
    From the List screen:
        1) Tap the add button to display the Add screen.
        2) Enter a title and date of a ToDo (both are required.)
        3) Tap save button to save ToDo and dismiss ToDo screen.
    Error: If the save fails, instead of dismissing the ToDo screen, 
           an Alert screen displays explaining the error.

One of the defining features of VIPER is that only Interactors work with Entities and the DataStore, the Wireframe injects the DataStore into the Interactor, and the Presenter knows nothing about the DataStore or the Entities.

You will notice that the presenter doesn’t create a Todo object, instead it just passes enough information to the Interactor for it to create the Todo object which then passes it to the DataStore. Then the DataStore converts the Todo object into a form that is savable and saves it.

It’s interesting to note that up to this point, our code has been indistinguishable from an MVVM-C architecture (other than the names of things.) VIPER adds an extra level of indirection between the interactor (view model) and the entities/data store. In MVVM-C, the view model works directly with them both. Personally, I’m not sure if this extra level of indirection is useful. Even in an application this small, I’m left wondering where I should change the date of the object to the startOfDay? Should it be done in the presenter or in the interactor?

Story 2, Step 1: Tap cancel button to dismiss Add screen without saving.

Since the screen and button for this story have already been laid out, it’s just a matter of hooking them up. We add the cancel button to the UI’s input, and then bind it directly to the wireframe’s Observable.

Story 3: Read Todos.

An important thing to notice at this point is all the different ways a “Todo” is represented in the system, even in something as simple as this example program.

• There’s the way the DataStore represents todos internally (in our case, as a plist structure and if we had used CoreData then as NSManagedObjects).
• There’s the way todos are represented internally by the interactors (and externally by the DataStore) as Todo structs.
• There’s the way todos are represented internally by presenters (and externally by interactors.) The list presenter uses UpcomingItem.
• Lastly, theres the way todos are represented internally by view controllers (and externally by presenters.) The list view controller uses UpcomingDisplaySection and UpcomingDisplayItem.

Again I am struck with the difference in complexity between MVVM-C and VIPER; in the former there would only be three different representations of a todo rather than four. Maybe in a larger project it would make more sense; presumably we would find re-use opportunities that wouldn’t otherwise exist? In MVVM-C I’m inclined to create such abstractions when they are discovered rather than assuming them at the outset.

For this story, you will see that most of the changes/additions are mostly dedicated to morphing the data in the stored plist into data the table view can understand over the four stages mentioned above. I also had to modify the AddWireframe so it could notify its parent about successful updates and pass that into the List presenter so it will know when to re-get the list of items.

Epilogue

This was an interesting exercise and I learned a lot about both VIPER and MVVM-C while doing it. Remember, the point of this article is to follow along with the commits. If you aren’t doing that, you won’t get the most out of it. Be sure to check out the repository and follow along.

Definition Phase

The first step in developing an application is to decide what the application is supposed to do. It doesn’t have to be a complete list, but it should include all the functionality that immediately comes to mind.¹ This functionality is specified by a number of User Stories; they consist of a number of entities and they allow a number of different types of user to perform a number of actions with those entities.

Every application will have different entities and different types of user, but most applications are of a CRUD nature. CRUD is an acronym for Create Read Update Delete which are the actions that can be performed on entities. Every entity does not have to have every action, but every action should be considered. Sometimes only certain types of users will be able to perform certain actions on certain entities.

At the end of this process, you will have a list of “user stories”, each of which will define a type of user, an entity and an action that can be performed on that entity.

The deliverable is a list of these user stories along with a list of user types, entities and connections between entities.² (Users may also be represented by entities in the application.)

Design Phase

The next step is to draw out a wireframe. This is often done for websites, but it’s also important for mobile apps. Also during this phase, the processes involved in all the user stories will be augmented with the steps the user needs to go through in order to complete the user story.

These user story steps will start on a particular screen and will detail the actions the user must take in order to complete the story. (i.e., “from screen X, tap button Y, enter Z information, and so on until completion.”)

This phase will produce a list of screens, the functionality (inputs & outputs) available in each screen, connections between screens, as well as a path for each user story from above.

It’s important to remember that this is not a waterfall process. It is quite likely that new user stories will be discovered during this phase along with new entities and users. As they are discovered, a decision will have to be made as to whether these new stories and screens must be in the current version of the application, or can be set aside for a future version.³ If it is determined that they must be included in the current version, then update the wireframe and user story list to include them, and make sure that all stake-holders have buy-in regarding the added scope. These additions will affect costs and deadlines and it’s unprofessional to ignore that fact or try to hide it.

Build Phase

Now it’s time to decide in which order the user stories will be developed. During this process it’s important to take into account any dependencies between stories. If you have stories that deal with sub-entities of some entity then they need to come after the stories about the entities. Each story starts on a particular screen so it is sometimes helpful to group stories by the screen they start on. Lastly, it’s generally easier to develop stories in CRUD order for a particular entity.

The process of developing a user story isn’t just about writing code, each screen also needs a detail-design and decisions need to be made about application wide fonts and colors. All of this can generally be done in parallel; however, it’s best if the detail design of a screen comes before development so that code doesn’t have to be revisited.

And again because this is so important: Even during this process, new user stories, entities and users could be discovered (especially in regard to error paths through stories,) and maybe new screens will be required. If the stake-holders decide they must be in the current version of the application then update the previous deliverables.

1. At Haneke Design, where I am the director of development, we kick off a new project with a Workshop where a Designer, Developer and others sit down with the idea person to define the user stories, as well as design themes.
2. A side note about naming things. In order to foster communication in a team it’s important to be consistent about what things should be called. Naming is hard, but once you pick a name, stick with it. If you absolutely must change it, change it everywhere, including in code.
3. At Haneke Design, we cycle through this process for every version of the application in development, usually once ever three months but, depending on customer, it may be more or less often.

As a reminder, you need to follow along in the GitHub repo in order to get the best out of this article. The first eight commits in the repo are covered in part 1 so let’s start there. Enough preamble, we’re off…

Consolidating the ProgressObserver

Since this is more about changing the semantics of the code, the process is going to be less formulaic. Basically we are looking for places where we are binding/subscribing inside another bind/subscribe, or where we are manipulating a Subject inside a bind/subscribe. For this first step I will focus on the ProgressObserver class since it only has two binds in it. We’ll start small.

Here, the only function is the init and the exposed properties are all lets. This immediately tells us that this entire class could likely be replaced by a single function that takes in the same parameters as the init method and returns the properties as a tuple. Further investigation reveals that name and progress properties aren’t used outside the class and could be made private so the only property we actually need to worry about is the changed computed property. Basically, the only reason this class existed in the original code was to convert from using KVO to a delegate. Now that such conversion is unnecessary, the entire class has become superflous.

As a result, the class functionality has been moved into a Progress extension function. Tests have also been written to ensure correct logic.

Simplifying the ProgressView

Let’s continue to follow the chain from the Progress object into the ProgressView.

First we inline the three functions that used to be a part of the delegate by moving their contents into the subscribe method. We see that there are no Subjects in them, but the terminus in the subscribe’s onNext closure is already a bindable property provided by RxCocoa, so we can make some simplifications there. We also find that the onError and onCompleted closures are merely debug messages. In the interest of code parity I will keep the print messages, the do() operator is great for such things.

Simplifying the SettingsViewController

Boy there’s a lot of logic in this class. The astute among you will notice that the displayName and serviceType validation doesn’t seem to exist in the Objective-C sample code from Apple. They checked validation by using that language’s try/catch system which isn’t available in Swift so I resorted to manually writing the validation logic. It would be nice though if it were more testable. So we will now move it to its own function. There are a lot of conditionals in this function and to achieve basis path coverage would require 13 tests. I’ll leave that as an exercise for the reader. At least now the logic is out where it can be tested without creating a SettingsViewController.

Further inspection shows that, though the done button’s bind function uses self, it does so in order to access the displayName and serviceType strings. So let’s expand our chain to push just those values in. Once we do this and then move the doneTapped code into the bind's closure we end up with:

let inputValues = Observable.combineLatest(displayNameTextField.rx.text.orEmpty, serviceTypeTextField.rx.text.orEmpty) { (displayName: $0, serviceType: $1) }

doneButton.rx.tap
    .withLatestFrom(inputValues)
    .bind(onNext: { [weak self] displayName, serviceType in
        if isValid(displayName: displayName, serviceType: serviceType) {
            self?._didCreateChatRoom.onNext((displayName, serviceType: serviceType))
        }
        else {
            let alert = UIAlertController(title: "Error", message: "You must set a valid room name and your display name", preferredStyle: .alert)
            alert.addAction(UIAlertAction(title: "OK", style: .cancel, handler: nil))
            self?.present(alert, animated: true, completion: nil)
        }
    })
    .disposed(by: disposeBag)

Whenever I see an if...else block in a bind/subscribe function I immediately look to using Observable.filter instead. This will mean we need two observables, one for the true branch and one for the false branch. In the true branch we are just connecting to the subject so we can bind to it directly. In this instance we can’t get rid of the subject because the chain that feeds it doesn’t come into existence until after viewDidLoad is called.

Then there’s the matter of moving our logic out of the view controller so it can be tested independently. The inputs to the logic are the text of the two fields and the done button’s tap. The outputs are to inform the subject when a chat room can be created and to inform the view controller when an error alert needs to be displayed. Note, I didn’t say “either/or” here. The done button can be tapped multiple times and the function must be able to respond with both depending on the logic.

Congratulations are in order here. We just created our first view model.

Simplifying the SessionContainer `received` Observable

The first thing to do here is to inline the delegate functions into their function blocks. Once that is done, we can see that there are three different binds that all affect the _received subject. You want to avoid that as much as possible; it’s a very imperative thing to do. Better would be to have a single chain that expresses the invariant of when/why the subject should emit.

In all three cases, we are taking different sorts of data from the session object and converting them into Transcripts, and once we inline the functions we see that all the real work is being done inside the bind methods. Let’s extract that work into maps and then extract the logic into single, testable, operators. So that the only things left in the bind functions are the subject.

To complete this simplification, we only need to remove the binds, merge the three observables, and bind the merged observable once. Wait, we are in the init function, so we can get rid of the subject completly and directly assign to the received observable.

Simplifying the SessionContainer `didFinishReceivingResource` Closure

Here we see error objects, but we have to be careful because Observable errors will shutdown a stream and we don’t want that happening. Also, like earlier, we see a condition inside a bind. Actually, there are two ways the bind can error for a total of three different possible outputs.

Three different outputs calls for three different observable chains. Also, we see that a side effect (copying the image) happens where the results are required for later. Side effects are for beginnings and ends of observable chains, so we need to create an observable in which this side effect is performed. This became the copyItem(resourceName:localURL:) function. Since this effect can error, and we don’t want the error to break the chain, we use materialize() here.

We can’t get rid of the _update subject just yet because it is also used in the send(imageURL:) function.

Consolidating the MainViewController’s `sendMessageButton` Output

I see that this program suffers from “Massive View Controller” syndrome. Despite it’s small size, the main view controller is playing god. RxSwift isn’t an architecture and doesn’t avoid this anti-pattern on its own, but it does provide opportunities to use architectures that will help avoid the problem. That said, it isn’t the goal of this article to discuss architecture, we are only looking to simplify the code we have.

For a first step in simplifying the MainViewController, I see that there are two different observable chains that affect the sendMessageButton's isEnabled property. Let’s move those together. This is something I call Output Centric programming. The idea is that there is a single place in the code to see all the inputs that can affect a single piece of output. By doing this, the chain for that output becomes its invariant. It makes explicit exactly what behaviors affect this particular output and how they do so.

At this point, you might wonder about the text in messageComposeTextField. In one chain we listen to editingDidEnd and set the text to an empty string, while in the other chain we listen to the same event and read the text to use it. This is safe because programmatically changing the text does not cause an event to emit. That said, there is some odd behavior for the RxCocoa text attribute because it emits on editingDidEnd events. Since we want to emit false on editingDidEnd regardless of the contents of the field, we need to guard against that extra emission. Therefore we have to add the distinctUntilChanged() function.

Separating the text clearing behavior

In the spirit of the output centric approach mentioned above, we should limit the behavior in a subscribe/bind block as much as possible. To that end, let’s create a new observable chain just for clearing the text field.

Simplifying and Correcting the Send Text Feature

While writing the above and making the refactoring, I realized that the sample source has a rather subtle bug in it. The text is sent when the textField’s editingDidEnd event emits which happens when the field resigns first responder status. Tapping the send button or return on the keyboard causes the field to resign, but the field will also resign when some other view controller is presented (which would happen when the user taps one of the other buttons on the screen.) This surprising behavior slipped through the original sample because of the indirectness of the code. Do we really want to send whatever text is in the field whenever the keyboard drops? Not likely. Do we really want the keyboard to drop every time the user sends text? Also not likely.

Correct behavior is to send the text when the send button or return key is tapped and keep the keyboard up so the user is ready to send more text. We can fix that simply by replacing messageComposeTextField.rx.controlEvent(.editingDidEnd) with sendMessageButton.rx.tap and removing the code that causes the keyboard to dismiss in those situations. So let’s do that now.

Inlining All the Things!

You might have noticed that I’m doing a lot of inlining of functions in the main view controller. Let’s take a break from the hard stuff and inline all the functions that are only called once and only in an already existing closure. We will keep createSession() and insert(transcript:) for now since they are referenced from multiple places, but the rest of the private functions are going away.

Removing Nested Subscribes: `browseForPeers`

Seeing a disposeBag referenced inside a subscribe closure is a sure sign that we have some inapproprate nesting. I’ll start at the top and deal with the chain that presents the MCBrowserViewController.

The createWithParent function is cribbed from sample code that is distributed with the RxSwift package. There’s a lot of good stuff in there.

Extracting the UIAlertController Presentation

What happens when the sendPhotoButton is tapped? The first bit is easy, request authorization, but then we get into this massive bind closure. We know what happens inside that closure because we have run the program an know what needs to happen, but reading it is not very obvious. It creates and presents an action sheet to get configuration parameters for the image picker, then creates and presents the image picker to get the user’s image, then switches to a background thread to save the image and send it to the session container, then switches back to the main thread to insert the generated transcript into the table view. That’s entirely too much work for one closure.

Also, notice how I presented the behavior as a list of steps, but when you look at the code you see that these steps are deeply intwined. I have already written a blog post about this sort of code. That post was in the context of Promises, but the same ideas apply to Observables.

Fixing this closure is a big job so we will do it in stages starting at the top: presenting the UIAlertController to figure out how to configure the image picker.

Extracting the UIImagePickerController Presentation

This will be the third view controller that we have presented so it should be pretty obvious what’s going on here. I also cleaned up the UIAlertController presentation closure a bit.

Un-nesting `didFinishPickingMediaWithInfo`

The next step is small but highly instructive so I am giving it its own commit. Whenever you see a bind/subscribe where the first thing that happens within it is another bind/subscribe, you know a simple flatMap wrap like what I do in this commit is the right choice. Always keep an eye out for this sort of code.

Taking Advantage of RxSwift Async Abilities

With the above, we have gotten rid of all the nested binds but there’s still a lot of code in that bind closure. It dismisses the image picker, switches to a background thread to save and send the image then switches back to the foreground thread to insert the image into the tableView. Surely we can do more here…

In this commit we manage to tease out what little logic there is in this chain by creating the imageData(from:) and imageUrl(with:) functions, but this observable chain is almost exclusively side effects hence all the flatMaps.

We also found a couple of other places that were using DispatchQueues and changed them to use Schedulers.

Epilogue: What’s Left?

There’s certainly more that can be done! I haven’t wrapped the table view’s data for example. Also, I could re-architect the code to use a MVVM approach rather than its current ad-hoc setup. Lastly, I have separated some logic out of the main view controller but I didn’t add the tests yet.

I will likely refine the code when time permits. Expect to see more pull requests and I will include commit comments that explain the changes. Also, pull requests are welcome.

I have tutored lots of people in RxSwift over the years and it has been my experience that if they try to go “full Rx” right away they will end up with a mess of code that is harder to understand than anything they have ever written. Because of this, I recommend integrating Rx into your code slowly and with intention.

In order to effectively integrate Rx into your app you first have to identify two kinds of functions: pull type and push type. The first type of function returns values when called and is used to “pull” or get information from objects. The second type takes values as parameters and doesn’t return anything and is used to “push” or set information into objects. (Watch out, there are also functions that do both.) Rx strongly favors push type functions, so if your style also favors push functions, then the integration will be more effective.

If the code base you are starting with favors a push style, then you will find it much easier to integrate Rx and will be able to do it more fully. Fortunately, Apple’s frameworks also favor push style code, so that should help reduce the friction.

For this post, I assume you have already read some tutorials and understand what an Observable, Observer and Subject are. I also assume that you know at least how merge, map, flatMap and filter work and are comfortable looking up other operators as you go along.

There are seven different systems used in iOS code to push data from one object to another:

• closures
• target/action (UIControl aka IBAction)
• delegates
• notifications (NotificationCenter)
• KVO
• setting variables
• sub-classing abstract base classes

A lot of the complexity of writing an application comes from trying to integrate these various systems into a unified whole. Each of the systems individually is simple to use, but weaving them together makes our code complex. One of the benefits of using RxSwift is that it wraps all of the above systems into a single powerful mechanism, thus making our code less complex overall.

Knowing the above gives a clue on how to go about integrating RxSwift into an existing project. If RxSwift can replace all those other technologies, then to integrate means to replace them with it. Once this is done, we will be able to make the code more declarative and less complex.

For this article, I’ve decided to use an old sample from Apple, MultipeerGroupChat. This code was originally written for iOS 7 and Objective-C but that won’t do for our purposes so I updated the code to Swift.

If you look at the first commit of the sample code in my GitHub repo, you will find a rather straightforward reimplementation of Apple’s sample code. There are some quirks about the code (not the least of which stems from the fact that all phones were the same width back then,) but our job isn’t to fix those. Rather our goal will be to integrate RxSwift into the program and along the way see how it gets transformed.

Each of this article’s section titles corresponds to a commit in the repository so it’s easy to follow along in the code. Be sure to use the code analysis tools in GitHub or Xcode to compare before-and-after changes. If you aren’t doing this, you won’t be able to understand what’s going on.

I picked this particular sample because it has a nice mix of target/action, delegates, notifications and even a sprinkling of KVO so there’s a lot to work with. Let’s get started, shall we?

Replacing IBActions

For our first step, we will start with something easy — replacing IBActions with observables. This is as simple as:

1. Make sure that the input that triggers the action is an IBOutlet in the view.
2. Make sure that RxSwift and RxCocoa have been imported into the view’s file.
3. Make sure the view has a DisposeBag
4. In the view’s initializer (for a UIView this would be the awakeFromNib method, for a UIViewController it would be the viewDidLoad method) subscribe to an Observable on the input that just calls the action.

As an example of this, in the MainViewController of our sample, there is an @IBAction called browseForPeers(_:). We see that the button that triggers this action isn’t an IBOutlet so first we do that, then we put this in the viewDidLoad:

browseForPeersButton.rx.tap
   .bind(onNext: { [weak self] in self?.browseForPeers() })
   .disposed(by: disposeBag)

In this case, the browseForPeers method takes a sender which we don’t need so we update the function signature from @IBAction func browseForPeers(_ sender: Any) to simply func browseForPeers().

Replacing Delegates: Removing App Specific Protocols

This is a much larger topic and there are a lot of delegates in the code we are working with, so I will break it up into stages. We see two basic sorts of delegates in this code — those provided by libraries (for e.g., MCBrowserViewControllerDelegate) and those created custom for this app (e.g., SessionContainerDelegate.) For the first sort we are forced to use the DelegateProxy class provided by RxCocoa; for the latter sort I recommend doing away with them completely.

We will start with removing the special purpose delegates. The basic process is again pretty mechanical.

1. Create a private PublishSubject for each function in the delegate protocol.
2. Create a computed property that returns each of the publish subjects as an observable.
3. Remove the delegate property and replace calls to it to onNext calls to the correct publish subject.
4. In the object that conforms to the delegate, remove the protocol conformance and replace with binders to each observable created in step 2.

A simple example is the SettingViewControllerDelegate which only has one method. The purpose of the protocol is to push out the new displayName and serviceType strings so our observable will want to do likewise.

We create the new didCreateChatRoom Observable:

var didCreateChatRoom: Observable<(displayName: String, serviceType: String)> {
 return _didCreateChatRoom.asObservable()
 }

private let _didCreateChatRoom = PublishSubject<(displayName: String, serviceType: String)>()

And then call its onNext function, instead of the delegate’s method, which will allow us to do away with the protocol. Meanwhile in the MainViewController, we bind to the new observable and remove the protocol conformance. You will notice that when I removed the conformance, I didn’t actually remove the function. Instead I just changed its signature so it no longer accepts a SettingsViewController and called that function from within the bind closure.

I need to make a special mention of the ProgressObserver's delegate. It contains three functions (changed, canceled, completed) and the semantics of them went well with those of an observable event (next, error, completed) so instead of making three observables, I just went with one.

Replacing Delegates: Wrapping iOS provided protocols

Sadly, creating wrappers using the DelegateProxy class provided by RxCocoa is outside of the scope of this article. I will have to give it its own treatment later. However, once you have them, replacing the protocol conformance with observables is something that we will cover. The steps are:

1. Remove the protocol conformance tag from the class/extension.
2. At the point where the delegate was getting set, replace that setter with the needed subscriptions to the various observables.

For example, getting data from a UIImagePickerController requires that we add the rx.didCancel and rx.didFinishPickingMediaWithInfo binders.

imagePicker.rx.didCancel
    .bind(onNext: { [weak self] in
        self?.imagePickerControllerDidCancel()
    })
    .disposed(by: disposeBag)
imagePicker.rx.didFinishPickingMediaWithInfo
    .bind(onNext: { [weak self] info in
        self?.didFinishPickingMediaWithInfo(info)
    })
    .disposed(by: disposeBag)

Another special mention needs to be made here, this time about UITextFieldDelegate. This particular delegate is often used incorrectly (even in Apple sample code) and can almost always be replaced by IBActions. That is the case here and since we already covered IBActions, I have simply made the replacement directly to observables.

Replacing Notification Observers

There are a number of problems with the sample code surrounding keyboard display and dismissal. I assume that the bugs exist because of changes in how the keyboard notifications work. Rather than just a mechanical replacement, we are forced to do a rewrite of the moveToolBar function.

Fixing a photo capture bug

During routine testing, I noticed that the app was unable to capture and send photos. I realized the problem was two fold. First, the operating system now requires the app to explicitly ask for permission to access photos, and second, the UIImagePicker delegate proxy I cribbed from the RxSwift sample code is out of date. To fix these, I wrote my own UIImagePicker delegate proxy, included the required permission strings, and added the request authorization method. This later is a good example of how to wrap an OS function that requires a callback and returns Void.

extension Reactive where Base: PHPhotoLibrary {
    static var requestAuthorization: Observable<PHAuthorizationStatus> {
        return Observable.create { observer in
            Base.requestAuthorization { status in
                observer.onNext(status)
                observer.onCompleted()
            }
            return Disposables.create()
        }
    }
}

Replacing KVO

This app uses KVO inside the ProgressObserver class to observe the Progress object. It observes two properties of the progress object, cancelled and completedUnitCount. Whenever either of them is updated, the appropriate bound observer will be called. You will see that now each observed key-value gets its own closure rather than having to route all of them through a single function and since the dispose bag takes care of cleanup for us, we can do away with the deinit function.

Interlude

Wow, that was a lot of work and a pretty big word count for some fairly mechanical code refactoring. I did some runs of the app throughout the refactoring but by and large I knew that behavior wasn’t changing so I wasn’t concerned. It would be nice to test the logic, but the logic was so interwoven with the effects and so much of the code was about translating from one observation system to another that, up to this point, writing the tests would have been very difficult.

Now that we have most of the code converted to using RxSwift, we can start removing a lot of it and tease out the logic for testing. When you are ready, check out Part 2.

The Value of flatMap

The flatMap method makes it easy for us to do a couple of different things that would have been hard to do otherwise. First, it allows us to increase the number of events being produced by an Observable stream. Second, it allows us to perform some asynchronous work as part of the stream.

For an example of the first idea we have this:

let string = Observable.of("a", "b", "c")
string
    .flatMap { Observable.of("\($0)-x", "\($0)-y", "\($0)-z") }
    .subscribe(onNext: { element in
        print(element) // this prints 9 values.
    })

An example of the second idea is something like this:

string
    .flatMap { URLSession.shared.rx.data(request: URLRequest(url: URL(string: "http://myserver.com/api/get_user?id=\($0)")!)) }
    .subscribe(onNext: { element in
        print(element) // this prints the result of the 3 network requests.
    })

The RxSwift library provides four ways to flatten observables and it’s important to understand the differences.

The Choices and Their Differences

The RxSwift library gives us four different flatMap methods:

flatMap

The basic flatMap merges the results from all the sub-Observables into one Observable. Every time the source emits a value, flatMap will create a new sub-Observable and subscribe to it, merging results of all the sub-Observables into one. There is no guarantee about the order of the outputs. If any of them emit an error, it will immediately shut down all the others and emit the error. The operator won’t emit a completed event until the source and all the sub-Observables have emitted completed events.

flatMapLatest

This is probably the most commonly used flatMap. When its source emits the first value, flatMapLatest will create a new sub-Observable and emit its next events. Unlike the flatMap above, if the source emits another value before the sub-Observable completes, then flatMapLatest will dispose the current sub-Observable before starting the new one.

It’s the cancelation ability that makes this operator so popular. If you don’t need the results of the network request anymore because the inputs have changed, then flatMapLatest is what you want.

flatMapFirst

Occasionally, you don’t want to cancel the sub-Observable and instead you would rather ignore events from the source until the sub-Observable is done. This is what flatMapFirst is for. Like flatMapLatest, it only allows one sub-Observable at a time. Unlike flatMapLatest, it will not cancel an ongoing sub-Observable. Instead it ignores events from the source until the sub-Observable is done.

concatMap

Like flatMap, the concatMap operator will create a sub-Observable for every event from the source, but this one guarantees the order of the output. It will only subscribe to one sub-Observable at a time and won’t subscribe to the next sub-Observable until the current one completes. Unlike flatMapFirst, it won’t ignore other events, instead is will buffer them to use when it’s ready.

Summary

These four flatMap operators give us a lot of flexibility to handle events. We can merge them all together, track the most recently emitted one, track the first one and ignore other events until it’s done, or track one at a time and buffer other events in a queue for later use. What else could you want?

RxSwift and Handling Invalid Tokens

I was recently asked to help with creating a system that would reauthorize a user when a 401 was encountered during a network request. After reauthorizing the user, it should retry the request with the new token. Because the word “retry” was used, I immediately thought of the `retry` operator, but in retrospect it might have been better to use `catchError`… That said, here is what I ended up with and my thought process while developing it.

First I roughed out what I need:

1. Since URLRequests will potentially need to be created with new tokens, I need a function that can create a request when given a token.
2. Since retryWhen provides an Observable<Error> that emits every error the stream throws, I need a function that will refresh the token and emit a trigger event on unauthorized errors while passing all other errors down the line.
3. Since multiple requests could be unauthorized while the service is waiting for a new token, I need a way to notify all the requests once the token is provided.

Lastly, since this is going to be a pretty complex job, I need to make sure I can test it without involving the network.

Because of requirement (3) I know that there will have to be some sort of object that can bind all the requests together and this object is primarally in charge of acquiring new tokens when needed. I’ll name it’s class TokenAcquisitionService. This object will also provide the most recent token on request.

With all of the above information. I can expect a function definition like this:

/**
 Builds and makes network requests using the token provided by the 
     service. Will request a new token and retry if the result is an 
     unauthorized (401) error.

 - parameter response: A function that sends requests to the network 
     and emits responses. Can be for example 
     `URLSession.shared.rx.response`
 - parameter tokenAcquisitionService: The object responsible for 
     tracking the auth token. All requests should use the same 
     object.
 - parameter request: A function that can build the request when 
     given a token.
 - returns: response of a guaranteed authorized network request.
 **/
typealias Response = (URLRequst) -> Observable<(response: HTTPURLResponse, data: Data)>
typealias Request = (String) -> URLRequest

func getData(response: @escaping Response, tokenAcquisitionService: TokenAcquisitionService, request: @escaping Request) -> Observable<(response: HTTPURLResponse, data: Data)> {
    return Observable
        .deferred { tokenAcquisitionService.token.take(1) }
        .map { request($0) }
        .flatMap { response($0) }
        .map { response in
            guard response.response.statusCode != 401 else { throw ResponseError.unauthorized }
            return response
        }
        .retryWhen { $0.renewToken(with: tokenAcquisitionService) }
}

As you can see above, code isn’t pretty when it’s in a Medium post. The RetryingTokenNetworkService code can be found here.

An explanation of the above function is as follows:

• .deferred { tokenAcquisitionService.token.take(1) } will subscribe to, and pass on, the token emitted by the service whenever this observable is subscribed to. In effect, when the request is started and whenever it is retried, this line will get the latest token from the service.
• .map { request($0) } will build the request with the token provided.
• .flatMap { response($0) } will send the network request and wait for the response.
• guard response.response.statusCode != 401 else { throw ResponseError.unauthorized } will cause the observable to emit an error if the response was rejected for being unauthorized.
• .retryWhen { $0.renewToken(with: tokenAcquisitionService) } will give the service a chance to handle the .unauthorized error, but pass on any other error.

You can use the above function with any network layer you care to name, whether that’s Alamofire, URLSession or whatever, as long as the layer allows the creation of the (URLRequest) -> Observable<(response: HTTPURLResponse, data: Data)> function. Because I used a function definition here instead of tying my code to a particular service, it can be used with any of them and allows for easier testing.

The TokenAcquisitionService itself consists of two functions and a property (along with some private properties.) The code in the gist above has doc comments so I will just explain how they work here rather than what they do. Be sure to read the doc comments in the gist before you continue with the below.

func trackErrors(for:)

In this method, I start with the source object as an observable.

• guard (error as? ResponseError) == .unauthorized else { throw error} will throw any error other than the one it is watching for. The idea is that if something else goes wrong, the calling code would want to know. An .unauthorized error will cause a next event to emit.
• do(onNext:) The block handed to this operator will send a next event to the private Subject that handles the chain which gets a new token. This is run through a subject because all the network requests that need to retry must be merged together so they can all be notified once the new token is acquired. The recursive lock guards the subject against events from different threads.
• filter { _ in false } eats all the next events emitted by the chain. This is because we don’t want to trigger a retry until after the new token has been acquired, but we still want to pass on any stop events (completed or an error other than an unauthorized network request.)
• Observable.merge(token.skip(1).map { _ in }, error) Remember that subscriptions to token will immediately receive a next event but this is unnecessary because we already know that the current token is invalid. We want the trigger for the next token. We also want all the stop events from the error observable (remember, this observable won’t emit next events.

init(initialToken:getToken:extractToken:)

In here is the code that actually refreshes the token. Keep in mind that this is the code that all unauthorized network requests will be subscribed to, as well as any streams that want to know what the current token is and when it changes.

• relay.flatMapFirst { getToken() } is the line that requests a new token and makes sure that only one request is made for each batch of unauthorized requests that are waiting.
• guard urlResponse.response.statusCode / 100 == 2 else { throw ResponseError.refusedToken(response: urlResponse.response, data: urlResponse.data) } will inform all listening requests that the service was unable to successfully extract a token, otherwise it will extract the token and emit it.
• startWith(initialToken) ensures that the token property is pre-loaded with a value.
• share(replay: 1) ensures that any observers that subscribe to the token property will immediately get the most recently acquired token value so they can attempt the first request.

FAQ:

What if I have to display a login screen in order to get a new auth token?

You could do that inside the getToken function that is passed into the service. It could even make a get token request with the server and if that fails, present a screen to the user and make another get token request. You could put a `retry(3)` in there to give the user a few chances. On an ultimate failure you could either throw an error, or push out a response with a non-200 series status code (even a 401. If a 401 occurs during the getToken attempt the service will emit an error.)

Combine Latest

The combineLatest operator is used whenever you have two or more observables emitting values, and you want access to the latest value emitted from each of them whenever one of them emits a new value. It can be used, for example, to combine a username and password to make a login request.

func example(username: Observable<String>, password: Observable<String>) {
    let credentials: Observable<(String, String)> = Observable.combineLatest(username, password)
    //...
}

It also comes in handy when you have an array of Observables, and you want to convert them into an Observable that emits an array.

func example(imageObservables: [Observable<UIImage>]) {
    let images: Observable<[UIImage]> = Observable.combineLatest(imageObservables)
    //...
}

Sometimes, one of the Observables will emit several values before all of them have. The combineLatest operator will ignore those values until such time as all the constituents have emitted a value. If you don't want to miss out on any such values, then it's best to use startWith to provide defaults:

func example(pageNumber: Observable<Int>, searchTerm: Observable<String>) {
    let pageAndTerm: Observable<(Int, String)> = Observable.combineLatest(pageNumber.startWith(1), searchTerm)
    //...
}

On occasion you need to use a value emitted by an Observable to create a new Observable, but you want to tie the value with the new Observable. For this, you can use just to lift the value back up into an Observable and combine it:

func example(pageNumber: Observable<Int>) {
    let pageAndItems: Observable<(Int, [Item])> = pageNumber
        .flatMapLatest { page in
            Observable.combineLatest(Observable.just(page), getItems(forPage: page))
        }
}

You could also do the above with an additional map:

func example(pageNumber: Observable<Int>) {
    let pageAndItems: Observable<(Int, [Item])> = pageNumber
        .flatMapLatest { page in 
            getItems(forPage: page)
                .map { (page, $0) }
        }
}

Zip

Then there are times where you want to fire off a bunch of Observables, then wait until they all emit a value. If you know they will all emit no more than one value, you could use combineLatest. However, it's probably more expressive of intent if you use zip.

func example(imageServerRequests requests: [Single<Data>]) {
    let images: Observable<[Data]> = Observable.zip(requests)
    //...
}

The zip operator also comes in handy if an Observable is emitting values too fast and you want to slow it down. Normally, from will emit all of the values in the array immediately upon subscription; by zipping it with an Observable that emits its values slowly, you can force from to slow down.

func example(imageURLs: [URL]) {
    let values: Observable<URL> = Observable.zip(Observable.from(imageURLs), Observable.interval(3, scheduler: MainScheduler.instance), resultSelector: { $0 })
    //...
}

Merge

There are times when you have data coming from several possible sources and you want to treat it all the same; this is especially true with Void Observables which act as action triggers. For this merge is a great choice.

func example(pullToRefresh: Observable<Void>, tapToRefresh: Observable<Void>) {
    let refresh: Observable<Void> = Observable.merge(pullToRefresh, tapToRefresh)
    // ...
}

Another common use of merge is when you have Observables that perform different actions on the same (usually) piece of state. In these cases you don't exactly want to combine the emissions, rather you need them to come through one at a time, but you need to distinguish between them.

func example(startOver: Observable<Void>, nextPage: Observable<Void>) {
    enum Action {
        case startOver
        case nextPage
    }

let action: Observable<Action> = Observable.merge(startOver.map { .startOver }, nextPage.map { .nextPage })
}

WithLatestFrom

Sometimes you want to combine observables, but you only want an event when one of them fires, not both. In that case, you use withLatestFrom(_:_:).

let selectedFamilyMember = input.selectedIndex
    .withLatestFrom(familyMembers) { $1[$0.row] }

There is also a withLatestFrom(_:) that will give you the latest emission of the second observable and ignore the emission from the first observable. That version is great for triggers and is the one that is most commonly used.

Concat

Lastly, there are times when you want to fire off a bunch of Observables in sequence rather than all at once, but you still want to collect up all the results. The concat operator is good for that.

let results = Observable.concat(networkRequests)

This will cause all the Observables in the networkRequests array to be subscribed to one at a time. The next one in the sequence won’t be subscribed to until the previous one completes. Make sure that the inner observables emit completion events or it will never finish.

Another great source to get a sence of how these operators work is in the Combining_Operators playground. Always be sure to check the official docs when you have any questions about an operator. Every one of them is well documented both as a doc comment and within a playground.

I hope this little tour of the combining operators helps out. If I got anything wrong, or your have better, or other, examples then by all means send me a DM on slack, twitter or reddit (danielt1263) or just leave a comment here.