Any discussion of primitive synchronization and how it can be used when building solutions with the Compact Framework must begin with an understanding of ActiveSync.
As Microsoft made its foray into mobile devices, the company knew that Windows CE absolutely required the ability to exchange data with the PC. By connecting a cradle to a serial port and running special data-exchange software on both the PC and the device, Windows CE could intelligently retrieve data from the desktop to use in different applications on the device, thus giving the user a better experience with Microsoft's PDA. This software became known as ActiveSync.
ActiveSync is a lot of things today. If one is new to the PDA environment, it may appear that ActiveSync is just software that runs on the PC and intelligently transfers Outlook data, as in Figure 6-1; however, it is much more than this. ActiveSync creates a bridge between a desktop and a device that provides for a variety of services. Not only does it work across different connections (like USB, serial ports, infrared, and even via an Ethernet link across the network), it also works for Pocket PC, Handheld PCs, and the SmartPhone.
The most recent version of ActiveSync as of this writing is version 3.7 and is hosted on the desktop by WCESMgr.exe. For a better understanding, consider the services of ActiveSync outlined in the remainder of this section. These include backup and restore, software installation, interaction with the device, file conversion, remote communication, and connection notification.
ActiveSync provides the basic ability to backup and restore the data on the device. This feature allows a user to select where on the PC to store the file (with a .stg extension), whether to do a full or incremental backup, and if the backup should occur on every synchronization of the device. In case of a device catastrophe, one would restore the backup file to a new device, reset the device, and then be glad for backups. Both of these options are on the Tools menu of the ActiveSync desktop software, as shown in Figure 6-2.
This feature can be combined with power-on password protection as described in Chapter 9 to form a simple means of data security. In this way, in the event of a misplaced or stolen device, the data can be restored onto a new device, while the old device cannot be accessed without removing the batteries and, therefore, totally wiping out its contents.
ActiveSync also serves as a conduit for the device's application installation process. The most prevalent type of application installation for a device today is one that is initiated from the PC and is dependant on ActiveSync and its Application Manager. Through this mechanism, ActiveSync enhances the installation by prompting the user to provide the installation location on the device, which includes the choice of main memory or storage cards. The benefit to doing this is that the PC has a backup of the installation and that it can later serve in reinstallation or removal if necessary. Figure 6-3 shows how the location of the installation can be chosen by the user.
In Chapter 10, Packaging and Deployment, an example is given that shows how to create this type of installation using the Application Manager (CeAppMgr.exe).
ActiveSync also provides a nifty feature via the Windows Explorer on the desktop. After a synchronization, a user can browse or explore the device's storage system via the mobile device drive in Windows Explorer or the Explore button on the ActiveSync toolbar, just as if viewing the PC's hard drive as shown in Figure 6-4. This provides the ability to drag and drop different types of files to or from the device. Upon being dropped, a file can optionally be processed by a filter to perform the appropriate conversion for the destination (device or desktop).
As previously mentioned, ActiveSync can perform conversion operations on files as they are transferred between the desktop and the device. The code to do this is packaged as in-process COM objects installed on the desktop machine. Referred to as filters, these objects are intended to convert files as appropriate for the destination. In most cases, the files on the device are limited due to size constraints and reduced functionality in the application; therefore, the filters are important.
Because filters are COM objects and because the Compact Framework does not support COM Interop, as mentioned in Chapter 2, Compact Framework developers will not be able to create filters in Visual Studio .NET. As a result, developers must resort to eVC to do the COM programming. Fortunately, several important filters come with the current version of ActiveSync including those for Word, Excel, and bitmap files.
The underlying service that makes the ActiveSync services discussed in this section possible is RAPI. Its purpose is to allow the desktop to execute Win32 API calls against the device. This functionality is located in Rapi.dll, an unmanaged DLL that resides on the desktop and includes 78 functions. Most of RAPI's functions are duplicates of Windows CE API functions on the device and are prefaced with a "Ce." For example, there is a Win32 function called CreateProcess that allows an application to start up another process on the device; therefore, the RAPI version is called CeCreateProcess and provides the ability to create a process on the device from the PC.
The functionality in RAPI is quite broad and allows for a variety of desktop-application purposes. Later in the chapter, we'll look at a sample that shows how to access RAPI from managed code.
ActiveSync provides several ways to receive notification of connectivity, as well as other events. From the device side there are two techniques applications can employ. The first technique utilizes COM communications. The second is to register a program to be invoked when certain events occur. In this latter case, a developer could put an entry into the registry or call one of the Windows CE API functions (CeSetUserNotificationEx or the older CeAppRunAtEvent), about which more will be discussed later in the chapter.