Splitting the View Models of TableFlip, a Short Aftermath

I executed my plan from earlier this week to split TableFlip’s monolithic view model into sub-view models. The process wasn’t too complicated. The highlights:

The current hierarchy of controllers in the view layer is as follows:

screenshot of TableFlip
Screenshot of TableFlip v0.6

The window doesn’t look too complicated and there truly are not that many view components involved, but still it’s quite some work to keep things well coordinated. The TableViewController file clocks in at about 400 lines of code although it mostly delegates stuff to other objects. There’s still room for improvement, but I have to see patterns, first. I even extracted NSTableViewaDataSource and NSTableViewDelegate into different objects months ago. Today I doubt this was a good idea in the first place. We’ll see.

Now that the single app state results in updates of 3 different view models, I can begin to plan performance optimizations: did the selection change? – then don’t redraw the table at all.

I love creating complex models and write unit tests for them. I really do. The view stuff, not so much. But now things really get interesting again as I try to improve the user experience and sometimes have to roll custom solutions instead of using the default AppKit stuff. The level of challenge increases. That’s always nice.

Browse the blog archive