7 Data handling

In order to exchange, store and process information, applications need to handle data in different ways. Data can be input from users, stored in a file, received from a server, entered by a sync operation, sent to the device, etc.

Data can be corrupted in many ways and for many reasons. This, however, should not stop an application from working.

The application should:

• Not panic,

• Restore as much data as possible,

• Remove corrupted data,

• Inform the user.

If the application allows viewing of partially corrupted databases or entries, it should be possible for the user to delete the corrupted data.

Corrupted data should not stop an application from working.

Valid data entered in an application should be saved when switching away. Invalid data should be corrected; if necessary, it should be replaced with default values. The user should be informed about the correction.

There is no point in saving entries where all the data entered is invalid. At least some data should be valid for an entry to be saved.

When switching away from the application any valid data entered should be saved.

Synchronization should not corrupt existing data or lead to duplicated data or entries.

Applications using databases should be able to handle unexpected database entries that might have been added by other applications.

Other applications, such as sync applications, may add entries with fields, options or combinations of fields and options that cannot be created by the application itself. The application should display these entries as best as possible and keep the data entered by the other application intact.

Applications using databases accessible by other applications should be able to handle all types of entries that can be entered in the database.

If the application needs to access a database that currently is locked, the application should not panic and the user should be informed.

If the application uses another application’s database, it should be released as soon as possible.

Application databases should only be locked when necessary, that is, only when writing to the database.

If an operation can be aborted, sufficient data should be saved to be able to resume work at the point of abortion. The abortion of an operation should not result in data corruption.

For example, if a sync or email download is aborted or cancelled, it should be possible to resume the sync or download at a later stage without creating duplicate entries.

If an operation can be aborted, sufficient data should be saved to be able to resume it later and data should not be corrupted.