Passing NSMutableArray to other classes

Question

I have created an NSMutableArray in the implementation of my class loginController. The mutable array contains a set of strings. I want to pass the mutable array with its objects to other classes within my cocoa-project. What is the best way to pass the array?

Answer 1

The most basic case is your login controller simply handing a snapshot of the array to the other controller. In this case, your login controller will need to have references to instances of the other classes, and it will set some property of those instances to the array. Remember to declare the properties with the copy attribute, so that the receivers don't hold on to your private mutable array.

If you want the other controllers to be able to modify the array, don't let them have your mutable array—that's an invitation to hard-to-find bugs.

Instead, you'll need to implement one property on the login controller, instead of one property on each of the other controllers. The login controller's property should have at least a getter and setter (which you can @synthesize), but you can implement more specific accessor methods for efficiency.

Once you have this property, the other controllers should access the property in a KVO-compliant way. If you implement the specific accessors, they can just use those. Otherwise, they'll need to send mutableArrayValueForKey: to the login controller. When they access the contents of that proxy array, they really access the login controller's array; when they mutate the proxy array, they mutate the login controller's array in turn.

Next comes the actual KVO part. You'll want the other controllers to know when one of them (or the login controller) changes the property. Have each controller (except the login controller) add itself as an observer of the property of the login controller. Remember to have them remove themselves in their -dealloc (or -finalize) methods.

In order for the right notifications to get posted, everything needs to use either accessors or mutableArrayValueForKey:. That goes for the login controller itself, too—it should use its own accessors when mutating the array, instead of messaging the array directly. The only exceptions are in init and dealloc (because the accessor messages would be messages to a half-inited/deallocked object, which will be a problem if you ever make the accessors fancy*).

BTW, it sounds like you may have way too many controllers. See if you can't move some of your logic into model objects instead. That drastically simplifies your code, as Cocoa is designed to work with a model layer. Being controller-heavy is fighting the framework, which makes more work for you.

*By “fancy”, I mean doing things other than or in addition to the normal behavior of a given accessor method. For example, insertObject:in<Foo>AtIndex: normally just tail-calls [<foo> insertObject:atIndex:]; if you insert or store the object somewhere other than in an array in an instance variable, or if you do something else in the same method (such as tell a view that it needs to display), then your accessor method is fancy.

Answer 2

short answer that may not be the best practice:

[otherObject giveArray:[NSArray arrayWithArray:theMutableArray]];

Answer 3

the question is a good one, but not complete... do you just need to pass an array of strings or does the class you are passing to need to modify the array?

In general, it's not a problem to simply pass around an NSMutableArray*, however you need to be careful, because you are just passing a pointer ( so if you retain it somewhere, you need to be aware that the owner or some other class may modify the array ). generally spoken you would want to use NSMutableArray to dynamically build up an array of objects and when you need to share them, then make a non-mutable copy and pass that along.

 NSMutableArray* myArr = [NSMutableArray arrayWithObjects:@"1",@"2",@"3",@"four",nil];
 // maybe modify the array here...
 NSArray* nonMut = [[myArr copy] autorelease];
 [someObject doWork:nonMut];

|K<

Answer 4

I think the pattern that's best for your situation is delegation. Your LoginController shouldn't have to know what class it's sending this data to. Instead, you would implement a LoginControllerDelegate protocol

@protocol LoginControllerDelegate <NSObject>

@optional
- (void)loginController:(LoginController *)loginController didReceiveLoginIDs:(NSArray *)ids;

@end

Then, in your LoginController class, you would implement a delegate property like this:

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

Then, when you've actually got something to communicate to the delegate, you would write this:

if ([self.delegate respondsToSelector:@selector(loginController:didReceiveLoginIDs:])
    [self.delegate loginController:self didReceiveLoginIDs:[NSArray arrayWithArray:loginIDs]];

The object that should receive the login IDs would incorporate the LoginControllerDelegate protocol like this:

@interface SomeOtherClass : NSObject <LoginControllerDelegate>

And you would implement the loginController:didReceiveIDs: method in SomeOtherClass.

This way, instead of your LoginController needing to have intimate knowledge of the other classes in your project, you simply establish a mechanism for sending that data to whatever object is interested in it when it becomes available. If you later change which object should receive the login IDs, you only need to choose a different delegate.