Handling Low Memory States
4/19/2010
Because mobile devices are designed for quick access, developers of the shell for Windows Mobile PDAs simplified the memory interface for users. When an application needs more memory, instead of prompting the user as a desktop computer would, the shell simply shuts down inactive applications without forcing interaction by the user.
The shell optimizes memory use for running applications. When the demand for memory is high, idle applications receive a WM_CLOSE message to make room for the active application. Because this automatic shutdown comes without warning, you must handle state persistence within your application if you need to preserve its state from one session to another. Typically, you archive any persistent-state variables to a temporary file after your application receives a WM_CLOSE message, but before the message is passed to the operating system. When the application starts, it should immediately check for this temporary file. If the file exists, the application should restore the application state.
Note
To simplify memory management for your users, do not provide a Close button on your application's toolbar. Similarly, do not enable Exit on the File menu. For more information, see the Design Guidelines.
The following table shows the shell response to low memory at different thresholds.
| Threshold | Default Value | Description |
|---|---|---|
Hibernation |
2 MB |
The shell sends a Windows Embedded CE WM_HIBERNATE message to the application that has been inactive the longest, and continues to send WM_HIBERNATE messages to the applications. Once all of the applications have been sent a WM_HIBERNATE message, the shell begins sending WM_CLOSE messages to the applications. This continues until free memory either climbs above the Hibernation threshold, or falls below the Critical Memory threshold. For more information, see Handling Application Hibernation. |
Critical–Memory |
1 MB |
The shell sends a WM_CLOSE message to the application that has been inactive the longest, and continues sending WM_CLOSE messages until free memory either climbs above the Critical–Memory threshold, or until only the foreground application remains open. |
No Execute |
500 KB |
No new applications can be opened. For more information about handling memory failure, see System Out of Memory Dialog Box. |
Note
The preceding threshold values are for actual devices, and may vary slightly between physical and emulated devices.
Remarks
Windows Mobile devices should not run multiple instances of an application because doing so requires a large amount of memory, and there is no way for a user to access multiple instances. Instead, an application should be restarted.
An application can have multiple documents open, but you must provide a way for the user to manage and switch between the multiple documents, because this capability is not provided on Windows Mobile devices.
See Also
Concepts
Handling Application Hibernation
How to: Determine Available Memory
How to: Determine Battery Status
Preventing Automatic Power Down
How to: Program an Application for Windows Mobile Standard to Turn the Backlight On or Off
How to: Suspend the Device
Managing Variables, Stacks, and Heaps on Windows Mobile Devices
Getting Memory Status and Processor Information
System Out of Memory Dialog Box