How do I get this code to be approved by the Analyzer?

[JasonR]

I love the idea of using the Analyze function of XCode4 to catch potential memory leaks. But I can't get it to understand that allocating an object, and releasing it in a delegate method is not a memory leak. Here's the simplest example of code I could find that demonstrates this:

- (void)request:(SKRequest *)request didFailWithError:(NSError *)error {
    UIView *view = [self.view.window viewWithTag:kActivityTag];
    [view removeFromSuperview];
    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:NSLocalizedString(@"CantConnectAppStoreTitle", @"")
                                                    message:NSLocalizedString(@"CantConnectAppStoreMessage", @"")
                                                   delegate:self cancelButtonTitle:nil otherButtonTitles:@"OK", nil];
    [alert show];
}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex {
    [alertView release];
    UIView *view = [self.view.window viewWithTag:kActivityTag];
    [view removeFromSuperview];
    if (productArray == nil) [self dismissModalViewControllerAnimated:YES];
}

Here, the alertView is alloc'ed in the first function, and released when the delegate method is called. Since I know the delegate method has to be called, there's no chance of a memory leak. How do I get Analyze, or "Build and Analyze" on XCode3, to stop reporting this as a leak?

[BrianSlick]

Release it after you show it. Why are you splitting it up, especially since it is the first thing you do in the delegate method?

[bigdiggyiPhone]

[[alert show] autorelease];

Originally Posted by JasonR

I love the idea of using the Analyze function of XCode4 to catch potential memory leaks. But I can't get it to understand that allocating an object, and releasing it in a delegate method is not a memory leak. Here's the simplest example of code I could find that demonstrates this:

- (void)request:(SKRequest *)request didFailWithError:(NSError *)error {
    UIView *view = [self.view.window viewWithTag:kActivityTag];
    [view removeFromSuperview];
    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:NSLocalizedString(@"CantConnectAppStoreTitle", @"")
                                                    message:NSLocalizedString(@"CantConnectAppStoreMessage", @"")
                                                   delegate:self cancelButtonTitle:nil otherButtonTitles:@"OK", nil];
    [alert show];
}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex {
    [alertView release];
    UIView *view = [self.view.window viewWithTag:kActivityTag];
    [view removeFromSuperview];
    if (productArray == nil) [self dismissModalViewControllerAnimated:YES];
}

Here, the alertView is alloc'ed in the first function, and released when the delegate method is called. Since I know the delegate method has to be called, there's no chance of a memory leak. How do I get Analyze, or "Build and Analyze" on XCode3, to stop reporting this as a leak?

[JasonR]

Well, I'm splitting it up because I don't see anyone with a reference to it after I show it. I guess there's a secret retain in effect when I show? I can't find anything in the documentation about it.

[JasonR]

OK, I think I was able to get rid of all those warnings. Apparently show must retain the UIAlertView. But now I have code in my In App Purchase code that has the same problem. Here's the sample code from Apple, and it causes the same warning from the Analyzer:

- (void) requestProductData
{
   SKProductsRequest *request= [[SKProductsRequest alloc] initWithProductIdentifiers: [NSSet setWithObject: kMyFeatureIdentifier]];
   request.delegate = self;
   [request start];
}

- (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response
{
    NSArray *myProduct = response.products;
    // populate UI
    [request autorelease];
}

Any idea how to get this code to pass the Analyzer? It doesn't look like I can safely autorelease the request immediately after the start call.

[BrianSlick]

If autorelease doesn't work, then just make a property for it.

[JasonR]

Thanks for the first answer, it worked great. For the second one, is there an easy way to autorelease a value stored in a property? The only way I can see is to store it in a local variable and retain and autorelease it.

Or does anyone know for sure if an SKProductRequest has to be autoreleased after the delegate method is called?

[Chobie]

Originally Posted by JasonR

Thanks for the first answer, it worked great. For the second one, is there an easy way to autorelease a value stored in a property? The only way I can see is to store it in a local variable and retain and autorelease it.

Or does anyone know for sure if an SKProductRequest has to be autoreleased after the delegate method is called?

The last time I had a similiar problem was with MKReverseGeocode. In the end I made a property for it which retained it and released it in dealloc. Checking if the object is null before releasing to prevent bad access errors.

Is there a reason why you are using autorelease instead of release? It appears to me it is at the end of its use in the code samples provided above.

[JasonR]

The reason I'm using autorelease is because all the Apple sample code does. I'm chicken to do a regular release because the documentation is so slim that I don't know how long the request needs to stay around after the callback.

Sounds like a property to keep it around until dealloc of the view controller is the safest option. Thanks everyone.

[BrianSlick]

Well, you should release all retain and copy properties in dealloc, but that doesn't mean you need to keep the object alive until the view controller dies.

The first thing to do is be cognizant of your memory management responsibilities. So you could alloc it in the first method, and since you are given a reference to the same object you can release it in the second method. Even if Xcode doesn't recognize this as correct, you know it is correct.

If you want to clear up the warning, the next thing you should try is autoreleasing the object, either when you create it, or at minimum within the same method. I can't say for certain if this will work (meaning the object will live long enough) since it is different for different classes in different situations. So, try it in a few different scenarios (devices) and see if it works. If it does, you're good.

If that doesn't work, then use a property.

SKProductsRequest *request = ...
[self setTheRequestProperty:request];
[request release], request = nil;

Your obligations have been met, and the object will still be alive in the delegate method. But if you don't have a reason to keep it alive beyond that, then clear out the property in the delegate method:

[self setTheRequestProperty:nil];

Originally Posted by Chobie

Checking if the object is null before releasing to prevent bad access errors.

An unnecessary step. If it is nil, the release doesn't do anything.

[JasonR]

Brian, the main problem is that I know the existing code works fine, but I hate having warnings from the analyzer. The other problem is that since the official Apple sample code autorelease's the variable at the end of the delegate method, it makes me think maybe there's some hidden reason the variable has to be alive when the delegate method returns. The documentation is too slim for me to tell, and I'd hate to have it turn into a rare crash in users hands.

I'm probably over thinking it. There's no way this object is large enough for there to be harm in it staying alive for the life of the view controller. It's not worth the effort to try to save this little bit of memory.

[Desdichado]

I struggled with this for a while too, but I'd guess that:

[alert show];

is just a friendly way of saying

[[[UIApplication sharedApplication] keyWindow] addSubview:alert];

And so as soon as you show it, the window is maintaining a reference to it, and you can release it. I always release alerts as soon as I show them, and I've never had an issue.