Reputation: 26223
After watching the Stanford iTunesU CS193p online course I have quick question regarding the correct way to implement an MVC design.
Usually when I do an application I set my view up as part of the controller and add UIButtons, UILabels etc. to that. Essentially the controller and the view become one, unless you count the UIObjects as being the view objects
In one of the early CS193p examples the tutor splits the view off from the controller as a separate object (subclassing UIView), before implementing a protocol and delegate property on the view which the controller object then conforms to.
I am just curious about the practicality of the CS193p design, I can understand that splitting off the view better represents the MVC design paradigm (especially as a teaching aid) but slightly sceptical of its application in real world applications.
Upvotes: 3
Views: 132
Reputation: 70703
With iOS, the UIView class implements drawing refresh and touch handlers, not the view controller class. If you need drawRect: or touchesBegan:, etc., you will need a separate UIView subclass.
This partially could be because this is how buttons and labels themselves behave as well. They redraw themselves, and delegate processed touches. The view controller doesn't draw their content and track xy locations.
Upvotes: 2
Reputation: 40517
Think about the "view" as objects such as UIButton and UIImageView; re-usable components that don't necessarily know anything about the rest of your application. Your view controller is the object responsible for configuring the view objects and managing their state.
There are times when you'll want to subclass UIView, mostly when you need to do custom drawing in drawRect:
. You wouldn't subclass UIView to customize behavior though, that's what your view controller is for. For example, you wouldn't subclass UITableView and just to make the table view its own delegate. Instead you'd make your view controller the table view's delegate.
Upvotes: 4
Reputation: 674
It's not strictly necessary. If you use Interface Builder, most of the reasons why you would build a custom view (breaking UI setup code out of your business code) are taken care of. However, if you want to build custom actions to your view, or setup some properties that you can't quite get at with IB, then it would make sense to split off your view into a separate class.
Upvotes: 1