Handling Low Memory States
Because mobile devices are designed for quick access, developers of the shell for Windows Mobile-based Pocket PCs 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 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 User Interface Guidelines.
The following table shows the shell response to low memory at different thresholds.
| Threshold | Value | Description |
|---|---|---|
| Hibernation | 224 KB | The shell sends a Windows CE WM_HIBERNATE message to the application that has been inactive the longest and continues to send WM_HIBERNATE messages until free memory climbs above the hibernation threshold or falls below the low-memory threshold. For more information, see Handling Application Hibernation. |
| Low-memory | 2 MB | The shell sends a WM_CLOSE message to the application that has been inactive the longest and continues to send WM_CLOSE messages until free memory climbs above the low-memory threshold or until only the foreground application remains open. |
| Critical-memory | 24 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 the device and the emulator.
Remarks
Windows Mobile–based 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-based devices.
See Also
Handling Application Hibernation | How to: Determine Available Memory | How to: Determine Battery Status | Preventing Automatic Power Down | How to: Program Applications to Turn the Smartphone Backlight Off and On | How to: Suspend the Device | Managing Variables, Stacks, and Heaps on Mobile Devices | Memory and Power Management | Getting Memory Status and Processor Information | System Out of Memory Dialog Box
Send Feedback on this topic to the authors