Generating alert to User when didReceiveMemoryWarning is called

I've seen some apps that generate a warning when low memory is detected. I tried to do this in my app but ran into a problem. Using the simulator to simulate a memory warning, the alert generated pops up twice before I can hit "ok" and pops up 9 more times after that times before it finally goes away.

Is it a bad idea to generate an alert when didReceiveMemoryWarning is called?

If not, is there a better way to do this than what I have below?

- (void)didReceiveMemoryWarning {

     [super didReceiveMemoryWarning];

     // Release any cached data, images, etc that aren't in use.
     ...

     UIAlertView *alert = [[UIAlertView alloc]
                          initWithTitle:@"Warning" 
                          message:@"Your device is low on memory..." 
                          delegate:nil 
                          cancelButtonTitle:@"OK" 
                          otherButtonTitles:nil];
    [alert show];
    [alert release];    
}

Thanks,

phil

Generally speaking, you shouldn't notify a user about low memory. After all, what can they do? Your app is the foreground app, which (aside from the Apple apps) is consuming most of the device's memory. What is the user going to do when they see the memory message?

When you get a low memory notification, you should solely focus on freeing memory, without user interaction.

Getting memory warning is a serious issue, which cannot be neglect by any developer developing mobile application. You should always free up the variables that take most of the memory in didReceiveMemoryWarning method of your class.

There is no use of showing alert to user that this app is consuming a lot of memory because its none of their business and what can they do. Instead you should focus on how to reduce memory consumption without user Interaction .Following are the ways to reduce memory consumption in your App

1. Allocate UI Elements when they are visible . Don’t hide them , instead remove them from superView and allocate them again when in use.
2. Empty all cache when Low memory pressure occurs.
3. Limit the scope of your Variable when ever possible . All @property of type (Strong , retain , copy) will be remain active until your Controller deallocated.
4. Find places of potential leak using static Analyzer.
5. Find and remove leaks using Leak tools in Instrument available . See Finding Leaks in your App in the Instruments User Guide.
6. Use the Allocation instrument to check which part of your application consuming a lot of memory.
7. If you are using Core Foundation classes ? Make sure you are releasing every allocation manually using CFRelease.
8. Make sure you are not creating too many autorelease objects in one go . If you are creating then reduce the scope by creating your own AutoreleasePool by using @autoreleasepool declarative

As I understand it, you'll likely get this just before your app crashes (or is killed). If you manage to free up memory, the app may survive (but isn't guaranteed to).

There might be a few legitimate use cases. Since it's usually a prelude to a crash, you might want to warn the user of this. This could take the form of a message like: "Your device is low on memory. As a result, this application may unexpectedly exit. If the problem persists, try powering the phone off and on again". Assuming all is well, this shouldn't appear - so you may want some warning if it does.

This might be more common on jailbroken phones, where the popular 'backgrounder' app allows applications to be run in the background (often until this very condition occurs - at which point they're forcibly exited - see the comment here for example).

To work around the problem of the event being triggered 11 times consecutively.. You could rate limit the popup. For example: when you display, store the seconds since the epoch. Then - check that a certain amount of time has passed before displaying it again.