Question

I have a view controller that creates ObjectA. ObjectA then creates ObjectB. ObjectB needs to get some values from the view controller (i need values that can change after creation of the objects).

I’m trying to figure out the best way to retrieve the values. My first thought was with protocols. I have only created protocols within an object so far:

#import <UIKit/UIKit.h>

@protocol AnalysisTypeTableDelegate;

@interface AnalysisTypeTableViewController : UITableViewController

@property (weak, nonatomic) id <AnalysisTypeTableDelegate> delegate;

@property (strong, nonatomic) NSArray *dataSource;

@property (nonatomic) BOOL allowRefresh;

@end

@protocol AnalysisTypeTableDelegate <NSObject>

-(void)returnAnalysisType:(NSString *)type;

@end

how can i create protocol class (such as create new file, objective-c protocol)?

Then how do I link them together? ObjectA has a protocol, do i do something like:

// View controller and objectB both conform to myProtocol

// view controller creates objectA
myObjectA.delegate = self

// when objectA creates objectB
myObjectB.delegate = self.delegate

Or is there a better way to retrieve the values i need?

EDIT:

I think I’ll need to do something like this:

objectA’s protocol:

@protocol objectADelegate

-(NSDictionary)requestViewController;

@end

objectB’s protocols:

@protocol objectBDelegate

-(NSDictionary *)requestObjectA;

-(void)updateList:(NSSarray *)list;

@end

in myObjectB

-(NSDictionary *)requestObjectA {
    NSDictionary *extents = [self.delegate requestObjectA];
}

-(void)serverCall {
    // make server call, get list
    ...
    // update myObjectA with new list
    [self.delegate updateList:newList];

in myObjectA

-(NSDictionary *)requestObjectA {
    return [self.delegate requestViewController];
}

-(void)updateList:(NSArray)list {
    // updates list
}

in view controller

-(NSDictionary *)requestViewController;
    return self.mapkit.exents;
}

Answer 1

I assume you’re saying that this is called from your view controller:

myObjectA.delegate = self

And that you’re calling the following line from object A:

myObjectB.delegate = self.delegate

Technically, you can do that, though I find that construct a little confusing. And it’s even a little problematic, because you don’t provide any mechanism for the view controller to say “ok, I don’t want to be a delegate anymore”, because it presumably only knows about myObjectA. You don’t have any mechanism for the view controller to tell myObjectB that it doesn’t want to be its delegate any more, because presumably the view controller doesn’t even know of B‘s existence.

---

Use Model-View-Controller pattern

The notion of delegate is one of “I want to tell my delegate something, or make some request of it”. If your goal, on the other hand, is to share data amongst them, I’d be inclined to shift away from the delegate-protocol pattern, and to a model-view-controller (MVC) pattern, and we’ll focus on the “model” portion:

• Create a Model class to holds the model data;

• Have the view controller instantiate a Model class object;

• Pass pointers to the Model object from one view controller or object to the next (or otherwise make this model object accessible to other classes, via, for example, a singleton pattern, an app delegate property, etc.);

• Make sure your Model class has properties associated with data being maintained (that way, other classes can use the accessor methods that Model will synthesize for you).

This is conceptually very similar to what you’ve outlined with your delegate pointers, but doesn’t carry the implications that delegate does, namely that you’re not only accessing data, but rather you can tell the controller to do something. In a delegate-protocol pattern, the delegate should generally have the ability to opt out of being a delegate at any point.

---

Different approaches to handling changes in model data

There are several approaches for reflecting the change to a model object in other objects (e.g. to tell the view controller that model data has changed and it must reflect that change). These include:

1. Use delegates. This is probably the worst of the approaches that I’m listing here because if you want to tell multiple objects about the change in the model data, you have to have multiple delegates (or an array of them). This is a poor use of delegates.

2. Reload upon viewDidAppear. If you’re only dealing with making sure that view controllers update their views to reflect data that changed on another view controller, you can just refresh the view when it appears again. This is the most primitive solution, and only works if you’re dealing with view controllers that are reappearing after, for example, a modal view that altered the data has been dismissed. This is, in those simple cases, often the easiest solution.

   - (void)viewWillAppear:(BOOL)animated
   {
       [super viewWillAppear:animated];
   
       [self updateField1Label];
       [self updateField2Label];
       [self.tableView reloadData];
   }
   

3. Register for notifications through the NSNotificationCenter. This has the beauty that multiple objects can add themselves as an observer to the same notification. For example, define a key for your notification in your .m file:

   NSString * const kNotificationField1Changed = @"com.log139.field1";
   

   Then, define an external reference to that key in your .h file:

   extern NSString * const kNotificationField1Changed;
   

   Then, the object that wants to be notified of the change can register for that notification:

   [[NSNotificationCenter defaultCenter] addObserver:self
                                            selector:@selector(handleField1Notification:)
                                                name:kNotificationField1Changed
                                              object:nil];
   

   Obviously, you have to write that “handler” method:

   - (void)handleField1Notification:(NSNotification*)notification
   {
       self.field1Label.text = self.model.name;
   }
   

   Finally, whatever updates that model field can post the notification, e.g.:

   - (void)saveAndPop:(UITextField *)textField
   {
       self.model.field1 = textField.text;
   
       [[NSNotificationCenter defaultCenter] postNotificationName:kNotificationField1Changed
                                                           object:self
                                                         userInfo:nil];
   
       [self.navigationController popViewControllerAnimated:YES];
   }
   

   If you do this, you just need to make sure that when the object that registered for the notification is going out of scope, it must also unregister for that notification:

   [[NSNotificationCenter defaultCenter] removeObserver:self
                                                   name:kNotificationField1Changed
                                                 object:nil];
   

4. Use key value observing. Again, multiple objects can register to be an observer of your model’s properties. Let’s assume that you have defined three properties (via @property) for your Model object. Any object that wants to be notified of changes can add themselves as an observer of those properties, e.g.:

   [self.model addObserver:self forKeyPath:@"field1" options:0 context:NULL];
   [self.model addObserver:self forKeyPath:@"field2" options:0 context:NULL];
   [self.model addObserver:self forKeyPath:@"field3" options:0 context:NULL];
   

   You then just need to write an observeValueForKeyPath method:

   - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
   {
       if ([keyPath isEqualToString:@"field1"])
           [self updateField1Label];
   
       else if ([keyPath isEqualToString:@"field2"])
           [self updateField2Label];
   
       else if ([keyPath isEqualToString:@"field3"])
           [self.field3TableView reloadData];
   }
   

   The only thing that’s tricky here is that if one of the objects is a collection (e.g. a NSMutableArray), you have to write collection accessors. See that document for more examples. For example, though, I have a model that has a property that is an array of pet names, NSMutableArray *petNames. Thus, I had to write the following two methods for my model:

   - (void)insertObject:(NSString *)petName inPetNamesAtIndex:(NSUInteger)index
   {
       [self.petNames insertObject:petName atIndex:index];
   }
   
   - (void)removeObjectFromPetNamesAtIndex:(NSUInteger)index
   {
       [self.petNames removeObjectAtIndex:index];
   }
   

   And instead of ever calling [self.model.petNames addObject:aPetName], I called [self.model insertObject:aPetName inPetNamesAtIndex:0]; instead (and by doing that, the notifications take place automatically).

In short, if you have multiple objects that have to be notified of a change in your model data, I think that key-value-observing is the most elegant approach, but it takes a little time to get your arms around it if dealing with collections. I think that just posting notification is a relatively simple alternative.

---

References:

• Model View Controller in Cocoa Core Competencies.
• Model View Controller in Concepts in Objective-C Programming.
• Key Value Observing Programming Guide.
• Key Value Coding Programming Guide
• If you’re dealing with collections with KVC, pay special attention to the Collection Accessor Patterns for To-Many Properties section of the Key Value Coding Programming Guide.