1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-00363030-AAE2-5231-8407-AC609DA0F496" xml:lang="en"><title>Backup

    13 and Restore on Scheduled Tasks in Persistent Schedules</title><prolog><metadata><keywords/></metadata></prolog><conbody>

    14 <p>When scheduling tasks in persistent schedules, special consideration must

    15 be given to the effects of backup and restore operations. Persistent schedules

    16 and tasks associated with them are backed up during a backup operation. This

    17 results in the storage of their status at the time of backup. When the data

    18 is restored on the same phone or another phone, the persistent scheduled tasks

    19 are recreated. This results in the overwrite of any existing persistent schedule

    20 and task on the phone. </p>

    21 <p> <b>Note:</b> Transient schedule and tasks are affected by the backup or

    22 restore process. </p>

    23 <section><title>Impact of backup and restore on persistent schedules and tasks</title> <p>State

    24 information associated with a phone, such as date, time and conditions are

    25 not backed up with schedules and tasks, during a phone backup. The date or

    26 time of a phone at the time of a backup is always likely to be different from

    27 the date or time of the target phone during restore. The conditions that are

    28 based on <xref href="GUID-C4776034-D190-3FC4-AF45-C7F195093AC3.dita"><apiname>RProperty</apiname></xref> values that indicate the various states

    29 of a phone might also be different between the time of backup and the time

    30 of restore. One example is the network status, which may be unavailable at

    31 the time of backup, but available at the time of restore. </p> <p><b>Possible

    32 problems</b> </p> <p>When a task is scheduled in a persistent schedule, its

    33 execution depends on a specific time or condition to become due. If the phone

    34 is backed up before the schedule is due, the schedule information is also

    35 part of the backup. Later, when the time or condition is satisfied, the task

    36 is executed on the phone. But, when a phone restore is done after the task

    37 is executed on the phone, the schedule may be due again and the task may get

    38 executed, if the same time or condition is satisfied again. </p> <p>For example,

    39 assume that a condition-based task is created to send an SMS when the network

    40 is available. In addition, assume that when this task is created the network

    41 is unavailable and a phone backup is taken. After the backup, the phone network

    42 may become available and the SMS may be sent. In this scenario, when a phone

    43 restore is done the SMS may be sent again when the network is available, which

    44 can result in additional SMS costs. </p> <p><b>Recommended alternatives</b> </p> <p>The

    45 non-repeatable nature of the tasks cannot be determined by the task scheduler

    46 automatically, and there is no mechanism for setting per-schedule backup options.

    47 For this reason, clients that create non-repeatable tasks must be aware of

    48 backup and restore implications and consider this fact in their designs. </p> <p>Clients

    49 can use transient schedules for non-repeatable tasks, which eliminates this

    50 problem because transient schedules are not backed up or restored. If the

    51 use of a persistent schedule is necessary, clients can choose to become backup-aware

    52 by registering for notifications through <xref href="GUID-DC57CA2E-0EDF-3AF2-BC65-50D71665333B.dita"><apiname>CBaBackupSessionWrapper</apiname></xref> or

    53 using the <xref href="GUID-0FE60A65-6CB6-50AB-B85F-2B60FE96ECFE.dita">Secure Backup

    54 Engine</xref> APIs, and taking appropriate actions. These actions might be

    55 to delete the non-repeatable task before backup or after restore, or rescheduling

    56 it after restore to a different time for time-based schedules. </p> <p> <b>Note:</b> Any

    57 schedule that expires or becomes ready to execute when a backup or restore

    58 is in progress is delayed, and is only executed when the backup or restore

    59 process is completed. </p> </section>

    60 </conbody><related-links>

    61 <link href="GUID-3CDCE4E0-E29D-5782-8053-B386A9E34BCC.dita"><linktext>Task Scheduler

    62 Overview</linktext></link>

    63 <link href="GUID-74C1C345-823C-5CD5-8FC5-214A55734E94.dita"><linktext>Developing

    64 Programs with Task Scheduling Capabilities</linktext></link>

    65 </related-links></concept>