How to implement didReceiveMemoryWarning?

Question

I developed an iPhone app with a convenient location that works perfectly with our expectations, except for the low state of the phone.

In conditions of low phone memory, my application simply crashes, and if I increase the phone's memory, freeing up space, it starts working again without failures.

when I made some mistake in working on the problem, I found that in low memory conditions the OS will send didReceiveMemoryWarning to all controllers of the current hierarchy, so that each of them should implement the didReceiveMemoryWarning method, and also set iboutlet to nil for which is not currently displayed.

I also read somewhere that if the view for this controller is not visible, the setView method with the nil parameter will be called, and if there are some output variables attached to the view, there will be a problem when deleting them.

So, with all these funds, what is best suited for working with the low memory level caused by Iphone by implementing the didReceiveMemoryWarning and viewDidUnload methods .

Please give the correct example or link, if possible, to solve the above problem.

thank.

Answer 1

One example that I am posting ... which I copied from somwhere ... this may give you some idea ...

- (void)didReceiveMemoryWarning { // Release anything that not essential, such as cached data (meaning // instance variables, and what else...?) // Obviously can't access local variables such as defined in method // loadView, so can't release them here We can set some instance variables // as nil, rather than call the release method on them, if we have defined // setters that retain nil and release their old values (such as through use // of @synthesize). This can be a better approach than using the release // method, because this prevents a variable from pointing to random remnant // data. Note in contrast, that setting a variable directly (using "=" and // not using the setter), would result in a memory leak. self.myStringB = nil; self.myStringD = nil; [myStringA release];// No setter defined - must release it this way [myStringC release];// No setter defined - must release it this way /* 3. MUST CONFIRM: NOT necessary to release outlets here - See override of setView instead. self.labelA = nil; self.imageViewA = nil; self.subViewA = nil; */ // Releases the view if it doesn't have a superview [super didReceiveMemoryWarning]; } 

Answer 2

Memory warnings are a signal to you that you should dispose of any resources that are not absolutely critical. Most of your controllers will be hanging on data caches, intermediate data, or other bits and fragments, often to save recalculation. When they receive memory warnings, they should start flushing everything that they don’t need immediately to work.

How you determine what is critical is entirely up to your application design. For example, an OpenGL game may determine that textures currently on the screen are valuable and hidden textures that are not visible, or level data that is outside the current playback area. An application with advanced session logs (for example, an IRC client) can remove them from memory and onto disk.

As you noticed, a warning is sent to each controller in your hierarchy, so each fragment must individually determine which data is “operation critical” and what “one-time” means. If you have optimized all of them and still do not understand the warning, unfortunately, it’s time to review your main application design because you have exceeded the hardware limits.

Answer 3

In iOS 5 and earlier.

When the controller receives a memory warning, doReceiveMemoryWarning will be called. At that time, if the controller view is not in the view hierarchy, the view will be set to nil, and viewDidUnload will be automatically called. So, the things we have to do in viewDidUnload release the subtask created in viewDidLoad or created from Nib. Like this:

 - (void)viewDidUnload { self.subView = nil; self.subViewFromNib = nil; } - (void)didReceiveMemoryWarning { self.someDataCanBeRecreatedEasily = nil; [super didReceiveMemoryWarning]; } 

On iOS6

The controller does not automatically turn off viewing when a memory warning is received. Therefore, viewDidUnload will never be called. But we still need to release our submission (including for viewing) when a warning about the memories occurs. Like this.

 - (void)didReceiveMemoryWarning { if ([self isViewLoaded] && [self.view window] == nil) { self.view = nil; self.subView = nil; self.subViewFromNib = nil; } self.someDataCanBeRecreatedEasily = nil; [super didReceiveMemoryWarning]; } 

Note that we do not call [self view] before we know that the view is loaded. because this method will automatically load the view if the view is not loaded.

Please note that we can free the view only when the view is not added to the window.

Answer 4

You decide what to do in didReceiveMemoryWarning . The OS tells you that memory is low, and you need to free as much as possible as soon as you can. The idea is that you should free up any cached data, unload views that are not visible, etc. Details are application specific.

Answer 5

You can also free up memory in didReceiveMemoryWarning , which you allocated for static variables in your classes. Because after allocating memory for static variables, it will not be freed during application startup.

Answer 6

To my surprise, only a few applications in the official iPhone samples implement didReciveMemoryWarning . You can use the iPhoneCoreDataRecipes example as a reference.

Some examples (like TableViewSuite) even do something else; -)