Trying Out MVVM

Last week, I wrote that I was jumping from strategy to strategy, hoping to find the inspiration that I needed to break through my coder’s block. The eureka moment hadn’t arrived by the start of this week, so I decided to cross my fingers and start refactoring to an architecture that seemed like it could plausibly work.

Earlier in the year, I learned about Model-View-ViewModel architecture (MVVM) on episode 3 of Justin Williams’ CocoaRadio podcast. I was in the late stages of building my first iOS app at that time, so it was too late for a major architectural re-think. But I did take some inspiration from MVVM by creating a few classes that presented model information in a view-convenient format.

I hadn’t thought about MVVM much since then, but in my research late last week, I read lots more about it. Here’s a few of my favourite links:

Many of the stated benefits of MVVM, like greater testability, serialization and code re-use, don’t really apply to my current project — but I was struggling with managing state — so I decided that implementing MVVM was worth a shot.

It’s still a little early to declare victory, but I’m happy with how the refactoring effort is going. I now have a view model layer that contains all of the dynamic state for my views and the actions to manipulate that state. Each view model defines a delegate protocol, so a view can register to be notified when the state changes. It feels like a very practical separation of concerns — it’s way easier to reason about state and state transitions when I’m not being distracted by how the views need to be updated to match the new state.

I've reached feature parity with what I had working on my old architecture, and a couple of new features fell out naturally after the refactoring work. That's a great sign. I’m hopeful that the rest will fall into place over the next week or so, then I’ll start polishing the UI and code for release. That’s both exciting and scary! Check in again next week for another update...