To the bottom with didRecieveMemoryWarning

Question

I have to go to the bottom with the didRecieveMemoryWarning method. I have read like thirty threads about this topic on this forum. And every answer is differerent.

1. First question. Should you release objects in didRecieveMemoryWarning or just set them to nil? Or both?

2. I have read that I should release the tableView data source, if you have one, in the didRecieveMemoryWarning method. I have also read that you should just release IBOutlets i this method. I'm confused, what is correct here?

3. Is it only objects I initiate in viewDidLoad I should release in didRecieveMemoryWarning? Or is it properties I just assign to, for example: labelTitleText.text = @"Woodie Guthrie"? labelTitleText is a property in my header file.

In my application today, I release everything (also labels assigned like the example above) in my dealloc method. This doesn't feel right.

I would really appreciate a small code example so it becomes easier to understand, this is what the other threads is missing to, I've noticed.

Have a great day everyone!

Answer 1

didRecieveMemoryWarning is called when the phone is low on memory. You should release any resources that you can retrieve later when needed. Think about caches, unused objects and that kind of stuff.

It is my understanding that you shouldn't release IBOutlets and such in didRecieveMemoryWarning, because those are needed for the app to work correctly.

You should however release these in methods like viewDidUnload and of course in the dealloc as you've stated. (if you retained them at some point, most likely using a property)

Answer 2

The bottom line is that you don't actually need to release anything when you get a memory warning. However doing nothing greatly increases the likelihood that some app will be killed, and that app might be yours. But it might not be.

If you are actually using all the memory you have allocated (e.g. not images you could just reload again later, etc.) then do nothing (or save important state just in case), and hope some other background process gets killed or starved. More apps do this than you might think.

If you do have stuff you can release, release the big stuff (at least 1 VM page and larger). Releasing the small stuff (short strings, etc.) will make almost no difference as to whether or not some background app gets killed or starved.

Setting pointers (or objects) to nil without freeing memory (or releasing objects) is extremely bad form, as this just leaks memory and will increase the likelihood of bad things happening. You can set them to nil after you free/release the memory/objects.