Overview
**I have a couple of doubts: **
for the above scenario, is it still better (good practice) to create a separate view (a view other than view controller's view)? If so why?
Other than drawing and displaying the view (in my project, I don't have much of it) what else should a view's implementation code contain?
I would like to disable a set of buttons when the user touches on a text field and the keyboard comes up.
a) So should I place this logic of disabling some buttons in the separate view's implementation (view created in question 1) ?
b) From my parent view (view created in question 1), can I create outlets for the buttons (which are subviews) to disable some of the buttons? I am not able to do this. Or should I use the method subviews
and loop through the button that I am looking for?
My understanding
Model contains the data
View is responsible for displaying and shouldn't contain business logic.
View controller is the only one to interact between the model and the view and contains the business logic
There's no need to create a separate view -- the view controller's view (usually just a plain UIView) can certainly contain your buttons and text fields. If you did want to put some of those in a separate container (perhaps so that you could move them as a group), you could use a plain old UIView for that.
Views are responders, so UIView subclasses can override the touch handling methods if you want to do any special touch handling.
a) It's common to put the code that manages views (such as disabling buttons) in the view controller. b) Again, you'd normally put the outlets for your buttons in the view controller.
When people talk about "business logic" they usually mean the logic that's required to maintain and operate on the data that the application deals with. That sort of thing is often best placed in the model. On the other hand, code that manages views, such as enabling or disabling buttons or moving data from the model into views (or vice versa) belongs in the view controller.