When scheduling tasks in persistent schedules, special consideration must be given to the effects of backup and restore operations. Persistent schedules and tasks associated with them are backed up during a backup operation. This results in the storage of their status at the time of backup. When the data is restored on the same phone or another phone, the persistent scheduled tasks are recreated. This results in the overwrite of any existing persistent schedule and task on the phone.
Note: Transient schedule and tasks are affected by the backup or restore process.
State information associated with a phone, such as date, time and
conditions are not backed up with schedules and tasks, during a phone
backup. The date or time of a phone at the time of a backup is always
likely to be different from the date or time of the target phone during
restore. The conditions that are based on RProperty values that indicate the various states of a phone might also be
different between the time of backup and the time of restore. One
example is the network status, which may be unavailable at the time
of backup, but available at the time of restore.
Possible problems
When a task is scheduled in a persistent schedule, its execution depends on a specific time or condition to become due. If the phone is backed up before the schedule is due, the schedule information is also part of the backup. Later, when the time or condition is satisfied, the task is executed on the phone. But, when a phone restore is done after the task is executed on the phone, the schedule may be due again and the task may get executed, if the same time or condition is satisfied again.
For example, assume that a condition-based task is created to send an SMS when the network is available. In addition, assume that when this task is created the network is unavailable and a phone backup is taken. After the backup, the phone network may become available and the SMS may be sent. In this scenario, when a phone restore is done the SMS may be sent again when the network is available, which can result in additional SMS costs.
Recommended alternatives
The non-repeatable nature of the tasks cannot be determined by the task scheduler automatically, and there is no mechanism for setting per-schedule backup options. For this reason, clients that create non-repeatable tasks must be aware of backup and restore implications and consider this fact in their designs.
Clients can use transient
schedules for non-repeatable tasks, which eliminates this problem
because transient schedules are not backed up or restored. If the
use of a persistent schedule is necessary, clients can choose to become
backup-aware by registering for notifications through CBaBackupSessionWrapper
Note: Any schedule that expires or becomes ready to execute when a backup or restore is in progress is delayed, and is only executed when the backup or restore process is completed.