tags:

views:

937

answers:

5

I understand you need to be careful with autorelease on the iPhone. I have a method that is returning a class 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 send 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?

+2  A: 

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.

NilObject
+12  A: 

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.

Alex
+1  A: 

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.

Chris Lundie
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.
Peter Hosey
+8  A: 

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.

Chuck
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?
bobobobo
@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.
Chuck
+1  A: 
thierryb