Looking for good guidelines on how to manage code for large UIViewController classes

Question

I've been working on my first XCode/iOS project and so far it's been an enjoyable experience. Currently, I am working on a Nib file that acts as a primary display for other views. Within this Nib file, I have a primary UIView and next to it I am designing a series of seven other views. At runtime I swap these seven views in and out when necessary, within a container UIVie, located on my primary UIView.

Across my 8 total views that I'm designing in IB, I have a large amount of buttons, images and other objects that need to be linked to IBOutlets. As this project is getting bigger, it would helpful if I could split my class across multiple code files.

Using categories is the solution, however, I've hit an annoyance-- when I tried to create an IBOutlet in one of my category headers, the XCode compiler keeps giving me errors and warnings about ivars and outlets. In my Nib I have a large number of objects that need outlets and I'd prefer to not have to define all of them in one, huge code file if that's possible.

However, I understand that I have to work within my limitations, so my question is a bit different than asking how to add an IBOutlet to a category. Instead, I'd like to know what are the best practices for splitting up a large UIViewController class across multiple code files? What are the limitations of objective-c and what is the best way to structure your code when working with interface design?

My code is not quite yet unwieldy, but I'd really like to start restructuring it so that it will be much more manageable when it consists of 100's of methods and 1,000's of lines of code.

Any pointers would be helpful. Thank you!

Answer 1

You can create one NIB that contains several controller objects, each managing the relevant views, and that will help to keep your code more manageable. The downside is that your memory footprint is larger loading a large NIB.

To achieve this, define the controllers in separate classes with relevant IBOutlets, and then drag the NSObject from the objects tray (where the UILabel, UIButton etc... are) into IB. Then for each object, define its class to the the correct controller, and you will have access to all the correct outlets and actions. You can then hook the controllers into a single UIViewController to control how they interact with each other.

The preferred way though, would be separate NIbs for separate controllers, and to have them all as UIViewController subclasses. If you move to iOS5 they have superseded NIBs in IB with Storyboards. These allow you to have separate UIViewControllers in a single IB file, however they are more efficient in memory usage as they don't keep the whole object tree in memory.

Answer 2

This is a pretty loaded question. But, in my experience, I've found that IB causes more headaches for me than it's worth in complicated situations such as this. I recommend just forgetting about IB for this scenario and just create your views in code. IB is really supposed to alleviate some of the more mundane tasks of layout, style, etc.

I recommend that all of your views be placed in their own project files as this has paid off for me...nothing more painful than scrolling through 1000's of lines of code to find what you need...and worse yet, using that dreadful code collapse widget in the gutter.