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.