In iOS, if a screen packs a lot of functionality, I struggle to keep the code for its view controller clean because of many methods defined for the same screen. Especially with delegate methods for (e.g. UITableView
, UIAlertView
, etc.) or if that same VC file is to support both iPad and iPhone, it quickly turns into a mess.
I also realised that if you use #ifdef
statements, it breaks up the nice #pragma mark - Title
grouping.
Question1 -
What is your practice for organising a view controller that gets very bulky?
Question2 - Similarly, for a page with several partial components (e.g. a bottom menu, a top menu, a side menu, whatever), how do you find the following pattern?
UIViewController *vc_component = ...
[self.view addSubview:vc_component.view];
It seems correct to me in terms of MVC because vc_component
takes care of all the interactions of its view. The only thing that bothers me is the fact that there are several view controllers responsible for the same screen at the same time, which is not ideal IMO.
Would love to hear your thoughts.
in my experience, if one view controller contains a lot of code in it, I would try to take this code into a different class. For example, my view controller contains panel that handles some controls for managing model object. In this case, I would create
ModelPanelControl
view and put all the logic for it in its implementation and then make it a subview of my View Controller. However, if you have a lot of delegate calls to your View Controller, then I think there is nothing wrong with this as long as you split these calls with pragma marks.To answer your second question, I would assume that your project is >= iOS5, because there is a very nice View Containment API you can use to add multiple View Controllers to one screen. Here is a documentation and you can also watch WWDC 2011 video called Implementing UIViewController Containment.
Hope this answers your questions. Cheers!
In response to your first question, if you are indeed having several viewControllers managed by one container viewController, why would you not have each of those viewControllers be the
delegate
to their explicit functions? Thus, any button actions etc. that trigger a UIAlertView or UIActionSheet from that viewController would be the delegate to those specific alerts?You could also be well served looking into some of the block UIKit categories that are out there. Gentleman named Mugunth Kumar has one called UIAlertView+MKBlockAdditions that I've found very handy for getting rid of a bunch of delegate spaghetti.
It's common practice to define a base UIViewController that all of your other viewControllers inherit from, where you implement all the common helper methods. Put the lowest common denominator in there, and set the rest of your controllers to be subclasses of this. That at least helps with copy and paste problems, and the DRY paradigm.
Finally, until iOS5 it was hacky to encapsulate viewControllers within viewControllers because the rotation methods didn't get invoked in all of the subviews automatically. The workflow goes like this:
That teaches the OS who is in charge of who.