Use block for Event Callback to simplify code, improve development efficiency, and block callback

Use block for Event Callback to simplify code, improve development efficiency, and block callback

When we customize a view, we usually need to consider the encapsulation and reuse of the view. Therefore, how to callback the view event to the Controller is a matter of consideration. Generally, the optional methods include target-action and delegate, and the strongly recommended block. The target-action and delegate methods are inconvenient, that is, the configuration code and action Code are not in the same place. You must write one more selector method or delegate method, this brings about a problem. Once the code is long or there are many selector methods, it is very inconvenient to find them. Writing the RESPONSE event directly in the configuration area is the ideal choice! The ideal way to achieve this is to use block for Event Callback ~ For example, if there is a button in the view, you need to call back the RESPONSE event of the button to the controller. What should you do? The most troublesome way is to use delegate. You need to define the delegate protocol for the view, implement this method in the controller, and write so much code, it's just to respond to the button event (the delegate method cannot be written together with the set view). Isn't that easy? Can you save the steps for defining the Protocol to implement the protocol? Yes! Just use block to add a block attribute to the view for callback. When the view is configured, the event is uploaded with block, and then the corresponding event of the button is set to execute the block, in this way, the configuration code and callback can be written together. It looks pretty good ~~ However, adding an event to the button is just to execute a block, which is repetitive. Can you optimize this step? Yes! Simply use the addTarget method of the button. The addTarget method is not designed to simplify this situation ~ In this way, the configuration code and corresponding events cannot be written together... Can you combine these two methods? Yes! Use LXMBlockKit (https://github.com/Phelthas/LXMBlockKit) on ~ LXMBlockKit encapsulates a-(void) addButtonCallback :( UIButton * sender) method for UIButton to allow the button to do the target itself and then respond to the event !!! You don't need to repeat the code. You just need to set the callback !!!

Typical method of button events:

[testButton addTarget:self action:@selector(handleButtonTapped:) forControlEvents:UIControlEventTouchUpInside]; - (void)handleButtonTapped:(UIButton *)sender {        NSLog(@"handleButtonTapped");        }

Use the Block statement:

   [testButton addButtonCallback:^(UIButton *sender) {        NSLog(@"handleButtonTapped");   }];

It can be seen that a lot of code is saved, and the Event Callback is written in the configuration of the button, so you don't have to look for it back and forth ~~ Note that weakSelf must be used in block callback! Using self directly will inevitably lead to loop reference !!! WeakSelf must be used in block callback! Using self directly will inevitably lead to loop reference !!! WeakSelf must be used in block callback! Using self directly will inevitably lead to loop reference !!! Let's talk about important things three times !!! As long as the view is added to the Controller, it will be strongly referenced, and the block is strongly referenced by the view. Therefore, if the block references self again, it will be referenced cyclically... I haven't found how to use code to judge whether self is referenced in the block for a long time, so I have no way to prompt that I have to be conscious... No way. You can make it a good habit. Similar implementation methods include UIBarButtonItem and UIGesture. You can use this method to greatly simplify the code ~ NSNotificationCenter can also be implemented in a similar way, and automatic removeObserver can be implemented. The specific implementation method is slightly different. It mainly uses the dealloc principle when attributes are released, for details, refer to Nick Lockwood's FXNotifications (https://github.com/nicklockwood/FXNotifications), I basically re-typed according to their own code habits. You can also refer to facebook's KVOController (https://github.com/facebook/KVOController) or the great god zwaldoski BlocksKit (https://github.com/zwaldowski/BlocksKit) The main purpose of this library is to simplify their usual code, therefore, the various controls of various events are not completely encapsulated, so currently only these categories are available, and other controls will be added later ~ If you have any questions, please feel free to discuss them ~