An “App Architecture” Kata

At the last Side Project Saturday CocoaHeads event I ran a special little exercise. Here was how I described it.

I’d like to run a little event, (maybe after lunch?) for anyone who wants to participate. Should take like 45-60m.

You will be presented with a mobile app idea. It’ll be fairly basic and we’ll list all of the behaviors we need and some we’d like in the future. You will then pair up with someone and pencil out how this could be architected. Each group will then present their app architecture and answer questions, accept feedback from the rest of the group.

From Wikipedia: A code kata is an exercise in programming which helps a programmer hone their skills through practice and repetition. The term was probably first coined by Dave Thomas, co-author of the book The Pragmatic Programmer, in a bow to the Japanese concept of kata in the martial arts.

App architecture is one of those things I’m always trying to improve so I thought it would be cool to see how other people would solve similar problems.

We had six people participate. We started with a brief explanation of the app we were going to sketch out an architecture for. Then, we broke up into pairs of two. After about 40 minutes we came back and showed the group what we came up with.

The one group ended up documenting behaviors per screen. They did a great job of documenting the little things that developers might look over as assumed behavior (which add up fast). It was pointed out that it’s also a great idea to document the things you will not be doing since there tends to be lots of great ideas during brainstorms but when you are planning a sprint of a version target you need to be clear about what’s in and what’s out.

The other two groups (including my own) were more visual, using tools like OmniGraffle to draw representation of models, controllers and services. There was some common separation of responsibilities with slight differences: the one group making an “APIStore” that combined the state and networking and another (mine) that favored separate “Network” and “Session” managers.

Some of the more high-end abstractions I introduced included a FormController that could take a Form model (that had say a collection of FormFields) which described the form at a model level and then through a FormController might be able to render the form on screen through a TableView for a generic representation or maybe through specific outlets to a custom layout. It could also handle things like input validation. True, this is overkill for our one simple login form but assuming this app might grow to contain edit person forms at some point it might not be too bad of an idea (and plus the whole purpose of this event is to discuss interesting ideas).

I also took the time to introduce a pattern thats been out for a while but is a recent addition to my personal toolkit, that being ViewModel. You can read more about MVVM on objc.io. In short it’s a great way to centralize the code you use to transform model objects for user interface purposes and keep that logic out of the model.

In conclusion, everyone who participated seemed to enjoy the exercise and I would encourage you to replicate it amongst your own peers. It’s still up for debate if “Side Project Saturday” is the best venue for such things as many who come have their own stuff to work.