You know (or don’t) that cocoa touch uses MVC (model, view, controller) to implement applications, beside the Delegate Design Pattern, but this one we’ll talk later.
Most of the Cocoa Touch classes fall into three categories: views kind, models kinds or controller kinds. And you’ll notice that views and controllers do the most of the hard work in your application.
Let’s first have a chat about Views. Views are responsible to all the user interaction objects. Buttons, scrolling lists, and everything else that appears in the iPhone screen are views. And if you pay attention, you’ll see that mostly of the already build views knows already how to interact with the users interactions. And you can always do a view yourself, off course, you’ll only need to extend your class to an existing view. It’s nice to know that mostly of built views extends to this standard classes: UIVIew and UIControl .
Models are, practically all that manage your application data. The models only know your data, but don’t have a clue about the user interactions and how to react to it. Think about it like this: thought about data, thought about models.
About Controllers, they are a bit complexes, comparing to views and models. They are the ones who transfers the information between models and views, if one model change its data, so the controller update the view, and if one view change its information the controller updates the data. The models and views don’t communicate directly because, if they did, you’d need a lot more objects. What if your client changes his mind and asks you another view to share the same data? Or worse, your boss? Think about controllers as a “task-setup”, whatever you must set, you should use the controllers.
You can read more about this subject on iPhone App Development: the missing manual by Craig Hockenberry or here, in apple documentations.
