is it possible to pass array as obj via nsnotification
Asked Answered
M

4

10

I could do this by using protocol and delegate but I would like to try with NSNotification

My task is sending an NSMutableArray via notification from one to another view. Is it possible to do

[[NSNotificationCenter defaultCenter] postNotificationName:@"reloadData" object:myArray];

Then, in the receiver, how can I get the passed myArray. I was reading and confused about the userInfo and object of notification object.

Please advice me on this issue.

Menial answered 24/7, 2012 at 14:46 Comment(1)
yeah I did try but when I catch the passed array.. Should I use [notification object] and catch it to NSMutableArray. how about userInfo. when should I use userInfo.Menial
A
32

An NSNotification has a property called userInfo that is an NSDictionary. The object is the NSObject that is posting the NSNotification. So usually I use self for the object when I'm setting up the NSNotification because self is the NSObject sending the NSNotification. If you wish to pass an NSArray using an NSNotification I would do the following:

NSArray *myArray = ....;
NSDictionary *theInfo =
  [NSDictionary dictionaryWithObjectsAndKeys:myArray,@"myArray", nil];
[[NSNotificationCenter defaultCenter] postNotificationName:@"reloadData"
                                                    object:self
                                                  userInfo:theInfo];

And then catch it using the following:

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(doTheReload:)
                                             name:@"reloadData"
                                           object:sendingObject];

where sendingObject is the object that is sending the NSNotification.

Finally, decode the array in doTheReload: using:

NSArray  *theArray = [[notification userInfo] objectForKey:@"myArray"];

That always works for me. Good luck!

Achromatism answered 24/7, 2012 at 15:0 Comment(7)
very quick question : when you were saying where sendingObject is the object that is sending the NSNotification and what is did is to create NSDictionary *sentOject = [NSDictionary alloc] init]; and pass it to [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(doTheReload:) name:@"reloadData" sentObject]` and I dont receive a notification at all.... Do I miss something in the middleMenial
no, sendingObject is the object that posted the NSNotification. So if it was posted by your AppDelegate, for instance, you would need to put your AppDelegate in the object: field. If it was sent by some viewController then you would need to put THAT EXACT viewController in the object: field. It must be the id of the object that sent the NSNotificationAchromatism
just modified and what I did is[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(doTheReload:) name:@"reloadData" object:[A class]] ; I put [A class] because A is the object that posted NSNotification.but still not work...I am thinking to create the object of A class by doing A *a = [[A alloc] init] but i doubt this one...Menial
No, you need to send it with self. You dont pass the CLASS of the object that is sending it, you pass the actual id of the object that is sending it, and then you need to catch the actual id of the object that it is sent from. If you don't know how to get that information it may work by using nil but I would not recommend it.Achromatism
@JustinPaulson if my controller that triggers the notification follows a different 'storyboard path' and does not directly link with the thing catching the notification, is the best way to feed the information through the appdelelgate?Pretence
@Pretence it really just depends on how you want to do it. If you can successfully catch the notification, then you might as well use it to pass the userInfo.Achromatism
Really Really Thanks @Justin Paulson :) and sendingObject I pass nil. and it works for me.Oppugn
P
2

You should use userInfo. It is for misc data you want to send with the notification. The object argument is for the object that the event is fired for. For example, if you want to monitor a certain MPMoviePlayerController (but not others), then you would sign up for only its notifications (via the object argument).

Pollard answered 24/7, 2012 at 14:53 Comment(5)
if he posts notification for himself, he could use the both object and userInfo. just he needs to know what he uses for what. :)Frawley
userInfo is a NSDictionary.However, I am passing NSMutableArray. Like you said, should I create an NSDictionary to hold my array.Menial
I have no idea why this was down-voted. This is exactly the right answer. You store the NSArray inside of the userInfo dictionary. As @Pollard says, the object should always be the object that is posting the notification. The array is not posting the notification, so it should not be the object. Failure to follow this convention consistently is a source of really frustrating bugs (usually with the symptom of bizarre "does not respond to selector" crashes).Boudicca
@ttran Yes, it is a dictionary so that you can conveniently store multiple pieces of information. Add your array to the dictionary (and anything you would like to)Pollard
@borrrden: I am deciding that should I or should not I create an dictionary to hold my object such as myArray. Now I know what to do. thanksMenial
F
1

it is very consistent because the object is the object and the userInfo is the userInfo when you post any notification using the -postNotificationName:object:userInfo: method.

yes, you can post any subclass of NSObject via the NSNotificationCenter.

Frawley answered 24/7, 2012 at 14:52 Comment(0)
N
1

Swift 4, Swift 5

NotificationCenter.default.post(name: Notification.Name("favoriteIsDeleted"), object: [message, self.viewModel.deleteSuccessIcon])

@objc func favoriteIsDeleted(notification: Notification) {
    guard let object = notification.object as? [String?], let message = object[0], let deleteSuccessIcon = object[1] else { return }
    // Code here ...
}
Neoplatonism answered 1/9, 2020 at 6:5 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.