Five methods of monitoring, observation, and notification in cocoa

This article describes five methods for implementing the observer mode (also known as broadcaster/listener, publish/register or notify) in Objective C and the value of each method.

This article will include:
1. broadcaster and listeners)
2. Key Value observing)
3. Notification Center)
4. Context notification)
5. Delegate for observation)

About observer
The observer mode is one of the most powerful ways to maintain the abstract relationship between two modules. The observer mode includes a module that publishes an event and several instances of another module that responds to the event. It is different from calling the second module directly, because the first module does not need to focus on the number of observers, so as to achieve a more complete abstract relationship between the observer and the observer.

Manual broadcasters and listeners

Manually, the caster needs to keep an array (nsarray) or set (nsset) of the listener ). When an event needs to be notified to the listener, the broadcaster directly calls related methods on each listener.

In the broadcaster class, you may need an nsmutablearray, nsset, or nsmutabledictionary. Nsmutabledictionary is more suitable for using the event identifier type as the key value for each listener. On the broadcaster, you also need to register the listener and cancel the registration.
The method for sending messages to each object in nsarray or nsset is simple, as follows:

 

[Listenerscollection makeobjectsperformselector: @ selector (methodsupportedbyeverylistener)];

 

 

For more information, see collections programming topics for cocoa.
Advantage: the broadcaster has full control over the listener list.
Disadvantage: manually add or remove listeners in the collection (especially when the listener is not maintained for other reasons ). If you want to publish different messages, you need more manual work.

 

Key Value observation
The key value observation protocol has made great progress in automating the above process. In many cases, broadcasters do not need to do anything.
Each cocoa object is automatically processed by the addobserver: forkeypath: Options: Context: used to publish any object :. If the caster's "setter" method follows certain rules, the "setter" method will automatically trigger the observevalueforkeypath: ofobject: Change: Context: Method of any listener.
For example, the following code adds an observer to the "Source" object ::

 
 

  
  
[Source
  
  
Addobserver: Destination
  
  
Forkeypath: @ "myvalue"
  
  
Options: nskeyvaluechangenewkey
  
  
Context: Nil];
 
 
In this way, an observevalueforkeypath: ofobject: Change: Context: Message to destination will be sent every time setmyvalue: method is called. All you need to do is register the listener on the observed object and enable the listener to implement observevalueforkeypath: ofobject: Change: Context :.
For more information, see nskeyvalueobserving protocol reference. Advantages: built-in and automatic. You can observe any key path. Supports dependency notifications. Disadvantage: the broadcaster cannot know who is listening. The method must comply with naming rules to automatically observe the message operation. The listener must be removed before being deleted. Otherwise, the subsequent notification will cause crash and failure-but this is the same for all methods mentioned in this article.
Notification centerNsicationicationcenter provides a more decoupled approach. The most typical application is that any object can send notifications to the center, and any object can listen to notifications from the center. The code for sending a notification is as follows:
  
  

   
   
[[Nsicationicationcenter defacenter center]
   
   
Postnotificationname: @ "mynotificationname"
   
   
Object: broadcasterobject];
  
  
The code for registering to receive notifications is as follows:
 
   
   

    
    
[[Nsicationicationcenter defacenter center]
    
    
Addobserver: listenerobject
    
    
Selector: @ selector (receivingmethodonlistener :)
    
    
Name: @ "mynotificationname"
    
    
Object: Nil];
   
   
You can specify a specific broadcaster object when registering a notification, but this is not required. You may have noticed defacenter center. In fact, this is the only center you will use in the application. The notification is open to the entire application, so there is only one center. There is also an nsdistributednotificationcenter. This is used for inter-Application Communication. There is only one center of this type on the entire computer. For more information, see: Notification programming topics for cocoa advantages: Notification senders and recipients do not need to know each other. You can specify the method for receiving notifications. The notification name can be any string. Disadvantage: More code is required than the key value observation. The listener must be removed before deletion.
Context notificationIf the observed attribute is a declared attribute of nsmanagedojbect, you can listen to nsmanagedobjectcontextobjectsdidchangenotification. The nsnotification method is still used, but it is a little different because nsmanagedobject does not send notifications manually. The registration of this method is as follows:
    
    

     
     
[[Nsicationicationcenter defacenter center]
     
     
Addobserver: listenerobejct
     
     
Selector: @ selector (receivingmethodonlistener :)
     
     
Name: nsmanagedobjectcontextobjectsdidchangenotification
     
     
Object: observedmanagedobjectcontext];
    
    
In receivingmethodonlistener:, key values such as nsinsertedobjectskey, nsupdatedobjectskey, and nsdeletedobjectskey in the userinfo of the notification give a set of affected objects.
For more information, see nsmanagedobjectcontext class reference. advantages: it is the easiest way to track changes throughout nsmanagedobjectcontext. Disadvantage: it is only applicable to core data and does not provide specific information that affects objects.
Delegate for observationThe last cocoa simplified observer mode is delegation. In a broad sense, delegation can not only handle simple observations, but not necessarily require more. For example, all notifications of nsapplication and nswindow are sent to the delegate at the same time for processing. Some Classes send messages similar to notifications to their delegates, instead of sending notifications at the same time. For example, nsmenu sends menuwillopen: it delegates but does not send the corresponding nsnotification. To connect a delegate, you only need to call the following code on the object that supports the delegate:
     
     

      
      
[Object setdelegate: delegateobject];
     
     
The object can receive any delegate message it wants.
For more information, see cocoa fundamentals guide: delegates and data sources. Advantages: the classes that support it are detailed and specific. Disadvantage: this class must support delegation. At a time, only one delegate can be connected to a certain object.