So far we have created a reliable source of data for our app, and we now we will work towards creating a communication between data and view.
The MVC architecture proposed by Apple official documentation is the most intuitive for new developers. This architecture is sufficient for simple application and small teams, but the tendency when following MVC is to centralize all the code into UIViewController classes, which turns your application hard to understand and susceptible to bugs.
First of all I want to make clear this is a very subjective concept, influenced by factors like: complexity of the features, team size, definition and restrictions of quality, level of reusability of components, technical skills of the developers, and also the developer experience with the architecture.
Personally, I had prioritized 3 basic principles when defining the architecture of an app:
The solution I will propose here is not supposed to be considered a silver bullet, but it’s definetely better than the common MVC and relatively easy to learn.
By choosing to use ReSwift I’ve obtained an architecture and also a data flow pattern.
The components of ReSwift are:
The code below defines the “State”:
The main struct here is the FetchedPlacesState , which has to conforms to the StateType protocol of ReSwift. This struct contains an enum representing all possible three states of the app:
The Equatable extensions are necessary for unit tests only.
The Actions structs are represented below:
The only piece missing now is the Reducer :
Now that we have all the code in place, it’s now clear to observe that the returned State is a function of an Action and the previous State .
There are a few details I’d like to point in the Reducer code:
To test our state management, I’ve decided to write some Reducer tests to ensure the state transitions are done correctly:
Translating into code, this is how it looks like:
Now with the state management implemented, we have all the data and its transitions needed to display into an user interface. The automated tests in conjunction with the continuous integration tools make our application more robust and the developers more confident to ship this code into production.
I hope you could’ve learned something and improved yourselves as developers!
Build a Foursquare clone iOS app — Part 6: State management was originally published in iOS App Development on Medium, where people are continuing the conversation by highlighting and responding to this story.
Powered by WPeMatico