Self-manager Mode in iOS development

Self-ManagerFrom the slang inside our team, "eh? How many IOS developers did you just go to for the start-up company? "Just Me," "You're a Self-manager."

Recently, this idea has been taken as a design pattern that gives a Widget a greater right to take charge of its own events.
To give a simple chestnut, this view is responsible for the display of the Avatar:

Its responsibilities include:

1. Load and show avatar pictures with incoming URLs
2. Display some ancillary information, such as the flag of the Big V
3. Pass the event that the user clicked the avatar to the outer View Controller to jump to the user information page

The API for this Widget can look like this:

@interface Fdavatarview:uiview // Suppose Vipinfo is an Entity-(void) Configurewithavatarurl: (Nsurl *) URL vipinfo: (ID) info tapped: ( void (^) (void)) block; @end

The person using this control only needs to call this configure method to configure the incoming parameter and event handling. But then comes the problem of some egg-ache:

1. The caller of configure is Superview, the above example is a UITableViewCell, but the Cell layer does not know who their viewcontroller is, so we have to pass the click event upward, until you can get the Navigationcontroller, and then Push a page of user information.
2. This Avatar View can be thick and consistent across apps, which means that the block of event handling is scattered across the pages, as well as a lot of " Middle Man" that is "just forwarding events for the upward level"

To solve this problem, it is necessary to give this view the Handle of its own events, that Self-Managed is, in order not to destroy the purity of the view, the better practice is implemented in the Category:

@interface Fdavatarview (Fdavatarviewselfmanager)-(void) Selfmanagedconfigurewithavatarurl: (Nsurl *) URL Vipinfo: (ID) Info uid: (NSString *) uid; @end

It is best to invoke the API provided by the View main class when implemented:

@implementationFdavatarview (Fdavatarviewselfmanager)//added a UID parameter for the creation of the latter page- (void) Selfmanagedconfigurewithavatarurl: (Nsurl *) URL Vipinfo: (ID) Info UID: (NSString *UID {[Self configurewithavatarurl:url vipinfo:info tapped:^{        //Assuming the APP structure is Root --TabBar-Navigation-ViewcontrollerUitabbarcontroller *tabbarcontroler = (ID) [Uiapplication.sharedapplication.Delegate. Window.rootviewcontroller; Uinavigationcontroller*navigationcontroller =Tabbarcontroler.selectedviewcontroller; //Create user information View ControllerFduserprofileviewcontroller *profileviewcontroller =[Fduserprofileviewcontroller Viewcontrollerwithuid:uid];    [Navigationcontroller Pushviewcontroller:profileviewcontroller Animated:yes]; }];}@end

Using the same approach as AOP, adding a coupling to the APP hierarchy, you can encapsulate a global approach to the current top-level Navigation Controller If you feel this coupling is inappropriate.
In this way, the caller of the Fdavatarview only needs to configure the parameters, the rest of its own all-around, even if there are many places in the App avatar, logic code is only one copy.

Let's take another example:

Here are some of the functions that the button likes:

1. Show the number of likes you already have.
2. Click the button to perform a small animation, like number +1, and send a network request.
3. If you've already liked it, click to perform the reverse action.
4. If the network request fails to send, it is back to the pre-click state

@interface Fdlikebutton:uibutton-(void) Configurelikestatus: (BOOL) Likeornot count: (Nsinteger) Count Animated: (BOOL) animated; @end

Because it inherits from UIButton, the external can set its action directly, so it does not increase the parameters of Tappedhandler. External in the Click event need to call this configuration method, play a point like animation, and then send a network request, if the network request failed, you can call the API's non-animated version rollback state again. However, as in the previous example, the network request and event processing logic is the same, but the code is in the various pages, so the View is added to the Category self-managed mode:

@interface Fdlikebutton (Fdlikebuttonselfmanager)-(void) Selfmanagedconfigurewithlikestatus: (BOOL) Likeornot count: (Nsinteger) count; @end

The pseudo-code is implemented as follows:

@implementationFdlikebutton (Fdlikebuttonselfmanager)- (void) Selfmanagedconfigurewithlikestatus: (BOOL) Likeornot count: (Nsinteger) Count {[Self configurelikestatus:    Likeornot Count:count Animated:no]; [Self addtarget:self Action: @selector (likebuttontapped:) forcontrolevents:uicontroleventtouchupinside];}- (void) Likebuttontapped: (ID) Sender {//+1 or-1 with animation//Network Request ^ (Nserror *error) {//if (error) {//rollback//     }    // }}@end

Remember the interview question of the article also joked that "interview time to talk about design, architecture is good, but do not go to the UIButton of the sub-category in the network request the wonderful structure on the line", the result was himself hit a face. However, from the design, the Self-manager mode does not destroy the original MVC structure, the above two examples of View can still not be coupled with the specific business logic of the single take out. Use the Category method to move the code that should be written in Viewcontroller to the View file, allowing the functionality to be more cohesive.

The complexity of the program is not reduced by which cool design patterns, but only the complexity of the segmentation and control, namely:

1. Make a nasty piece of code into a few small pieces of less disgusting code.
2. Make disgusting code only in one place disgusting.

Self-manager Mode We practice when writing very happy, give a try, hope also can solve your distress.

Self-manager mode in iOS development