Is there a way to know if an object is already registered as an observer for a particular notification?
In my implementation I have to add and remove the observers on the fly. For some reason, there is a random issue where the listener is receiving twice the same notification. I know I have to review my coding but It will be easier to fix for me if I could know this info.
Thanks.
No. There is no way to query this information. If you need it, you need to keep track of that yourself.
You might want to look into NSNotificationQueue. Here's the overview from Apple. It sounds like this could help you stop receiving duplicate notifications:
NSNotificationQueue objects (or simply
notification queues) act as buffers
for notification centers (instances of
NSNotificationCenter). Whereas a
notification center distributes
notifications when posted,
notifications placed into the queue
can be delayed until the end of the
current pass through the run loop or
until the run loop is idle. Duplicate
notifications can also be coalesced so
that only one notification is sent
although multiple notifications are
posted. A notification queue maintains
notifications (instances of
NSNotification) generally in a first
in first out (FIFO) order. When a
notification rises to the front of the
queue, the queue posts it to the
notification center, which in turn
dispatches the notification to all
objects registered as observers.
Every thread has a default
notification queue, which is
associated with the default
notification center for the task. You
can create your own notification
queues and have multiple queues per
center and thread.
Related
I am doing a notification Stream where each notification is shown for 5 seconds while business logic is allowed to keep adding new notification to the notification list.
Problem: Notification is shown as soon as they are called (or added to the Stream) which leads to many notification showing up at the same time
I don't have a code as I'm looking for a generic answer in Dart (whether it's Stream, StreamQueue or manipulating Stream controller)
Edit: I would like to work with Future rather than a fixed, periodic 5-second timer as mentioned above. For example: If a user dismiss the notification manually before 5-second is up, the next notification should appear immediately
Thank you
If you for instance do
DataBase.database().refrence().observe(.valueChanged....
//code here
)
more then one time in the same spot, does this create a stack of observers? I want to make sure I only have 1 observer per spot. Does calling this method multiple times create more then one observer?
If you attach multiple observers to the same location in the database, the SDK is smart enough to internally only register with the server to receive updates to that location once. It doesn't duplicate the amount of data sent to the app. All your observers at that location will still receive the updates, so you will need to unregister each to stop receiving updates.
Just wondering, does anyone have experience with activating large amounts of NSNotification observers at a time?
What is the overhead of an observer? Is it reasonable to run, say, 50 or 100 or more observers at a time?
I have an application that displays a scrolling list of media from database and I want to implement NSNotificationCenter as a scalable method of listening for individual pieces of media and allocating them to the proper UIViews
Cheers,
Doug
Notification does not have overheads if they are processed in background. If you process NSNotification in one single thread then any one of the observers can mishandle it which would lead to a blocking thread. If this thread happens to be the main thread (in your case it is ) then app will freeze .
It depends upon the way notification is handled. Sending notification is not an overhead they are just 50 -100 method calls just like any other methods. (I have 5000 methods in my app). The issue is thw way it is handled. If each observer blocks the notification for a long time then nothing can be done. I will suggest using NSNotification queues instead NSNotification Queue
If time permits I would also suggest to refer reading article on Objects Communication by apple.
I'm going to take J2theC's advice on this one..
I'm currently shifting the design pattern to use delegate methods to prevent any freezing..
Thanks for the feedback!
I want to know how long does it take from posting a notification to getting the notification.
The reason is that I want to find out if the observer pattern is suitable for me. I don't want that another view controller can change the value before the notification has been sent and processed. I'm afraid that another process (thread?) is faster and the value will be overwritten when it shouldn't.
A notification center delivers messages synchronously, which means that the postNotification: method does not return until all objects registered to receive the notification have processed the notification. In other words, you can think of it as taking no time between posting a notification and receiving the notification.
There are a few extra things you'll need to be aware of:
Notifications are received on the same thread in which they are posted. If you move a notification over to the main thread using performSelectorOnMainThread:withObject:waitUntilDone:, you can break the synchronous behavior if waitUntilDone is set to NO. If waitUntilDone is set to YES, the thread passing the notification will block until the main thread has finished performing the specified action.
There is no guarantee of the order in which a notification will be received by its observers. If a single notification has multiple observers, don't rely on those observers receiving the notification in any particular order.
Given the above, and knowing which thread is posting notifications in your application and which thread needs to process them, you should be able to figure out whether the observer pattern will work for you.
you can use enqueueNotification for finer grained control over the processing of the notifications, but in the end I believe you can run into the same issue you have expressed concern about regardless of a NotificationCenter implementation or not
I am interested in knowing whether I can expect the observing object's method to be pushed onto the stack before the posting object's method has been completed and removed.
The short answer is yes... "Regular notification centers deliver notifications on the thread in which the notification was posted. Distributed notification centers deliver notifications on the main thread".
However, Apple has docs on this very subject that you may find helpful, and from which the above quote was pulled:
Notification Programming Topics: Delivering Notifications to Particular Threads
Just bothered to look it up myself, shameful:
From the class reference: NSNotificationCenter posts all notifications synchronously
Also, if you prefer, you can use NSNotificationQueue to post notifications asynchronously