When does autorelease actually cause a release in Cocoa Touch?

Question

I understand you need to be careful with autorelease on iOS. I have a method that is returning an object it allocs which is needed by the caller, so in this situation -- as I understand it -- I need to send autorelease to the object in the callee before it returns.

This is fine, but once control returns to the phone (i.e. after my button click has been processed) it seems that the autorelease pool is released. I suspect this is how it is supposed to be, but I am wondering what is the best practice for this situation.

I have resorted to sending a retain message from the caller so that the object is not released and then explicitly releasing it in dealloc.

Is this the best approach?

Bibbye

Answer 1

The autorelease pool is typically released after each iteration of the run loop. Roughly, every Cocoa and Cocoa Touch application is structured like this:

Get the next message out of the queue
Create an autorelease pool
Dispatch the message (this is where your application does its work)
Drain the autorelease pool

What you describe is the expected behavior. If you want to keep an object around any longer than that, you'll need to explicitly retain it.

Auxiliary

Answer 2

Using autorelease is a way of saying, "Object, I don't want you anymore, but I'm going to pass you to somebody else who might want you, so don't vanish just yet." So the object will stick around long enough for you to return it from a method or give it to another object. When some code wants to keep the object around, it must claim ownership by retaining it.

See the memory management guidelines for everything you need to know to use autorelease correctly.

Barranca

Good answer BUT is this safe? Is there an example of a time when you return an object which you [[[object alloc] init] autorelease], but then the object goes away before you had a chance to use it? – Pseudo

@bobobobo: Not if you're following the memory management rules. The behavior of autorelease is quite predictable — the object will stay around until the current autorelease pool is drained, which won't happen until the end of the current event loop (unless you purposely make it happen sooner). If you, say, point an instance variable to the object but don't retain it and then try to access it much later, the object will have gone away before you had a chance to use it — but that's because you broke the memory management contract when you didn't retain the object. – Barranca

Answer 3

Here is an examle provided in the Apple Memory Management document:

– (id)findMatchingObject:(id)anObject 
{ 
    id match = nil; 
    while (match == nil) { 
        NSAutoreleasePool *subPool = [[NSAutoreleasePool alloc] init]; 
        /* Do a search that creates a lot of temporary objects. */ 
        match = [self expensiveSearchForObject:anObject]; 
        if (match != nil) { 
            [match retain]; /* Keep match around. */ 
        } 
        [subPool release]; 
    } 
    return [match autorelease];   /* Let match go and return it. */ 
}

Riccardo

Answer 4

Yes, that's the best approach. Autorelease is really only intended for interactions in code that you know. Once you're storing an object, you should either know that the object that holds a reference will not die/go out of scope until you're also done with the object, or you need to retain the object.

Whitneywhitson

Answer 5

It is only guaranteed that autoreleased objects will be released after the end of your method. After all, the method that called your method could have created its own pool and release it right after your method.

Education

Strictly speaking, even that isn't guaranteed, since you could create a pool in one method, autorelease some objects, and drain the pool in another method. A dubious design, but valid: The objects will last all the way from the pool's creation to the pool's drainage, regardless of the method that created the pool returning. – Peraza