iOS application architecture: MVVM, behaviors, singletons, subclassing

I completely agree. Years ago when starting an iOS app I suggested a few abstractions to the other devs and got the response that 'this is not an enterprise application.' The problem is that a complex iOS application can quickly become a lot of code. It is compounded by the fact that a lot of that code ends up in the view controllers.

I have experience doing something similar in a project at work.

In this project I have one reusable ViewController (among others, but this example is about this one) that had nothing but a UITableView and a search box (a UITextField for searching by text, and a segmented control that sorts/filters the data by preset values like A-Z or distance).

About halfway through this project I found myself with a controller with several if/else blocks and other weird things to stop code re-use and make the controller abstract in the sense that I could init it with whatever data object I needed and it would figure everything else out from there. This accomplished my goal of limiting code re-use but it absolutely sucked when a change had to happen. Conceptually, it was terrible to go down and find the correct "else if {}" to make my amendments to and then make sure that didn't take anything else down with it.

Then I said to heck with code re-use. I'm going to make this sucker clean and easy to find/fix/edit/create a new one. I pulled all of my UITableViewDelegate and UITableViewDataSource code into separate files depending on the data model that was necessary for this controller. I still init the Controller the same way, but now all of the searching/sorting/table actions that were horribly done earlier are in their own separate classes - specific to the model for each.

This means that I have 12 files that have a slightly similar structure - all of the numerOfRows and cellForRowAtIndexPath type methods as well as my custom search view's delegates. And yes, an earlier self would of been a little weirded out by such blatant disregard for reuse. But yesterday, when a change request came in to add another similar type view with a different API and data model it literally took me 5 minutes to subclass my XXDataSource class and hook it up to a model, and the whole thing worked perfectly. 5 minutes. I can't tell you how good it felt to not have to look through the cruft and add another "else if" check and make sure my other stuff would still work.

I hate to call it beautiful since I'm still a noob, but damn is it beautiful. My controller has 40 lines. Each XXDataSource class has about 100-150ish. I highly recommend this approach, especially when it looks like you're going to reuse a tableview-esque controller.

Now my XXNavigationBrain solution - that's a whole other topic. ;)

I think part of the reason that most apps don't use these techniques is that there are not enough examples.

The examples that are available on SO, the apple docs, and IB generated/influenced code work great for the simple case but fall down a bit when your app grows. there are much better and simpler ways to handle some of the common patterns in large apps, for example the great thin view controllers article.

Objc.io is a fantastic resource.

Where I come from, friends don't let friends use singletons (drugs are okay though).

Show me a singleton and I'll show you a doubleton, no wait, its a tripleton....

I think 40 lines of code for a controller is overkill. The goal is to make them manageable without sacrificing readability. In my opinion the data source and the delegates should be in the controller because it makes the code easier to read.

My average controller is between 200 and 400 lines of code. This might be a lot of code in Rails of other frameworks but I find it acceptable in Objective-C (considering it's an extremely verbose language).

To reduce the lines of code in my controllers I usually use categories or subclasses for custom views (I don't use Interface Builder). You can also make manager objects to do most of the workload and reduce the lines of code per method. I think reducing the lines of code per method is more important than reducing the lines of code overall.

Things that I configure once and don't plan to touch again I put in separate files like subclasses or categories. Things that can change or are necessary for understanding the big picture stay in the controller. And guess what? Data Sources and Delegate Methods are necessary for understanding how a UITableView works. In my case 200 to 400 lines of code (on average) seems like a good compromise.