The problem of delegate pointer in MRC

In the near project development, temporary was transferred to fix a page return when crash problem. The cause of this problem is also very coincidental, just the service address on the colleague's computer, also happens to network request response time crazy slow! A request to send back the time is about 40 seconds, if online, will certainly let users get mad!

When I open the project, when I click on the page to return, I find that the network request is still in the request, the first feeling is the memory management error. In the global breakpoint to navigate to the point of the problem, unexpectedly is the place where the delegate callback problems!

if (self.delegate && [self.delegate respondstoselector: @selector (test:)]) {[ Self.delegate Test:nil]; } 

This code is ubiquitous in iOS development, and its correctness is beyond doubt in the current version. At first I did not think it was delegate this side error, because I checked the property is indeed assign. In the Viewcontroller inside and check the related memory operation, in Dealloc found a serious problem, my VC is destroyed, the object unexpectedly wood has destroyed, this is indeed very strange. Because the structure of the project is a bit of wonderful, belong to MVC heavy users! The object that is not destroyed is what we call the object responsible for the business logic, where there is only a network request to where it is referenced, and delegate is set to self in the calling function parameter. In iOS development, we put the network request into a queue, and after the network request succeeds, the network request information is fetched in the queue and the request is removed. This can explain why our business Processing object reference count is greater than 1 and cannot be destroyed because it is a strong reference to the incoming self in the queue to join the network request. Although this is really unreasonable in design, I need only a delegate without a strong reference to the calling object. But think about this will not cause the program to hang up, although I have a reference count on your calling object plus 1, a big deal of memory late release, go through the callback, I actually call the VC is nil, so it will not be called.

That's it. I think VC must be nil, after all I see it destroyed in memory. The Xcode debug in zombie objects hook, re-debug, the results console printed a message sent to deallocated instance 0x90a3900, completely changed my world view! Delegate is not nil .... But my delegate is indeed assign! What is this for? The most fundamental reason is to confuse the weak in arc with the assign in the MRC ....

Weak and assign do not change the reference count for incoming objects. So the discovery of our delegate, in the MRC is assign, in arc is weak. But what is the difference between these two points? Both ensure that the reference count is not changed for the incoming object, but the weak object must be an OC object. Weak is more powerful than assign is when a pointing object is destroyed, all weak pointers to that object will be set to nil. So we can write such a simple judgment.if (self.< span class= "s2" style= "margin:0px; padding:0px ">delegate && [self.delegate respondstoselector: @selector (test:)]). In MRC, if the code is written directly, if the caller does not set delegate to Nil,delegate when the object is destroyed, it will become a wild pointer, which causes the program to hang. So in dealloc [XXX release] before, plus xxx.delegate = nil. This is why Apple has officially recommended that you use ARC,ARC in many places to ensure the robustness of the program.

The problem of delegate pointer in MRC