-1

i'm getting lost on the use of delegates. ok they are used to pass values between objects, let's say ClassA needs to pass values to ClassB, we should use a delegate ( if i got that at least ).

let's say i have a ViewControllerA which has a textfield and a button, and a ViewControllerB which has a label. To pass the data saved from the textfield in the VControllerA to the VControllerB i can use a delegate...

let's see the first class

//ViewControllerA
#import <UIKit/UIKit.h>

@interface ViewControllerA : UIViewController {
IBOutlet UITextField *tf_text;
IBOutlet UIButton *but_add;
}

@property (nonatomic, retain) IBOutlet UITextField *tf_text;
@property (nonatomic, retain) IBOutlet UIButton *but_add;

-(IBAction)addAction:(id)sender;

@end

ok this is the other 

//ViewControllerB
#import "ViewControllerA.h"

@interface ViewControllerB : ViewController {

IBOutlet UILabel *_label;

}

@property (nonatomic, retain) IBOutlet UILabel *_label;

@end

ok now i start to get lost. what will be the correct way to use this protocol ? let's say i want to do it as a new file controllerADelegate.h

how should i pass data?

i'm getting crazy about it, i seen many online tutorial but i still can't really get how to use it

rmaddy
  • 314,917
  • 42
  • 532
  • 579
mystudioos
  • 99
  • 1
  • 1
  • 8
  • 3
    possible duplicate of [How does a delegate work in objective-C?](http://stackoverflow.com/questions/1045803/how-does-a-delegate-work-in-objective-c) – Mike D Jul 30 '13 at 18:56
  • [Passing Data Between View Controllers](http://stackoverflow.com/questions/5210535/passing-data-between-view-controllers) – JuJoDi Jul 30 '13 at 18:57
  • 1
    It's important to understand that there's absolutely nothing special about a delegate. It's just a class/interface whose methods are called to obtain data or to interact with the delegate owner in some other way. We call it a "delegate" simply because of the context in which it's used, not because of any mystical behavior. – Hot Licks Jul 30 '13 at 19:13

3 Answers3

2

I think you are still a bit off the mark with delegates, if you are looking to pass data between viewcontrollers, then JuJoDi's link is what you want.

but delegates can be viewed as a sort of call back to give a 'parent' object a chance to execute some code when something happens in the 'child' object.

for instance a UIScrollView has a delegate method scrollViewDidScroll: that tells its delegate that it has scrolled and may run some code. most of the time you will go scrollView.delegate = self meaning that the object that is self (which is usually the viewcontroller you are writing this statement in) is becoming the delegate of the scrollview, which means it will receive the call backs from the scrollviews delegate methods (which are defined in the UIScrollViewDelegate protocol, but unless you want to write your own delegates, you dont need to worry about).

hope that clears it up a bit, but ye in short delegates aren't only for passing data around (even though they have parameters, they are for a different purpose really), they are for running code when something happens within an object that the 'parent' object (or anything outside the class really) may need to know about

Community
  • 1
  • 1
Fonix
  • 11,447
  • 3
  • 45
  • 74
1

As Apple points out in its IOS tutorial, a delegate exists not to pass data from one part of your view to another, but to let your application react when the user causes an event to occur. For example, the user is editing something, and then tries to close the editing window. The system will send a windowShouldClose: message to the window's delegate. The delegate, if it exists and can can accept the message, can warn the user that he has unsaved edits and ask him whether to close the editing window or not.

Delegates are usually declared as something like id <NSWindowDelegate> and implement that protocol.

Your controllers should just pass the data themselves. That's just ordinary programming.

Eric Jablow
  • 7,874
  • 2
  • 22
  • 29
  • that's my doubt... i was reading some delegate tutorials around the web... but to me it's weird... to pass those data, i would just use a regular method that passes parameters... – mystudioos Jul 30 '13 at 20:00
  • Yes. Your controllers talk with each other, and they push data back to the views and the models. The delegate (and you can have a controller be its own delegate) handles system events that happen based on what the user does. None of your code will call `windowShouldClose:`. The system sends that message to your delegate if it exists and can respond to it. – Eric Jablow Jul 30 '13 at 20:04
1

You use a delegate if you are passing information up from a child to a parent. In your case if ViewControllerA is the child of ViewControllerB then you would want a delegate. I don't see why you would need to do it as a new file though. All you'd need to do is in your child (ViewControllerA) header file do this:

@class ViewControllerA;
@protocol ViewControllerADelegate/*just naming your delegate */ <NSObject>
//list methods that you will be using from your parent ex. -(void)setLabel;

don't forget to set a property for your delegate in your interface

@property(nonatomic, strong)id delegate;

Now in your ViewControllerA implementation file you need to access your method in your parent (ViewControllerB) you can do that in your IBAction

-(IBAction)addAction:(id)Sender {
[self.delegate setLabel];

Now to set your ViewControllerB as the delegate. In the header make sure to have the method you placed in the protocol of your child. Also make sure the child is imported.

#import "ViewControllerA"

After interface but before end

-(void)setLabel;

in the implementation of ViewController B (most important)!

-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
ViewControllerA * view = [[[segue destinationViewController] viewControllers] objectAtIndex:0];
[view setDelegate:self];
Ryan Smith
  • 98
  • 1
  • 9
  • if B is son of A, can't i just use a regular method to pass parameters? why to use a delegate? – mystudioos Jul 30 '13 at 20:01
  • if B is the son of A then A can get any methods from A. Good way to think about it is this: The parent can tell the child what to do, but the child can't tell the parent what to do. That's why we delegate the child so it can. – Ryan Smith Jul 31 '13 at 03:05