Defining ActiveSync Objects
A version of this page is also available for
4/8/2010
ActiveSync service providers are almost always written to synchronize objects, rather than whole files, because it is virtually impossible to rationally synchronize two versions of the same file when both have changed.
Consider a file containing contact information. During synchronization, if the version on the Windows Mobile device has a new time stamp, but the version on the desktop does not, you can reasonably assume the Windows Mobile device version is the one that changed.
But if both files have new time stamps, how do you decide what the differences between the files mean? If one file has an entry missing from the other, is it because the entry was added to the first file — or deleted from the second?
It is to remove this ambiguity that the objects themselves, rather than the files or databases containing them, are synchronized.
An object is any data item. You have complete freedom in defining what an object comprises. With respect to contact information, for example, you could define the set of data for a business or personal contact as an object. Or you could define the individual elements of the contact information — date, name, location — as objects.
Both approaches have strengths and weaknesses. The "holistic" approach — defining the data set as an object, rather than each element — works best for most developers. Although synchronization takes slightly longer, the code required is simpler, because only a single "object" — rather than multiple objects that contain the same content as the single object — has to be enumerated. The ambiguity that occurs when one piece of information changes on the desktop, while another piece of information changes on the Windows Mobile device, is unlikely when only a single user has access to the desktop and Windows Mobile device, which is the usual situation.
An object type is a name for a particular group of objects contained in a folder. For example, Contacts is an object type naming all contacts in a Microsoft Outlook folder.
Before writing a service provider, you need to make the following decisions about objects and object types.
- Which data do you want to synchronize?
- What names will you give the objects and object types?
These names are user-defined and can be anything you want. The object-type name is used in both the registry and the code you write. The display or "user-friendly" name for the object type can also be stored in the registry for use in the ActiveSync Status window. - Where are the data objects stored?
The store is a database that holds the data, or objects, to be synchronized. The store is usually the Windows Mobile data store, but it can be a flat file, a relational database, or have a custom format of your own design. - How will an object identifier (OID) be assigned to each object?
The OID is a 32-bit value. It can be an integer, a text string, or byte sequence, but it must satisfy four criteria.- It must be unique among all objects of the same type.
- It cannot change once it is assigned.
- It cannot be reused for any other object of the same type if the original object is deleted.
- It must be ordered, so you can determine which of the two objects was created first.
Globally unique identifiers (GUIDs) satisfy these criteria. Other types of identifiers are possible.
- How will the object indicate that a change has occurred since the last synchronization?
A change is usually shown by a time stamp or version number.
An OID cannot be used as a change signifier. Once assigned, it never changes. - How will your application interact with the object?
The application must be able to enumerate (locate) all current objects of a given type, including those scheduled for deletion. It must be able to serialize an object (convert it into a byte stream) for transmission between the desktop computer and the Windows Mobile device, and convert the byte stream back into an object. It must supply a user interface if the user is expected to enter data values or select synchronization options.