1 General application behavior

This section describes the general behavior in different states (start-up, foreground, background, closing) during an application’s lifetime.

There should always be only one instance of an application running at any time. When an application is launched, the UIQ application framework will make sure that a new application instance is not created if one is already running. This behavior can, but should not, be overridden by the application.

It should not be possible to start more than one instance of the same application.

Once an application is started it should not be closed again. Instead, it is placed in the background when not used. The user, another application or a notification could force an application into the background. The user should be able to resume work in the application as soon as it is brought to the foreground again.

Applications can be forced to close down by the framework, but the user should not have the choice to do so.

The application should not present an “Exit application option” to the user.

If a low memory situation occurs, the Memory Manager framework will ask the application to close down. The default behavior is that the framework calls the CEikDocument::SaveL() method where the application should save any unsaved data. Then EEikCmdExit is sent to the application and should be handled in CEikAppUi::HandleCommandL() in the usual way.

See even the section on Memory Manager Interaction about exceptions to this default behavior.

If an application is forced to close down, any unsaved changes should be saved first.

An application should always make use of the multitasking environment which is available. For example, use ActiveObjects to implement long running tasks. Otherwise, use separate threads, if that is more appropriate.

The application should not depend on other device or system tasks to complete before continuing general application processing. For example, it should be possible to save an SMS while receiving a new one or to scroll in lists while the device is adding or deleting entries.

It should always be possible to select commands, use the application and switch away from the application even if the application or device is busy with some other task.

The framework controls the behavior of view switching; an application can, but should not, override it.

A view switch can be:

• Directly to the application launcher,

• Caused by a notification, for example, a viewer takes you to another application or another view (or entry) in the current application,

• Caused by a Direct Navigation Link (DNL).

When returning to an application after switching to another, the view tab and the highlight position are shown in the same way as they were before switching away.

When switching away from a view, only changed or new non-empty entries should be saved. If an entry is only opened and viewed, the entry should not be saved again when closed. Saving unchanged entries could, for example, affect synchronization and unnecessarily drain battery power.

All changes in an application view should be saved, without user confirmation, as soon as a view switch occurs.

When a view is cancelled, the default behavior of the framework is to make sure that any changed data is not saved. This behavior can, but should not, be overridden by the application.

Changed data should not be saved when the user cancels a view.

When editing an entry results in removing all of the information it contains, the entry itself should also be removed when saved. This avoids any stray unusable entries.

If all information is removed from an entry the entire entry should be removed when closed.