Memory Management release or autorelease?

Question

Hi!
Im am finishing my app and starting to optimize and analyze my code with instruments..
There are still some things concerning memory management I dont understand..
1. I'm starting a urlConnection. My class implements the connection delegate, so, it is "waiting" for the response data in a background thread. If I am clicking "build & analyze", XCode complains about a potential memory leak for the getMessageHeaderConnection variable if I am not releasing it. Should I release it (variant 1), or should I autorelease it (variant 2)? Releasing means, that the object is destroyed, right? But: If am releasing it (variant 1) my getGroupMsgHeaders:groupId method doesn't stop immediately, it is still alive, but it should be dead, right?
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
GetMessageHeaderConnection *getMessageHeaderConnection = [[GetMessageHeaderConnection alloc] initWithDelegate:self];
getMessageHeaderConnection.currentUserLocation = currentUserLocation;
[getMessageHeaderConnection getGroupMsgHeaders:groupId];
[getMessageHeaderConnection autorelease]; //variant 2
[getMessageHeaderConnection release];//variant 1

Answer 1

sommeralex wrote:
1. I'm starting a urlConnection. My class implements the connection delegate, so, it is "waiting" for the response data in a background thread.
Are you sure that is the best strategy? Threading can make things painfully difficult and complicate your life, including where autorelease is concerned. You should be able to do this on the main thread.
If I am clicking "build & analyze", XCode complains about a potential memory leak for the getMessageHeaderConnection variable if I am not releasing it. Should I release it (variant 1), or should I autorelease it (variant 2)?
Neither, apparently.
Releasing means, that the object is destroyed, right?
Yes.
But: If am releasing it (variant 1) my getGroupMsgHeaders:groupId method doesn't stop immediately, it is still alive, but it should be dead, right?
If that is running in another thread, then it will continue running, but "self" will be invalid and will crash when you access it. Don't bother testing it, because it could work just fine in debug mode. It will still crash when someone else tries it.
Standard procedure in this case is to make sure that the method running in the background thread retains itself until the method is done. Many of the built-in threading methods or other asynchronous methods (such as NSInvocation) will do that automatically. You can study the documentation to find out where that happens.