5 Storage and persistence

Applications need to store data on the disk in order to be persistent, that is, to be able to remember user settings and data between runs. There is plenty to think about concerning storage and persistence.

The application should always try to ensure that there is enough disk space before allowing the user to input new data or to change any data.

An out-of-disk condition could potentially arise during the creation of a new entry before it is saved to persistent storage. In this situation, it is acceptable to lose the new entry. However, no data should be corrupted, no garbage data or orphan files should be left on the device and the user should be informed.

No entries should ever be lost or corrupted due to out of disk conditions.

Application startup should not be affected directly by an OOD situation, that is, it should still be possible to start the application. This means that an application cannot write to the disk when it is starting up.

When OOD occurs it should be possible to start the application, even if it has not been started before.

Viewing already available entries in an application should still be possible in an OOD situation. This means that an application cannot write to the disk when opening an entry.

When OOD occurs it should be possible to view entries in the application.

When OOD occurs it should not be possible to create new entries and the user should be informed.

There are preferred locations for storing data. Follow directions for storing data to ensure correct cooperation with the Storage Manager.

With the introduction of Platform Security in Symbian OS, the concept of Data caging was also introduced. Data caging, or partitioning, involves separating code from data in the file system so that a simple, trusted path is created on the platform.

A UIQ application should follow the partitioning rules set out by the Data caging concept.

Applications have their own restricted view of the file system consisting of the directory sub-tree /private/<SID>/, where SID is a unique security identifier taken from the application’s UID. The application's private data files should be stored in the private sub-tree and will only be accessible by the specific owning process and for TCB-processes.

An application’s private data files should be stored in the private tree /private/<SID>/.

The /resource directory is public but read-only for non-TCB processes. The purpose of this is to allow read-only files to be publicly shared without compromising their integrity. An application should put its resource files and icon files in /resource/apps/.

Resources that need to be shared are stored in the resource path (/resource/).

The /sys directory is the restricted system area inaccessible to non-TCB programs. It contains a sub-directory, /sys/bin, that holds all executables (.exe, .dll, ECom plugins). The OS will refuse to load any program not in /sys/bin.

All binary files must be stored in the binary path (sys/bin/).

Multimedia files, for example, image and audio files should be handled using the UIQ Multimedia File Handling (MMFH) framework.

Media files should be handled through the Multimedia File Handling Framework.

When the phone runs low on disk storage, the Storage Manager notifies all applications by calling the CEikDocument::SaveL(MSaveObserver::TSaveType aSaveType) method with the aSaveType set to EReleaseDisk. Notification can occur at any time and the application should be able to handle this.

At notification the application should:

• Remove temp files,

• Stop filling the disk, for example, abort the downloading of files,

• Not compress data as the compressing procedure temporarily requires more space.

When the application receives the EReleaseDisk notification it should clean up its files and abort any disk operations.

Applications using external and removable storage should always check that the storage media is available before trying to use it. Before writing or deleting from external storage, the application should check that write access is allowed.

For example, external storage could be available when the user selects a file, but could be unavailable when the user tries to perform an action on the file. The user should be informed that the operation failed due to the fact that external storage was removed.

The application should be able to handle external storage being removed at any time during an operation.

The application should check if external storage is write protected before trying to write to or delete from the disk.

Copy, delete and move operations not yet in progress should be cancelled when switching away from an application, since this is the safe thing to do. The data is already on the disk and aborting the operation makes sure no data is accidentally lost.

If an action is already in progress and switched away from, it should continue to run in the background, with minimum performance loss.

If the user aborts a storage operation in progress, no data should be lost or corrupted. For example, if a user copies a file and aborts the operation, the original file should be intact and the copy should be removed. No data is lost and no data is corrupted.