This chapter gives an overview of the application life-cycle on the maemo platform, introduces services used in the application state-management and resource-saving.
Components involved in the application life cycle management and switching are following:
The first phase of the platform startup is the bootloader, which will load the Linux kernel into memory. Linux kernel then loads the initial filesystem (InitFS) from its' own filesystem partition. InitFS, used as a root file system during the startup, contains necessary binaries and scripts to initialize the system and to access the actual root file system, which will be mounted after the InitFS scripts finish. Root file system contains several init-scripts, which will handle the startup of necessary daemons, services and the application framework itself, everything that makes the maemo platform. See chapter "maemo Platform Overview" for more information.
Platform state is managed through several system software components:
One of the important (and interesting from developers point of view) components is D-Bus. The D-Bus message bus is a central part of the platform architecture. Applications should listen to D-Bus messages indicating the state of the device, such as "battery low" and "shutdown". When receiving these messages, the application may, for instance, ask the user to save any files that are open, or perform other similar actions to save the state of the application. There is also a specific system message, emitted when applications are required to close themselves.
In maemo platform, user starts the applications primarily from the Task Navigator. There are also few other ways to start the application, either from the Status Bar (e.g. connection manager), from File Manager to view a file, or from other applications (e.g. "Send as E-mail").
User normally start applications from the Task Navigator. Task Navigator starts the application by sending a D-Bus message to the application service with the D-Bus auto-activation flag set.
Other applications can also start applications implicitly by sending a D-Bus message, for example to open a file of certain MIME-type that the application has registered to the MIME databse.
Every application in the Internet Tablet has a well-known name uniquely identifying the application, e.g. "Browser" or "Email". D-Bus has a service name for each application, derived from the application name.
Where applications get the D-Bus service name:
.desktop file D-Bus daemon looks into application .service file to see how to execute the application before delivering the message. Applications launched by the D-Bus daemon will only have one instance of them running, because D-Bus does not allow the same service name to be registered by more than one process.
The application launched by the D-Bus daemon will inherit environment variables that were defined at the time when the D-Bus session bus was started. D-Bus does not provide a way to change the environment variables passed to an application. As the Task Navigator uses D-Bus to launch the application, it's same as directly launching the application using D-Bus.
Environment variable should not be used for dynamic configuration changes, since they require program restart and D-Bus does not support that. The language change is also communicated through environment variables. As applications and their libraries also cache locale state, changing the language in Internet Tablet requires restarting all applications and processes.
When the application is started, the window manager takes care of drawing the titlebars, dialog borders and windows. Application windows are in a stack. When you top an application, it comes on top of the stack. The window manager also keeps the application dialogs stacked together with the application in the window stack, thus when the application is topped, it's dialogs are topped too.
The application can top itself, or the Task Navigator can top the application by sending a standard X message.
To conserve memory and resources, only single instance of an application can be running at the same time. If application is already running, it will only receive a message about the new invocation (for example "open file") and top itself (bring the window to foreground). User can switch to another, already running application either by using the Task Navigator UI, or by closing the topmost application.
Application framework has a mechanism for shutting down GUI applications on the background to save memory so that other application can be run. This is called background killing.
Background killing is implemented by Task Navigator to transparently close an application when the user does not see it and to restart the application when user needs it again. This is possible because applications are required to be able to save their user interface (UI) states and Task Navigator has a list of all running UI applications. The application is required to save its UI state when it moves to background.
If in some cases Internet Tablets don't have enough memory to run all the applications at the same time, the system may kill an application running in the background that has indicated to be killable.
Saving the UI state may not always be feasible for the application (e.g. during a download in progress), that is why the application must notify the Task Navigator when it has saved the state and can be killed. Task Navigator will kill all the killable applications when system notifies that it is low of memory. When the application is started again, it is required to rebuild the UI according to the saved state. Task Navigator won't restart the application if there is not enough memory in the system for that.
The application UI state saving is assisted by LibOSSO. The LibOSSO library creates the state file and provides the file descriptor to the application. Libosso will make sure that the real state file will not be updated until the state file write has completed and file closed. The application uses the standard POSIX file system API for writing and reading to the file descriptor.
If device is restarted, the UI states will be discarded, so applications start from their default state. Each application with different version number will have it's own UI state file, meaning that if the application is updated (version number changes), it will start from the default state.
Some applications are required to save the unsaved user data periodically when on the foreground (top), so that as little as possible is lost on battery failure. Applications should register a LibOSSO callback function for this operation and tell when their user data has changed (the application is in "dirty state"). LibOSSO will then tell the application when they should do the saving.
Note that applications should call "forced autosave" LibOSSO function when they go to background (LibOSSO does not know when this happens).
Applications exit when user closes them from the application UI, or when system requests that. System will request (and force) the applications to exit when:
If the Internet Tablet runs low on memory, the system can request application to be background killed. If there is not enough free memory to satisfy the applications' request for more memory, the application will be killed by the kernel.
Copyright © 2007-2008 Nokia Corporation. All rights reserved.