Criticism targeting MVVM (Model–View–View-Model) from late last year essentially points out it’s not the silver bullet some take it for. Most of the stuff is missing the point. How are you supposed to make sense of it? What’s good advice for your project?
Today was the second time during the development of TableFlip that I started to implement a new feature in the wrong way: starting with an explicit event type that is triggered by pressing a button in the user interface. This is a 1:1 mapping of user intent to an event that performs changes in the model. Next time I’ll start from another point of view instead to not rush too many minuscule changes until I hit a roadblock and hate myself. Here’s what went wrong.
Now that TableFlip is nearing completion, I want to share details of how I created this piece of software with you. Today, I’ll start with the bigger picture: the application architecture. Earlier this year, I got to know ReSwift from a talk by Benjamin Encz which I loved.
In a top secret project I am working on, I think I found a consistent way to create UITableViewControllers in a reusable fashion without making a mess with massive view controllers. The key ingredient is, as always, delegation from the view controller and thus composing larger components:
It happens that just yesterday I read about architecture smells in code. Among the examples was “subclasses don’t redefine methods”. In my post about Core Data and expressive domains earlier this week, I did just that: create a Egg subclass of CoreDataEgg to inherit CoreDataEgg’s behavior. That’s not what abstraction to superclasses is meant to do.
I’ve written a whole book on the topic of architecting a Mac app using Core Data. Today I found an approach which doesn’t add lots of overhead and which also doesn’t clutter everything everywhere. It’s pretty simple and involves Swift.
The other day, I wrote a post about bind() and the >>= operator and how it can help chain function calls together. The example was a bit too contrived and making it fit the requirements left us with really bad code. I came up with an even better implementation: use plain Swift objects and express your intent carefully.
After working on the model of your app for a while, it can be hard to change your ways of thinking and see what should be coming next. How does an app come out of all this? Where does the user interface plug in? It helps to architect your app in layers and focus on the missing parts before figuring out the glue.