Understanding the application life cycle
The life cycle of an application refers to the stages that an application can move through, from the time it is invoked until it is terminated. It is important to understand the implications of the various states and transitions of the life cycle on your application so that you can respond to them appropriately in your code.
In its simplest form, the life cycle of your application has three stages: it starts, runs for a period of time, and then ends. While the application is running in the foreground, it is active. While your application is running and active, it can be interrupted at any time, when another application opens and replaces yours as the active application. The BlackBerry Tablet OS is a multithreaded, multitasking platform. When your application loses focus it is not terminated, but is instead deactivated and pushed to the background; the application is still running, but it is no longer the top application on the stack. A background application can be reactivated—that is, returned to the foreground—at any time, or may be closed by the user, or occasionally terminated by the system, without ever becoming active again.
During the application life cycle, other events might cause your application to terminate prematurely (that is, before the user has closed it). For example, when the battery drains, the tablet turns off and closes all open applications. In addition, there are memory considerations that your application should account for. If, for example, a user has too many applications open, it could create a low memory situation. The BlackBerry Tablet OS manages low memory conditions by closing idle background applications so it can reclaim the necessary memory resources.
Saving the application state
Saving the application state makes sure that when the user returns to the application, the application returns to the same condition it was in when it lost focus. A mobile application can experience a number of interruptions during its life cycle—losing application focus, change in application window state, low memory events, and low battery events—that must be managed. It is important that your application listens for these events and respond by saving the application state; any pertinent information about the current conditions of the application—for example, the screen element currently in focus, or any user-entered data—can be saved. When the user returns to the application, the saved state can be reloaded and the user can then continue on as before.
The type of information you should save about the application state depends upon the application, and upon the likely expectations of your user. For example, for an eReader application, the user might simply expect to return to the same page of the same book they were reading. In a text editor application or on a settings page, the user might expect that any text entered would still be available, even if those changes were not saved manually. In an interactive game, such as a driving game, you might save much more data about the state of the application. In each case, to decide what data to save and when to save it, you must first decide what data is necessary for the user to continue when the application is reloaded.
It is also wise to save the application state after other significant events; for example, in a game application, you might save the state each time the user completes a level.