When we're constructing our app's view controller - view architecture (I believe I'm using that word correctly, as it concerns the relationships of objects and how they work together and what roles they play, rather than what frameworks we use etc):
The view is a UIResponder, and it receives touch events. The view controller also receives those touch events. But View Controller is a controller object, and responding to touch events is controller logic, so the view controller should be responsible for knowing what to do depending on which view is touched, right?
So is it better practice to put all the touch logic in view controller objects, and not put it in the view object? Essentially, ignoring the fact that views can respond to touches.
If we put all the logic in View Controller objects, is it a good idea to have a View Controller object for each view that needs a fair amount of touch logic? So, instead of one View Controller with a bunch of subviews as interface elements, containing all the touch interaction code, we have each sub view be the main view of its own View Controller object, and have all those view controllers be children of a parent view controller.
Is that a good approach?
Thanks for your help