From the early chapters of the book, we have discussed mobile development from the perspective of data handling by exploring essential architectural concepts. In this journey, we have covered local data handling, remote data access, and caching data. If you combine the functionality of these three concepts into an application, you will be able to design software that pushes and pulls large amounts of data, regardless of whether it is already located on the device. In environments where the application functions over limited bandwidth connections, however, these techniques may be frustrating to the user due to the waiting involved. Therefore, the amount of data transmitted from constrained devices should be limited, and this brings us to the concept of synchronization and this chapter. Therefore, synchronization is the last essential architectural concept in our series of architectural points.
Synchronization is distinct from the transferring and caching of data, which was thoroughly discussed in the previous chapters. Synchronization is important because it checks for the differences between two data containers in order to avoid the unneeded transfer of data that already resides in both data sources. Therefore, synchronization schemes typically update both data sources by transferring only additions, changes, and deletions.
Consider the scenario where a company has a database of customers. Inside the office, the customer service department executes a Windows application that allows agents to update the customer information located in the database. Also, salespeople have a Pocket PC application that allows them to download the customer database and edit customer records while out of the office.
The challenge in this application will be the synchronization of data from these traveling devices. If a developer were to develop this functionality, code would have to be written on the device and on the server. The effort to get this correct is tougher than you might initially think due to error handling and conflict resolution. Remember, the application cannot afford to lose data due to a loss of connectivity during transfer. In addition, a protocol has to be developed to query for the differences in data. Additions and deletions are easy to manage, but changes to existing data provide an opportunity for the developer.
The primary issue that synchronization needs to address occurs when a record is changed on both computers. For example, a customer table has an entry for Customer 100. The Pocket PC application downloads the customer database to the device that is taken out of the office by a salesman. During the day, the salesman discovers that Customer 100's phone number has changed and updates the customer record in his Pocket PC application. Later that day, someone in the customer service department notices the same discrepancy and makes a change to the database in the office. Which is the change that should remain? This is a simple case. But what would happen if these entries are different? Which is the right one? Should the application just accept the most recent one? What if the changes were made to the same customer but to different fields? The challenge here is how to manage conflicts.
There are several ways to achieve synchronization. It is certainly possible to create your own algorithm, which may consume significant effort based on the above scenario. Another alternative is to look at solutions built by others. Microsoft has built two mechanisms, ActiveSync and SQL Server 2000 Windows CE Edition. In this chapter, we will look at ActiveSync, and in the next chapter, we will look at the options provided SQL Server CE.
In exploring ActiveSync, we will not only look at how it does synchronization, but we will also look at the other services that it provides.