EODelayedObserverQueue
Enqueuing a Delayed Observer
The enqueueObserver method records an
EODelayedObserver for later change notification. However, enqueuing
is usually performed automatically by an EODelayedObserver in its objectWillChange method.
Hence, it's typically enough that an object being observed invoke willChange as needed. For example,
in Java Client and Application Kit applications, an EODisplayGroup
(EOInterface) does this (among many other things) on receiving an ObjectsChangedInEditingContextNotification
from
its EOEditingContext.
Although you can create individual EODelayedObserverQueues, you typically use the single instance provided by the static method defaultObserverQueue. Using separate queues bypasses the prioritization mechanism, which may cause problems between the objects using the separate queues. If you do use separate queues, your EODelayedObserver subclasses should record a designated EODelayedObserverQueue that they always use, and implement observerQueue to return that object.
If you need to remove an enqueued observer, you can do so using the dequeueObserver method. EODelayedObserver also defines the discardPendingNotification method, which removes the receiver from its designated queue.
Change Notification
The actual process of change notification is initiated by
the enqueueObserver messages that line observers
up to receive notifications. Regardless of how many times enqueueObserver
is
invoked for a particular observer, that observer is only put in
the queue once. The first observer enqueued during the run loop
also sets up the EODelayedObserverQueue to receive a message at
the end of the run loop. EODelayedObserver sets up this delayed
invocation in NSRunLoop.DefaultRunLoopMode, but you can change the
mode or add additional modes in which delayed invocation occurs
using setRunLoopModes (Yellow Box only).
notifyObserversUpToPriority cycles through the queue of EODelayedObservers in priority order, from ObserverPriorityFirst to the priority given, sending each observer a subjectChanged message. Each time, it returns to the earliest priority (rather than continuing through the queue) in case the message resulted in another EODelayedObserver with a earlier priority being enqueued. This guarantees an optimal delivery of change notifications.
Observer Proxies
It may not always be possible for a custom observer class
to inherit from EODelayedObserver. To aid such objects in participating
in delayed change notifications, the Framework defines a subclass
of EODelayedObserver, EOObserverProxy, which implements its subjectChanged method to invoke an action
method of your custom object. You create an EOObserverProxy, providing the
"real" observer, the action method to invoke, and the priority
at which the EOObserverProxy should be enqueued. Then, instead of
registering the custom object as an observer of objects, you register
the proxy (using EOObserverCenter's addObserver)
.
When the proxy receives an objectWillChange message,
it enqueues itself for delayed change notification, receives the subjectChanged
message
from the EODelayedObserverQueue, and then sends the action message
to the "real" observer.