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...

Working Toward an Architecture Eureka!

I had a quiet meeting-free week, so I got back to working on my SwiftBoard project. Early in the week, I was making decent progress, but by mid-week my progress had stalled. Adding each subsequent feature was taking longer and longer, and the code was definitely getting smelly. I could tell that I’d reached the point in the project where the original architecture was no longer sufficient — it was time to refactor.

Sometimes this stage is a quick bump in the road. I can see quickly where I’ve gone wrong, or I find a parallel to another project I’ve worked on, and I’m good to go.

I haven’t been that lucky this time. I’m working in a new language (Swift), and I’m tackling more complex user interactions on iOS than I’ve tried before. It’s enough out of my comfort zone that my old bag of tricks doesn’t help me much. It feels like the coding equivalent of writer’s block… it would be a waste to keep slogging through new features in the existing architecture, but I don’t know what the new architecture should be yet.

When I’ve been stuck like this before, there wasn’t a linear path to solving the problem. I’ve tended to pull at the problem from all angles, then eventually the eureka moment strikes. I’m hopeful that will be the case again this time, so I’ve been jumping between research, quick throw-away code spikes, diagramming, and exercise. I feel like I’m closer to the solution, but I’m not quite there yet. Maybe a weekend off will be just the ticket?