mccallum@gnu.ai.mit.edu)rfm@gnu.org)Date: Generated at 2024-11-18 21:56:13 +0100
Copyright: (C) 1996,1999 Free Software Foundation, Inc.
- Declared in:
- Foundation/NSNotification.h
Represents a notification for posting to an NSNotificationCenter . Consists of a name, an object, and an optional dictionary. The notification center will check for observers registered to receive either notifications with the name, the object, or both and pass the notification instance on to them.
This class is actually the interface for a class cluster, so instances will be of a (private) subclass.
nil user info argument.
- Declared in:
- Foundation/NSNotification.h
GNUstep provides a framework for sending messages
between objects within a process called
notifications. Objects register with an
NSNotificationCenter to be informed
whenever other objects post
NSNotification
s to it matching certain criteria. The notification
center processes notifications synchronously --
that is, control is only returned to the
notification poster once every recipient of
the notification has received it and processed it.
Asynchronous processing is possible using an
NSNotificationQueue
.
Obtain an instance using the +defaultCenter method.
In a multithreaded process, notifications are always sent on the thread that they are posted from.
Use the NSDistributedNotificationCenter for interprocess communications on the same machine.
Registers observer to receive
notifications with the name
notificationName and/or containing
object (one or both of these two must be
non-nil; nil acts like a wildcard).
When a notification of name
name containing object is
posted, observer receives a
selector message with this notification
as the argument. The notification center waits for the
observer to finish processing the
message, then informs the next registree
matching the notification, and after all of this
is done, control returns to the poster of the
notification. Therefore the processing in
the selector implementation should be
short.
The notification center does not retain
observer or object.
Therefore, you should always send
removeObserver: or
removeObserver:name:object:
to the notification center before releasing these
objects.
While it is good practice to remove an observer before releasing it, currently on MacOS it is possible to remove an observer even after the object has been deallocated. This is not documented behavior from Apple and could change at any time. In the interests of compatibility, this behavior will also be supported here.
NB. For MacOS-X compatibility, adding an observer multiple times will register it to receive multiple copies of any matching notification, however removing an observer will remove all of the multiple registrations.
Returns a new observer added to the notification
center, in order to observe the given
notification name posted by an
object or any object (if the
object argument is nil).
For the name and object arguments, the constraints and behavior described in -addObserver:selector:name:object: remain valid.
For each notification received by the center, the
observer will execute the notification
block. If the queue is not
nil, the notification
block is wrapped in a NSOperation and
scheduled in the queue, otherwise
the block is executed immediately in the
posting thread.
nil user info argument.
nil, they act like wildcards. The
observer may still remain registered for
other notifications; use
-removeObserver:
to remove it from all. If observer is
nil, the effect is to remove all
registrees for the specified notifications,
unless both observer and name
are nil, in which case nothing is done.