Custom UIView and UIViewController best practices?

Question

I currently have a simple iPhone app that loads a custom subclass of UIView. There's only one controller at the moment for the whole application, although there are several UIViews for separating the program logically.

My current structure looks something like this:

mainView : UIScrollView
    \__ has one subView : myCustomUIView : UIView
            \__ has many subSubView : myOtherCustomUIView : UIView

I hope this is clear; a colon, of course, represents inheritance.

My issue is this: I need to intercept events at the lowest level, subSubView. I can probably do this in the application controller if I need to, but should I have a subSubViewController instead? Should I have a subViewController too?

If so, can someone point me towards some references for doing this by hand? I can of course create the classes, but connecting them to custom views seems nontrivial. I'm not using interface builder at all aside from the main nib that holds the window object.

My main confusion arises from what will happen when I have a view nested in a view with a different controller. So let's say I did have a subSubViewController, but mainView still has its mainViewController. Since subSubView is contained within mainView, would this not cause some issue?

And should I be using delegates at all for any of this?

Any nudge in the right direction would be appreciated.

Answer 1

Views and view controllers exist in pairs. Each view controller control a view and the view's subviews. This is necessary because view controllers are in the responder chain for events. If multiple view controllers are active within the same view, the responder chain becomes scrambled.

Standard view controllers don't have a subController attribute and don't understand if another controller is active in the same chain. Navigation and tabbar controllers exist precisely to handle hierarchal controllers. However, they do so by swapping one view/view-controller pair for another. You can't use navigation or tabbar controllers to provide different controllers for subviews.

So, regardless of how many subviews you may have for anyone view, you end up with just one controller per screen.

You might want to reconsider your design. If the subviews each need highly customizable behavior, you might want to move them to individual views in a controller hierarchy such as in the master-detail design pattern.

If you do have to have all the subviews on the same screen, then I would suggest looking at how a UITableView and UITableViewController handle things. (You might be able to just use a a modified tableview.) A tableview is a scrollview that holds multiple subviews for cells, section titles, headers and footers. It manages this by trapping the touches from the tableview and determining which cell view was touched and then taking the appropriate action.

If you need highly customized behavior for each subview, you could use the delegate pattern and assign each subview a different delegate object. The view could trap its own touches and call its own delegate.

Scrollviews can be tricky to implement customized touch behavior because the scrollview traps touches at a higher level than other views so that it can determine if it needs to scroll or not.