When you start to write iOS programs soon, you should start to face a lot of delegate,
Whether you use someone else's library or write your own library, you may not be able to escape delegate.
In order to fear that some people do not know what is delegate, here is a brief introduction,
Delegate Chinese is called a delegate, it is often used within class to handle some event "delegate" to others to complete.
For example, XML parser might know how to parse XML, but the parse to what to do with XML parser may not be known.
So Nsxmlparser provides a nsxmlparserdelegate for the client to do,
When parse is to an element, it callback the message defined by delegate,
Let him go to the client and decide how to deal with this element.
Well, I admit I have a vague explanation, but I'm not going to ask you to understand what a delegate is,
It's something you might want to pay attention to when using or designing a delegate.
When designing delegate in our class, we usually have a few caveats.
Assuming that my class is called MyClass, then we may have a definition of a myclassdelegate this protocol as my delegate protocol.
And that's what we might write in MyClass.
@protocol myclassdelegate <NSObject>
-(void) Myclassonsomeevent: (myclass*) MyClass;
@end
@interface MyClass
{
Id<myclassdelegate> _delegate;
}
@property (nonatomic, assign) delegate;
@end
The above code we notice delegate this property is defined as @property (assign).
Why don't we use assign instead of retain?
The reason is that in iOS reference counting environment, we have to solve the problem of circular count.
Let's write about how we usually use delegate, the following code I think we should not strangers
-(void) someaction
{
MyClass = [MyClass new];
Myclass.delegate = self;
....
}
This way, it's going to be circular reference soon.
Suppose the code above is written in a Myviewcontroller object,
And then once Myviewcontroller's reference count turns 1,
Myviewcontroller and MyClass these two brothers two left each other retain, it becomes an island, also?? So it caused the memory leak!!!
Because of this, the official iOS file will be recommended to us so the delegate are to use Assign property.
The so-called "weak reference" property, his characteristic is that although will hold each other's reference, but will not increase retain count.
So down, when Myviewcontroller's retain count becomes 0, it will dealloc.
At the same time in the Dealloc, also put MyClass release, then MyClass also followed by release.
-(void) dealloc
{
[MyClass release];
[Super Dealloc];
}
Is this the end of the story? Not yet yo ...
And here's the one thing that people often forget is that the above dealloc is potentially dangerous to write.
It's supposed to change.
-(void) dealloc
{
Myclass.delegate = nil;
[MyClass release];
[Super Dealloc];
}
You may be wondering if MyClass is going to be release soon? Why do you have to set his delegate to nil first?
That's because we assume that MyClass will be dealloc soon, but the reality is that this is not necessarily the case,
It is possible to build a nsurlconnection inside, or to do something and make other objects retain myClass.
If MyClass does not dealloc immediately, does his myclass.delegate point to an illegal position? (This kind of pointer is called dangling pointer)
The workaround is in Myviewcontroller's Dealloc, before release MyClass,
The original point to their own delegate should be set to nil, so as to avoid crash happen.
Before I wrote project, a large part of the crash was caused by this, because this problem usually does not happen every time,
But when it happens, it's hard to re-copy it, so don't be careless.&NBSP;
&NBSP;
But it is very exciting to iOS5 in the automatic Reference counting this problem can be improved. &NBSP;
presents a new concept of weak reference in Arc to replace the original Assign,&NBSP;
Weak reference refers to an object that has been retain by dealloc count zeroing, and this weak reference is automatically set to nil. &NBSP;
and original?? The old assign approach, called __unsafe_unretained in Arc, is only for compatibility with iOS4 versions below. &NBSP;
Review Focus: &NBSP;
If you are writing the library to others, remember to set your delegate to assign property, so that it will not cause circular reference When you are going to start using someone else's library, remember to set delegate to nil when you dealloc yourself, to avoid crash things happening. &NBSP;
References&NBSP;
[1] Communicating with Objects