Application Data Flow: Part One
Working With Stores
Demo CodeBefore we get stated, if you saw store in the title and thought this was something to do with a commerce app, unfortunately it does not. In this instance, Store is in regards to a particular way of organizing storage and retrieval of data for the application.
Okay, now that we have that out of the way, today we are going to be talking about application data flow. While the topic may not sound super interesting, having a good handle on the river of information flowing through your application will, in the long run, save you a lot time.
Order From Chaos
How often do you sit down and sketch out a rough outline of an application before you start building? Regularly? Not at all? If it is regularly, how much of that time is spent mapping the data and application state and how much of it is on planning UI?
The truth is not nearly as many people spend time planning the data as on the UI. And why not, there are tons of really great tools like Sketch for planning UI, and there tons of blogs and other resources for learning more about planning your UI. Planning your data isn’t nearly half the fun. But, if you do it properly, spending the time to do it will save you double the trouble.
Chaos From Organization
If you think about it, someone starting without much experience and using MVC in iOS as their guide could end up with code that structured in any number of ways. There are very few constraints or even signposts for them to follow. The sign post that is clearly visible is generally held onto like a life raft. This is why so much beginner code ends up in the ViewController and in particular viewDidLoad. Without much else to reference, this becomes their organizing principle.
An Open Canvas
Beyond the implementation of the base UI classes, there are almost no decisions made for you you as a programmer. This open canvas is often the source of frustration when you start out, because at that stage you really want to know where you should go. But as you feel more comfortable having this free space opens up new possibilities, it is a great place to explore.
MVC
For this example we will be working with something close to plain vanilla MVC. In the past, I must admit that I’ve had an unnecessarily harsh opinion of the the standard MVC that iOS uses. Mainly this was due to my own impatience. Given a little time, and the proper implementation, MVC can work really well.
While there are view models in the demo project, there’s nothing particularly fancy about the code, no RxSwift, no coordinators. For all intents and purposes it’s vanilla MVC, the tableview cell models are structured like this:
Data Flow
Before we go any further I just want to clarify a term: data flow. When I refer to data flow in an application, I’m referring to how data is passed along through the application from the source to display and how that is structured. It encompasses everything from API response all the way to the data model and ultimately to the rendering of the data.
For the level of importance it has, it doesn’t get nearly the amount that it deserves. I’d be willing to bet that a lot of my own hangups when I first learning networking calls and started building more complex applications came from the fact that I didn’t really think through the path that my data would take through the application. Hopefully it’ll become more clear just how important it is go forward with the demo code.
The Synchronizer
The Synchronizer is a class bound protocol. When implemented it allows your controller to subscribe to object that is updating the data model. That way it can act accordingly. In the example that I’ve given. When the data model adds a new item, the controller is notified through its subscription with the Synchronizer. It can then synchronize the data and the view.
The Sync
The Sync, maintains the connection between the controller and object that updates the data. The sync message is sent when you feel that your data has completed updating. This could be at the end of an API call or a CoreData fetch.
Store
The store coordinates the flow and holds the data. In base form it is just a protocol that defines certain characteristics. It becomes useful when you implement it for specific data and tasks.
ItemStore
This class conforms to the Store protocol and is specialized to handle the applications main data model, which I’ve ceremoniously named Item. ItemStore implements the Store functionality plus some specialized code.
TableViewDataSource
The TableViewDataSource in this implementation does double duty as a datasource and as a view model. It serves as the intermediary between the data and the view and the controller. If I had one reservation about this class, it is that it is starting edge close to the line of having multiple purposes. It might be better to separate out the interface between the data and the view modeling into separate classes. The goal is to create a clear separation between the model and the controller, and the view and model. In part two you may see this revised to create a clean separation.
ViewController
Finally, this would not be complete (nor would it run) without the ViewController. To the extent that we can keep logic out of this class is best. If you find that a lot of view logic is happening in the controller, or API logic, this is a good hint that encapsulation has broken down, and that other objects have not been fully implemented and that the classes are not following proper encapsulation. Within a reasonable degree, try to keep properties private. If for some reason you need to modify or access that property, create a method to facilitate that. If your ViewController can’t see that a property exists, it is much less likely to start performing logic with it.
Database
Finally, I’ll just append the data storage parts to the end. These are the components that handle the storage and retrieval of the data to the disk directly. They’ve been split into the reading and writing functionalities as protocols which are implemented in the database class.
Writer
Reader
Database:
In the database class we bring both the DataWriter and DataReader protocols together in an implementation using generic T that conforms to Codeable
Resources:
