Well I'm not going to say this is the best approach, but I can tell you some of the things I typically do.
1. Controlled views have a controller property. You could either do this generically or specifically ( IE UIViewController *controller or RootViewController *controller ). There is a pro/con to both approaches. The first is more generic and will fill most circumstances for passing interaction delegation back to the controller (IE, setTarget, performSelector, etc ). If you need to access specific method calls on the controller however it will require a tiny bit more typing if you want to be proper about it and cast it.
2. UIViews that are controlled ( IE base views ) don't handle any interaction themselves - anytime something happens it isn't even seen by the view. For example if I have a MenuView that creates some buttons, then when I set them up their target for the event is self.controller. It keeps things cleaner IMO, and means I have less work to do if I refactor because I didn't like the method name I chose - because then I don't also have a sub method in the view.
3. Controls / Widgets typically don't have an associated controller. For example if you're making custom table cell or button implementation, or a game sprite actor. They're just for display and they should be able to be controlled by anything that wants to use them.
4. For advanced controls that have very specific interactions and callbacks that need to happen I like to use delegates. It's how Apple has done things, it works well and it's pretty simple after you've done it a couple times. Plus it's nice to be able to see in the header what protocols are being implemented - as Colionel pointed out very correctly, it shouldn't matter *what* is using your control, just that it conforms to the expected interfaces.
Just some thoughts off the top of my head. =)
|
