强烈推荐给代表

Question

I read somewhere that if i have delegates in my app, i should keep a weak reference to them however, when i debug the app, the app doesnt want to move on, when i call on a delegate because my delegate has already been deallocated by the time it reached that method

why ?

If i put the reference to be "strong" everything works just fine, though i am not sure what are the consequences of that on my memory allocations and the fact that those delegates are not in "sharedInstance" classes....

code:

    @interface LoginProcessListener()
@property (nonatomic,weak)id<UserSettingsDelegate>userSettings;
@property (nonatomic,weak)id<DisclaimerDelegate>disclaimerDelegate;
@end

@implementation LoginProcessListener


-(instancetype)initWithUserSettings:(id<UserSettingsDelegate>)userSettings andDisclaimerDelegate:(id<DisclaimerDelegate>)disclaimerDelegate{
    self = [super init];
    if (self){
        [self setUserSettings:userSettings];
        [self setDisclaimerDelegate:disclaimerDelegate];
    }
    return self;
}

-(void)onLoginAuthenticationProcessFinished{
    User *user = [_userSettings getUserDetails];
    if(user && [_disclaimerDelegate isConfirmedDisclaimer:[user disclaimerInfo]]){
        [_disclaimerDelegate confirmedDisclaimer];
    }else {
        [_disclaimerDelegate needDisplayDisclaimer];
    }
}

-(void)onLoggedInUserDetailsReceived:(User *)user{
    [_userSettings saveUserDetails:user];  <== here my _userSettings is already nil;
}

Answer 1

when i debug the app, the app doesnt want to move on, when i call on a delegate because my delegate has already been deallocated by the time it reached that method

But that is your bug, which you must track down. The whole point of a delegate is that you must not permit it to die before the thing whose delegate it is. In general, if a delegate dies before the other thing does, you are doing something wrong; it is the job of a delegate to live as long as it is needed.

On the other hand (there is always an "other hand") it may be that what you are calling a delegate is not really a delegate. It is a delegate more or less if it is an object with a primary existence of its own. If it's just a packet of values or a purely ancillary object whose only purpose is in connection with the object keeping a reference to it, then it is not a delegate and a strong reference is correct.

Answer 2

Yours architecture is wrong. It's should be:

@interface UserSettings
@property (nonatomic,weak)id<UserSettingsDelegate>userSettingsDelegate;
@end

@interface Disclaimer
@property (nonatomic,weak)id<DisclaimerDelegate>disclaimerDelegate;
@end

Actually yours userSettings not real delegate, it just member of LoginProcessListener, so you may use strong references.

Commonly id<UserSettingsDelegate> creates UserSettings and own reference on it. If UserSettings will own reference at id<UserSettingsDelegate , then there will be retain loop.

Answer 3

when i debug the app, the app doesnt want to move on, when i call on a delegate because my delegate has already been deallocated by the time it reached that method

What's your seeking is how a weakly defined property behaves.

Via the docs: https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html#/apple_ref/doc/uid/TP40011210-CH5-SW30 )

Because a weak reference doesn't keep an object alive, it's possible for the referenced object to be deallocated while the reference is still in use. To avoid a dangerous dangling pointer to the memory originally occupied by the now deallocated object, a weak reference is automatically set to nil when its object is deallocated.

Simply put, if the delegate is no longer allocated, it's being released elsewhere.

With that said, your bug is likely not there at all, but elsewhere. You're going to have to backtrace _userSession to verify where it's being created and what objects have strong references to it.

Answer 4

Using a strong reference to a delegate is permissible, but you need to understand what is going on as it has risks that you should be aware of.

Apple's documentation kind of glosses over this, just saying that delegate users keep a weak link to the delegate, and in general this is true, but there are cases, and yours may be one of them, where it makes sense to keep a strong reference. In general, this happens in asynchronous code where the delegate might otherwise be released before it is used.

Too much hand waving: here is a concrete example. NSURLConnection needs a delegate to do asynchronous IO. In order to make this reliable and to greatly simplify it's usage, NSURLConnection keeps a strong reference to it's delegate as long as it needs one. Here is a quote from the NSURLConnection documentation :-

"Note: During a request, the connection maintains a strong reference to its delegate. It releases that strong reference when the connection finishes loading, fails, or is canceled"

In simple terms, under ARC, "releases that strong reference" probably means setting the property to nil.

Summary: If you know what you're doing, use strong references when you have to, and document well so that the next person to see that code understands why you did it.

Answer 5

You can temoprarily make a strong reference to the delegate object, which is excatly what NSURLConnectionDelegate protocol does. I do it like this:

Let's say i have a protocol for downloading images.

@implementation AsyncImageLoadManager <NSURLConnectionDelegate>

static char delegateStrongReferenceKey;
.......
-(void)startDownload {
    ....
    objc_setAssociatedObject(self, &delegateStrongRefernceKey, _delegate, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
    _imageConnection = [NSURLConnection connectionWithRequest:request delegate:self];

    objc_setAssociatedObject(self, &delegateStrongRefernceKey, _delegate, OBJC_ASSOCIATION_RETAIN_NONATOMIC);

    _downloadTaskID = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{ //I use tihs instead of [connection start]; so that download continues if app goes to background
        [_imageConnection cancel];
        [[UIApplication sharedApplication] endBackgroundTask:_downloadTaskID];
        _downloadTaskID = UIBackgroundTaskInvalid;
        objc_setAssociatedObject(self, &delegateStrongRefernceKey, nil, OBJC_ASSOCIATION_ASSIGN);
    }];

}

..../// and in connectionDidFinishLoading and connectionDidFailWithError you release the strong reference with:
[[UIApplication sharedApplication] endBackgroundTask:_downloadTaskID];
_downloadTaskID = UIBackgroundTaskInvalid;
objc_setAssociatedObject(self, &delegateStrongRefernceKey, nil, OBJC_ASSOCIATION_ASSIGN);