passing data btwn UIViewControllers

126 views
Skip to first unread message

WyattJ

unread,
Apr 28, 2009, 2:30:24 PM4/28/09
to iPhone Application Development Auditors
I'm a bit sketchy on how to properly pass data back and forth between
view controllers, from a code architecture standpoint. In the
previous lesson, they made a big deal on how NOT to do it -- including
not using global variables, and not using the app delegate. Then they
go on and briefly mention that one way to do it is by using
delegation.

???

So using delegation is good, as long as its not the app delegate? I
really dont see the problem here.

Rich MacDonald

unread,
Apr 28, 2009, 4:06:17 PM4/28/09
to iphone-appd...@googlegroups.com
Yes, this is a bit confusing.  It's not difficult for a UIViewController subclass A to pass data to a UIViewController subclass B that is instantiated by A and before A pushes this new controller on the navigation stack.  The demos and assignment describe this direction adequately.  

Sending information the other direction is trickier and the lectures were vague as you pointed out.  One solution would be to alter the data of an object sent from A to from within B.   I'm not sure if this is OK practice.  On the one hand it seems like it relies on side-effects and global data.  On the otherhand, the object passed to B need only be the portion of A's model that B cares about (e.g. Person object instead of array or Person objects).  

I did try the delegation route for a third view I made, which is basically just a view for entering in a multiline comment which is  then sent back and appended to a comment section displayed on the PersonDetailViewController.  Since the comments are saved in user defaults, I first did the appending and saving in the CommentsView, but the dependencies seemed like bad form and limited reusability.  So now my CommentsViewController.h file defines, in addition to its class, a CommentsViewControllerDelegate protocol with an optional method:

@protocol CommentsViewControllerDelegate <NSObject>

@optional

- (void)viewDidPopWithEditedText:(NSString *)aString;


@end


I also added a delegate property to the CommentsViewController class:

@property(nonatomic, assign) id<CommentsViewControllerDelegate> delegate;


Now my PersonDetailsViewController can adopt the CommentsViewControllerDelegate protocal.  After it creates an instance of the CommentsViewController - and before it pushes this viewController subclass onto the navigation stack - it sets the delegate property to self.  By implementing - (void)viewDidPopWithEditedText:(NSString *)aString; in PersonDetailsViewController.m, it will get a chance to handle the text that was entered in the comments view. 

The call for this delegate method within CommentsViewController's -(void)viewWillDisappear:(BOOL) :

if(delegate && [delegate respondsToSelector:@selector(viewDidPopWithEditedText:)])

[delegate viewDidPopWithEditedText:editedText];


or for brevity, since a message sent to a nil would result in 0 anyway:

if([delegate respondsToSelector:@selector(viewDidPopWithEditedText:)])

[delegate viewDidPopWithEditedText:editedText];


I'm not sure if this approach is what they are talking about, but it does seem similar to the approach outlined for View -> Controller delegate communication in today's Lecture 6-7 Follow-up Notes, and I tried to model it off of UIView and UIViewDelegate interfaces and the respondsToSelector: excercises from Assignment 1.  

Using delegation has seemed more natural over time, but I found implementing it gives a deeper understanding of the design pattern.  For instance, it flips around how objects are "returned" in methods, as the arguments become more like return mechanisms (beneficial in that you can have many arguments instead of only one return type). 

-Rich
Reply all
Reply to author
Forward
0 new messages