Hi Dave,
With all the top coders getting fired-up/tangled up over this thread,I'm thinking we should get a better idea of the original situation you are dealing with.
You talked in terms of when the object comes back 'alive'....obviously the same programmatic object doesn't come back alive, but the logical object does ... like the 'Bob' account, and the 'Lisa' account, serialized, stored, then new programmatic object equivalent recreated. Do I understand you right?
You also mentioned 'getting last notification'. I don't understand what you really want...Notifications are a broadcast communication, and the 'last' notification is going to be quite disconnected (logically) from the receiving object.
You seem to want the re-incarnated object to pick up where it left off,but with the Notification model you're using, you've still missed the train car you wanted, and getting next car in front of the current car is still no good.
I seems to me that what you want is nothing to do with the NSNotification model of communication but traditional message passing, buffered by a persistent message que between objects.
Maybe have a central Que/Proxy object that:- holds a dictionary of ques (each an array of Notification objects), identified by the unique identifier of your receiving object (like Bob's account number);
- registers itself for the Notification;
- for each receiving object:
- if 'alive'/exists: send notification
- else: add to que for that object
then when each object comes 'alive' it pulls from the Center's que
until empty, then rests.
As you can see I've sort of come full circle to what you (Dave) have now implemented, but with 2 final comments: (1) I agree with the others that you should make you own notification center *without* subclassing. (2) I still think there is something wrong with this design pattern ... there must be some better/more normal way to keep the data synchronized. Maybe the data manager (whatever object is responsible for the persistence and management of the receiver objects) should lookup the relevant data when instantiating the data object, or the data object needs to lazy-load the updated information from the data source.
P.S.: The other posters are right about the Notification model being 'loose-coupling': "At times, this tight coupling of two objects is undesirable—most notably because it would join together two otherwise independent subsystems. For these cases, a broadcast model is introduced" -- "Notification Programming Topics", page 4 <https:// developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/ Notifications/Notifications.pdf> I, personally, have always considered Notifications to be for non- essential, run-time only communication.
Manoah F. Adams https://federaladamsfamily.com/developer =========== On Sep 11, 2013, at 04:35 , Dave wrote:
Hi,Sorry for the lack of data in my original post! I Found the problem it was a Notification being sent to a dead object, it didn't happen very often, one crash after over an hour running continuously. I was more worried about the data I was passing not belonging to same thread (I recently added this code) rather than one the object being dead. I thought my modifications had caused the crash, but actually it was there all along hiding!Is there any problem with having all notifications handled by one object that doesn't go away, and have this ship the notificationa off to the correct object as long as it is still alive? The way this App is designed is I can tell if the object is allocated or not and if it is allocated, then I want it to receive notifications (In fact I ideally want it to get the last notifications sent regardless of if the receiver was dead or alive when the event occurred). At the moment I listen for the notification when the object is born and stop it listening when it dies. But when it it dies I have to save the data from the last notification somewhere and restore it when it is reincarnated. This is common to around 26 classes and I don't want to change all 26 to do the above, I'd rather the last value was remembered by the source of the notification and resent somehow on request.Any ideas? Cheers Dave On 10 Sep 2013, at 12:08, Dave <d...@looktowindward.com> wrote:Hi,I have a crashing problem when calling postNotificationName, the following method is called from an Operation Queue method/thread. It is called on the Main Thread (the operation queue method, uses performSelectorOnMainThread which calls "parseOperationCompleted" below. I've tried copying theResultDictionary or just passing it in the dictionary as is, same result.Any ideas what could be causing the crash? -(void) parseOperationComplete:(NSDictionary*) theResultDictionary { myUserInfoDictionary = [[NSMutableDictionary alloc] init];[myUserInfoDictionary setObject:self.pUpdateString forKey:kUserInfoLiveUpdateString]; [myUserInfoDictionary setObject:[theResultDictionary copy] forKey:kUserInfoLiveUpdateDictionary];[NSNotificationCenter defaultCenter] postNotificationName:kNotificationName object:self userInfo:myUserInfoDictionary];} Thanks in advance for any help! All the Best Dave _______________________________________________
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
