Implementing Flux in iOS

When most people think of Flux they imagine a React.js web application using a bunch of different frameworks to get all the magic of Flux working. But Flux is not a javascript framework, in fact it’s not a framework at all — it’s an architectural design pattern. There’s nothing stopping us from implementing this pattern on any platform other than the idea that iOS and Android have their own design patterns already. This is not entirely true. Yes, they have an implementation of MVC but on both platforms it’s quite vague, confusing and a lot of times contradicting. If you have more than just a couple of simple views talking to a web API not having a well-defined architecture become a big problem and a source of a lot of technical debt.

This is why, here at Lean Walk, we started using Flux in our native apps. Despite the lack of any frameworks we came up with our own implementation that’s easy to set up and use. Here’s how we did it…

This article assumes you are already familiar with Flux but if that’s not the case here is a resource to get started:

Let’s start with the Action class:

It is quite straightforward, you can choose to make it generic but as it is passed around through an event bus there’s very little benefit to this.

The ActionType can be just a simple enum.

Make sure you inherit from String as the event bus library would require it as an identifier for the event and the registering subscribers. This will make more sense when we look at the Dispatcher.

The ActionsCreator is there to help the view with creating and dispatching actions. Above I’ve included some example code that would call a web API and retrieve some user data. What you do in here exactly can vary but ultimately you would always dispatch an action.

Next up is the Dispatcher:

We are using SwiftEventBus, but you can even use the platform’s NSNotificationCenter to implement the observer pattern.

Let’s go through the above code. Firstly we dispatch actions to all subscribers of the event bus (usually stores). We also provide a way to emit store change events and subscribe stores and views to actions and events respectively. Notice that the register and dispatch methods are using a background thread, this ensures your UI thread is not locked by a long-running process regardless of your service API implementation.

After you dispatch an action the store will be updated:

We use Inversion of Control to create single instances of our stores on application start, which is why registering to certain actions is done in the initializer.

handleLoggedIn will be called every time the LoggedInUser action is dispatched which will update the state of the store and then emit a change event.

Next is where the whole cycle starts and ends — the View. Or in iOS terms the ViewController.

First, in the loginBtnTapped method we call the ActionsCreator, which will ultimately dispatch an action and update the store.

Then, we bind the ViewController to LoggedIn store change event. After a successful login the onLoggedIn method will be called displaying a greeting.