iOS messaging mechanism

Each application is more or less composed of loosely coupled objects that need to be delivered in order to accomplish the task well.

The message delivery mechanism is all that is available:

The Core Data managed object context is the sender of the notification, and the body that obtains the notification is the recipient. A slider (slider) is the sender of the action message, and the responder that corresponds to implementing the action in the code is the recipient. An attribute in an object supports KVO, so who modifies the value, who is the sender, and the corresponding observer (Observer) is the recipient.

KVOKVO provides a mechanism for notifying observers of these values when a property value in the object has changed. The implementation of KVO is contained within the foundation, and many of the frameworks built on the foundation are dependent on the KVO. If you are interested in changing the value of an object, you can use the KVO message passing mechanism. There are two requirements, first, the receiver (the message that will receive a change in value) must know the sender (the object whose value will change). In addition, the receiver also needs to know the life cycle of the sender, because the viewer's registration needs to be canceled before the sender object is destroyed. If both requirements are met, the message can be 1-to-many during messaging (multiple observers can register values in an object). If you plan to use KVO on the core data object, you need to know that this is a bit different from the general KVO usage. That is the failure mechanism that must be combined with core data (faulting mechanism), and once the core data fails, it will trigger the observer for its properties (even if the property values have not changed). NotificationNotification (notifacation) is a good mechanism for message delivery in unrelated two-part code, and it can broadcast messages. In particular, you want to deliver rich information, and you don't necessarily expect anyone to care about this message. Notifications can be used to send arbitrary messages, even a userinfo dictionary, or a subclass of Nsnotifacation. The uniqueness of the notice is that both the sender and the receiver do not need to know each other. This enables the delivery of messages between very loosely coupled modules. Remember, this messaging mechanism is one-way, and you can't reply to a message as a recipient. ‘ delegationIn the Apple framework, the delegation pattern is widely used only. Delegation allows us to customize the behavior of an object and to receive certain events. In order to use the delegation mode, the sender of the message needs to know the recipient of the Message (delegate), which in turn is not necessary. The sender and receiver here are relatively loosely coupled because the sender only knows that its delegate is following a particular protocol. The delegate protocol can define any method, so you can define exactly what type you want. You can process the message content in the form of a function parameter, and the delegate can also respond to the sender in the form of a return value. Delegation is a very flexible and straightforward way to do this only if you need to deliver messages between the relatively close two modules. However, the transition to use delegation also has a certain risk, if the two objects are more tightly coupled, can not be independent of each other, then there is no need to use the delegate protocol, in this case, the object can know the type of each other, and then directly to the message delivery. such as Uicollectionviewlayout and nsurlsessionconfiguration. BlockBlock is relatively new technology, which first appears in OS X 10.6 and iOS 4. In general, block can satisfy the message passing mechanism implemented with delegation. However, both of these mechanisms have their own needs and advantages. When block is not considered, it is generally considered that the block is very susceptible to retain rings. A potential retain loop occurs if the sender needs to Reatain block and cannot ensure that the reference is nil. Suppose we want to implement a table view and use block instead of delegate as a selection callback, such as Self.myTableView.selectionHandler = ^void (Nsindexpath * Selectindexpath) {};. The problem with this code is that self retain the table view, and table view is able to use block later to retain block. And table view can't get this quote nil, because it doesn't know when it's not going to need this block. If we can not guarantee to break the retain ring, and we need to retain sender, this time block is not a good choice. Nsoperation can use block very well, because it can break the retain ring at some time: self.queue= [[nsoperationqueue alloca]init];myoperation *operation = [[Myoperation Alloca]init];operation.completionblock = ^{[self finishedoperation];}; [Self.queue addoperation:operation];. At first glance this seems to be a retain ring: the self retain queue,queue retain operation, operation retain the completion block, and completion Blockretain the self. However, when operation is added to the queue, it causes the operation to be executed at some point and then removed from the queue (if not executed, there is a big problem). The retain ring was broken after a single queue was removed from the operation. Another example: Here is the implementation of a video encoder class, which has aA method named Encodewithcompletionhandler:. To avoid the retain ring, we need to make sure that the Encoder object is able to nil its reference to the block at a certain time. Its internal code is shown below: 

2. @Interface Encoder ()
4. @property (nonatomic, copy) Void (^completionhandler) ();
6. @end
10. @implementation Encoder
14. -(void) Encodewithcompletionhandler: (void (^) ()) handler
16. {
18. Self.completionhandler = handler;
20. //Do the asynchronous processing ...
22. }
26. This one would be called once the job was done
28. -(void) finishedencoding
30. {
32. Self.completionhandler ();
34. Self.completionhandler = nil; //<-Don ' t forget this!
36. }
40. @end

In the above code, once the encoding task is complete, the complietion block is called and the reference is nil. If the message we send is a one-time (specific call to a method), because it breaks the potential retain ring, using block is a good choice. In addition, if you want to make your code more readable and consistent, it's best to use block. According to this idea, block can often be used for completion handler, error handler, etc. target-actionTarget-action is primarily used in messages that need to be passed in response to user interface events. This mechanism is supported by Uicontrol in iOS and Nscontrol/nscell in Mac. Target-action establishes a very loose coupling between the sender and receiver of the message. The recipient of the message does not know the sender, or even the sender of the message does not need to know the recipient of the message beforehand. If Target is nil,action is passed in the response chain (responder chain), it is known to find an object that can respond to Aciton. In iOS, each control can have multiple target-action associated with it. One limitation of the mechanism based on target-action message delivery is that messages sent cannot carry custom payload. In the action method of the Mac, the receiver is always placed in the first parameter. In iOS, the sender and the event that triggered the action can optionally be used as parameters. In addition, there is no other way to control the content of the Send action message.

• http://www.cnblogs.com/zylin/

iOS messaging mechanism