The Tailspin mobile client must be able to download new surveys from the Tailspin Surveys service and to upload survey answers to the service. This section describes how Tailspin designed and implemented this functionality. It focuses on the details of the synchronization logic instead of on the technologies the application uses to store data locally and to interact with the cloud.
There are two separate synchronization tasks that the mobile client must perform:
- The mobile client must download from the cloud service any new surveys that match the user’s subscription criteria.
- The mobile client must send completed survey answers to the cloud service for analysis.
These two tasks are independent of each other; therefore, the mobile client can perform these operations in parallel. Furthermore, for the Tailspin application, the synchronization logic is very simple. At the time of this writing, the Tailspin cloud application does not allow subscribers to modify or delete their survey definitions, so the mobile client only needs to look for new survey definitions. On the client, a surveyor cannot modify survey answers after the survey is
complete, so the mobile client can send all of its completed survey answers to the cloud service and then remove them from the mobile client’s local store.
In the Tailspin mobile client application, the user manually initiates the synchronization process by tapping a button. Tailspin considered automating the synchronization process, but the developers at Tailspin decided not to adopt this approach in the first version of the application because it could result in increased resource usage, especially
of the battery. A more sophisticated approach for the application would be to automate the synchronization process, but first check the battery level and available network connectivity. Tailspin plans to add this feature in a later version of the application.
Because synchronization can be a time-consuming process, the mobile client should run it asynchronously and notify the user of the outcome when the synchronization completes.
Note: How often you should run a synchronization process in your application involves some trade-offs. More frequent synchronizations mean that the data on both the client and in the service is more up to date. It can also help to free up valuable storage space on the client if the client no longer needs a local copy of the data after it has been transferred to the service. Data stored in the service is also less vulnerable to loss or unauthorized access. However, synchronization is often a resource-intensive process itself, consuming battery power and CPU cycles on the mobile client and using potentially expensive bandwidth to transfer the data. You should design your synchronization logic to transfer as little data as possible.
Overview of the Solution
Tailspin considered using the Microsoft Sync Framework, but they decided to implement the synchronization logic themselves. (For more information about the Microsoft Sync Framework, see Appendix E, “Microsoft Sync Framework and Windows Phone 7.”) The reason for this decision was that when Tailspin started developing the mobile client application, the necessary providers were only available as pre-release versions. In addition, the fact that the synchronization requirements for the application are relatively simple reduces the risks associated with developing this functionality themselves. The developers at Tailspin have designed the synchronization service so that they can easily replace the synchronization functionality with an alternative implementation in the future.
Tailspin decided to use the Rx to run the two synchronization tasks asynchronously and in parallel on the phone. Figure 4 summarizes the synchronization process and the tasks that it performs.
The user starts the synchronization process by tapping a button in the UI. A progress bar in the UI is bound to the IsSynchronizing property in the view model to provide a visual cue that the synchronization process is in flight. Rx runs the two tasks in parallel, and after both tasks complete, it updates the view model with the new survey data.
In Figure 4, Task A is responsible for downloading a list of new surveys for the user and saving them locally in isolated storage. The service creates the list of new surveys to download based on information sent by the mobile client application. The client sends the date of the last synchronization so that the service can find surveys created since that date, and the service uses the user name sent by the client to filter for surveys that the user is interested in.
Task B sends all completed survey answer data to the cloud service, and then it deletes the local copy to free up storage space on the phone.
When both tasks are complete, the application updates the data in the view model, the UI updates based on the bindings between the view and the view model, and the application displays a toast notification if the synchronization was successful or an error pop-up window otherwise.