Objective-C learning path delegation Mode

Objective-C learning path delegation Mode

Objective-CLearning pathDelegateThe mode is described in this article,DelegateMode is very important, such as the official interactive API,DelegateThis mode is very common, for example, setanimationdelegate of uiview, set the animationDelegate. Not understoodDelegateMode, you cannot quickly understand the use of many APIs, because they use the same mode. If you understand this mode, you will get started immediately.

Let's talk about what the delegated mode is for in plain words. ActuallyObjective-CThe delegate mode in is similar to the callback mechanism or listener mechanism in Java. Or, it is similar to the onclick events and functions in JavaScript. For example, if you want to do something after clicking a button, there must be a View class and a control class, no matter what language or development tool you are using. The View class knows when a user clicks the button, but does not know what to do after clicking it. The control class knows what to do after clicking the button, rather than when the user clicks. Then, you can delegate the control class to the View class. When you click, The View class calls the control class.

If you have used Java swing for local graphical interface development, you should know that the view class contains a large number of (anonymous) Internal classes, or you want to register the listener, these mechanisms play a similar role as objective-C delegate. It can be understood as follows: Listeners and (anonymous) Internal classes are the part of implementation, but they do not know when something will happen. view classes call listeners when an event is sent, (anonymous) internal class, View class knows when something happens.

Write a simple example in the main method to simulate the role of delegation in view and control. Here, I have a screen class. Let's take it as a view. The requirement is that an explosion occurs when a screen is clicked. Then I have an action class which will implement the explosion action.

Delegate mode using protocols

The code below is very blunt, and will gradually evolve into a reasonable implementation. The first example is to explain how to implement it technically without practical application.

Here, because it is a simulation, we can regard the main method as a user re-operate interface, create a view by clicking it, and then call the screen instance method ontouch, here, the user clicks the screen by hand:

 
 

  
  
#import <Foundation/Foundation.h>   
  
  
#import "Screen.h"  
  
  
int main (int argc, const char * argv[]) {   
  
  
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
  
    Screen *screen=[[Screen alloc] init];   
  
  
    screenscreen.delegate=screen;   
  
  
    [screen onTouch];   
  
  
    [screen release];   
  
  
    [pool drain];   
  
  
    return 0;   
  
  
} 
 
 

Skip the following steps:

 
 

  
  
screenscreen.delegate=screen; 
 
 

Later.

Action class, which is implemented using the protocol here:

 
 

  
  
#import <Cocoa/Cocoa.h> 
  
  
@protocol Action <NSObject> 
  
  
- (void) doAction;  
  
  
@end 
 
 

Is a protocol that inherits the nsobject protocol. Note that nsobject is not a class here, and there is indeed a class with the same name. This Protocol defines a doaction method, which can meet the needs of "screen explosion" for example.

Next we will talk about the screen class and header files:

 
 

  
  
#import <Foundation/Foundation.h>   
  
  
#import "Action.h"  
  
  
@interface Screen : NSObject <Action> {   
  
  
    id <Action> delegate;   
  
  
}  
  
  
@property(nonatomic,retain) id <Action> delegate;  
  
  
- (void) onTouch;  
  
  
@end 
 
 

The ontouch method is used to simulate the method called after the screen is clicked by the user. The screen class implements the Action protocol. It also has an action-type member delegate. In order to set the delegate instance variable, property is also set for it.

Let's take a look at the implementation file:

 
 

  
  
#import "Screen.h"  
  
  
@implementation Screen  
  
  
@synthesize delegate;  
  
  
- (void) onTouch{   
  
  
    NSLog(@"on touch …");   
  
  
    if ([delegate conformsToProtocol:@protocol(Action)] &&   
  
  
        [delegate respondsToSelector:@selector(doAction)]) {   
  
  
        [delegate performSelector:@selector(doAction)];   
  
  
    }   
  
  
    NSLog(@"on touched.");   
  
  
}  
  
  
- (void) doAction{   
  
  
    NSLog(@"Bang!!!!!!!!!");   
  
  
}  
  
  
@end 
 
 

Here we will focus on the internal code of the ontouch method. We need to judge whether the delegate is an action protocol and whether there is a doaction method. This judgment is rigorous enough. If yes, call the doaction method of the action protocol.

In fact, there is no need for screen to implement the Action protocol, although this is often the case in development. Any class instance that implements the Action protocol can be set to the delegate attribute of screen.

The above example is not very similar to the situation encountered during development. The actual situation is often similar to the following example. First, let's look at the main method:

 
 

  
  
#import <Foundation/Foundation.h>   
  
  
#import "MyScreen.h"  
  
  
int main (int argc, const char * argv[]) {   
  
  
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
  
    Screen *screen=[[MyScreen alloc] init];  
  
  
    [screen onTouch];   
  
  
    [screen release];   
  
  
    [pool drain];   
  
  
    return 0;   
  
  
} 
 
 

A myscreen class is added here. It inherits from the screen class. The code here does not set the delegate attribute, because it is already set in the init method of the myscreen class. You will see it later.

The action protocol has not changed, but optional is added:

 
 

  
  
#import <Cocoa/Cocoa.h> 
  
  
@protocol Action <NSObject> 
  
  
@optional   
  
  
- (void) doAction;  
  
  
@end 
 
 

The screen class can be considered as an abstract class, which is mainly used for inheritance and reuse the code in the delegate mode. Header file:

 
 

  
  
#import <Foundation/Foundation.h>   
  
  
#import "Action.h"  
  
  
@interface Screen : NSObject <Action> {   
  
  
    id <Action> delegate;   
  
  
}  
  
  
@property(nonatomic,retain) id <Action> delegate;  
  
  
- (void) onTouch;  
  
  
@end  
 
 

Implementation file:

 
 

  
  
#import "Screen.h"  
  
  
@implementation Screen  
  
  
@synthesize delegate;  
  
  
- (void) onTouch{   
  
  
    NSLog(@"on touch …");   
  
  
    if ([delegate conformsToProtocol:@protocol(Action)] &&   
  
  
        [delegate respondsToSelector:@selector(doAction)]) {   
  
  
        [delegate performSelector:@selector(doAction)];   
  
  
    }   
  
  
    NSLog(@"on touched.");   
  
  
}  
  
  
@end 
 
 

The doaction method is not implemented here.

The following shows the header file of the myscreen class:

 
 

  
  
#import <Cocoa/Cocoa.h>   
  
  
#import "Screen.h"  
  
  
 
  
  
@interface MyScreen : Screen {  
  
  
}  
  
  
@end 
 
 

Implementation file of myscreen class:

 
 

  
  
#import "MyScreen.h"  
  
  
@implementation MyScreen  
  
  
- (id) init{   
  
  
    if (self=[super init]) {   
  
  
        delegate=self;   
  
  
    }   
  
  
    return self;   
  
  
}  
  
  
- (void) doAction{   
  
  
    NSLog(@"Bang!!!!!!!!!");   
  
  
}  
  
  
@end 
 
 

Delegate mode using categories

You can use category to implement the delegate mode. Or the above example. The following uses category to implement an example.

Main method:

 
 

  
  
int main (int argc, const char * argv[]) {   
  
  
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];  
  
  
 
  
  
    Screen *screen=[[Screen alloc] init];  
  
  
    [screen onTouch];   
  
  
    [screen release];    
  
  
    [pool drain];   
  
  
    return 0;   
  
  
} 
 
 

The header file of the screen class:

 
 

  
  
#import <Foundation/Foundation.h> 
  
  
@interface Screen : NSObject {   
  
  
    id delegate;   
  
  
}  
  
  
@property(nonatomic,retain) id delegate;  
  
  
- (void) onTouch;  
  
  
@end 
 
 

In this example, property does not actually play a role.

Implementation file:

 
 

  
  
#import "Screen.h"  
  
  
@implementation Screen  
  
  
@synthesize delegate;  
  
  
- (id) init{   
  
  
    if (self=[super init]) {   
  
  
        delegate=self;   
  
  
    }   
  
  
    return self;   
  
  
}  
  
  
- (void) onTouch{   
  
  
    NSLog(@"on touch …");   
  
  
    if ([delegate respondsToSelector:@selector(doAction)]) {   
  
  
        [delegate performSelector:@selector(doAction)];   
  
  
    }   
  
  
    NSLog(@"on touched.");   
  
  
}  
  
  
@end  
 
 

Here, if you run the Code, only the following logs will be printed:

 
 

  
  
2011-05-26 10:37:30.843 DelegateDemo[5853:a0f] on touch …   
  
  
2011-05-26 10:37:30.846 DelegateDemo[5853:a0f] on touched. 
 
 

Enter the category code named screenaction and its header file:

 
 

  
  
#import <Cocoa/Cocoa.h>   
  
  
#import "Screen.h"  
  
  
@interface Screen (ScreenAction)   
  
  
- (void) doAction;  
  
  
@end 
 
 

Implementation file:

 
 

  
  
#import "ScreenAction.h"  
  
  
@implementation Screen (ScreenAction)  
  
  
 
  
  
- (void) doAction{   
  
  
    NSLog(@"BANG!!!!!!");   
  
  
}  
  
  
@end 
 
 

Execute the following code:

 
 

  
  
2011-05-26 10:37:30.843 DelegateDemo[5853:a0f] on touch …   
  
  
2011-05-26 10:37:30.846 DelegateDemo[5853:a0f] BANG!!!!!!   
  
  
2011-05-26 10:37:30.846 DelegateDemo[5853:a0f] on touched. 
 
 

Summary:Objective-CLearning pathDelegateI hope this article will help you.