Cocoa Touch App Architecture - MVC controller?

views:

602

answers:

+2 Q:

Cocoa Touch App Architecture - MVC controller?

+2 A:

Updating my answer based on comment:

It's in most cases ok to have state in your controller. Like an array or an instance of whatever modelobject you are writing an application for.

I would keep the model object clean of any networking code and put that in the Controller instead though. In this case the ViewController where that connection action is triggered.

Original answer:

It is not really clear to me how can I get data nested deep into subviews(username) or how can I trigger actions in nested parent views(connect button).

With the utility application template you already have a couple of ViewControllers.

To get references to your UI inside your controllers you need to declare IBOutlets and connect them inside Interface Builder. To respond to actions you need to declare and implement IBActions in your ViewControllers and hook them up in Interface Builder as well. Which you do in Connections pane (2nd from left) in the inspector.

monowerker 2009-05-29 11:52:26

I am able to use IBOutlets and IBActions to link UI elements to the immediate parent view controller. I do not understand how to propagate data to upper containers up to my App Delegate that contains my Model object...

Paull 2009-05-29 12:12:20

Keeping state or data in the app delegate can work but is not a good architecture, since it's always available (with [NSApplication delegate]) it very easily leads to code making asumptions about this global object, ie. non-reusable. It might be OK for smaller applications.

monowerker 2009-05-29 14:04:37

Thanks for the answers!For my simple app can be ok to have the model instance inside the root controller so that it can reach both subviews (text field and connect button+label). I will also clean networking as you suggested.I wonder how to cope with more complex architectures with really nested views.Is it necessary a singleton model so that it can be accessed from all over the app? (I do not like this approach)Or maybe you have to propagate data bottom to top invoking parent view methods or sending some sort of event notification around?

Paull 2009-05-29 15:55:47

On the iPhone you are very encouraged to have one UIViewController for each "screenful of content". So anything that happens in a View connected to its ViewController or any of its subviews should ideally be encapsulated to that ViewController, if possible.Now for a significant app i would rename AppDelegate in the Utility template to ApplicationController instead, still keeping it as the delegate but to make it more clear as to it's purpose. Then I'd put references to the ViewControllers in the application in there. But keep the state as much as possible in the ViewControllers.

monowerker 2009-05-29 16:38:43

ansaurus

tags:

views:

answers:

Cocoa Touch App Architecture - MVC controller?

related questions