views:

333

answers:

2

Given the section of an application which has a UINavigationController and 2 levels of UITableViews (i.e. a row is selected on the root controller which pushes the second controller onto the navigation stack) I have the following questions:

1) There is a User object which is required by both controllers. What is the best way to communicate between the two controllers? I have seen a post on this site which mentions dependancy injection and that the root controller could pass the User object to the second level controller by:

@implementation SecondLevelViewController

-(void) initWithUser: (User *) user {
   // myUser is an instance variable
   myUser = user;
   [myUser retain];
}

In that example the second controller would seem to retain the User whereas I have seen other sources (e.g. the Stanford iPhone development course) which advocate the User being simply assigned, and not retained, in that situation (loose coupling).

I have also seen arguments for a form of delegation where an assigned id object would be used on the second controller (rather than a retained User instance variable as above).

It would be great if someone could clarify this position for me as I am extremely confused by the seemingly conflicting advice in this area. What is the best way for communication between view controllers?

2) My second question also relates to the structuring of the controllers. I have seen examples where the root controller (in the arrangement above) has an array of instantiated second level controllers. Is this normal in a professional application or would there be a significant memory impact for doing things this way (i.e. no lazy loading)? I assume the advantage of the array is a reduction of loading times for the second level controllers?

Thank you for any responses as I am trying to develop things properly rather than hack them together.

+2  A: 

1) "What is the best way for communication between view controllers?"

There is no one "best" way. You can certainly pass a model object to the view controller on initialization. In that case, the controller should generally retain the model. Going with a delegate is a good option if you are writing a general view controller class with a focus on reusability (such as UITableViewController).

2) "I have seen examples where the root controller (in the arrangement above) has an array of instantiated second level controllers. Is this normal in a professional application"

Firstly, you should limit your posts on SO to one question per post. The memory impact of a view controller itself is usually quite low. It needs just a few hundred bytes for its instance variables. The memory-intensive part are the views themselves. And UIViewController's view loading/unloading mechanism will take care to unload the memory-intensive view when needed (i.e. if it receives a memory warning and the view is currently not on screen). So as long as you implement viewDidLoad, viewDidUnload and didReceiveMemoryWarning correctly, I wouldn't worry too much about memory consumption of an array of view controllers.

UITabBarController holds an array of subcontrollers, too, so there is nothing wrong with that. What you should avoid, though, is for one controller to hold an entire hierarchy of subcontrollers (i.e. not only second-level, but also third-level etc.): not so much because of memory concerns than to avoid unnecessary coupling.

Ole Begemann
Thank you for you answers Ole and I note your comment regarding one post per question. However, I was just curious if the array approach (referred to in my second question) does have any loading-speed advantages or is it simply a useful means to structure your code?
Urizen
Instantiating a view controller object should not take a significant amount of time so I'd say any loading-speed advantages are insignificant. What takes time is the loading of the view but the array approach does not change the fact that the view controller will lazy-load the view anyway.
Ole Begemann
Thank you again. Very helpful answers.
Urizen
Glad I could help.
Ole Begemann
+1  A: 

Generally you should try to avoid directly passing data between controllers.

You can setup your model to which each controller has access and then you could implement notifications to inform the other controller that something happened. The other controller can get whatever data necessary from the model.

That way you keep your controllers separated.

stefanB