Next up, the Poorhouse wanted to try some 2-way sync action with the Palm task (aka todo) list.

Being slightly familiar with MS Access, it was decided we'd sync the Palm tasks to an Access equivalent. Hopefully this would provide a good framework to sync them to anything else, as just the code involving the Access API would need to be replaced.

First we needed some synchronisation logic. Some methodology is required so that the sync works; tasks added in either database are added to the other, same with deletion and editing. Moreover, the correct action needs to be done - if two records don't match, which one do we go with?

Fortunately, the Palm documentation explains the logic behind how the normal conduits work. They refer to it as a "mirror sync", as opposed to say a one-directional sync which for instance could copy data from the Palm onto your computer, but not the other way around.

Two important things to know about the Palm databases containing tasks etc. are there are a few "hidden" fields. These include a "deleted" and a "dirty" boolean field. Deleted is only true when the user has requested a record is deleted. The record physically stays on the device until a sync occurs so the record can be tied up with the remote database. "Dirty" means that something about the record has changed. Perhaps it's a new record since the last sync, perhaps the user changed some aspect of it and so on. This allows the device to quickly determine what bits of synchronisation are needed.

Not having the time or inclination to spend a lifetime going through the CDK, the Poorhouse cheated and had a brief flick through a rather useful tutorial - the VB Conduit Starter Kit. The main attraction of this was chapter 4, where code for a conduit to sync contact address book information is given. Given the overall logic for syncing contacts is identical to that for tasks it provided a quick structure for developing such a conduit. Indeed almost all that was needed was to replace references to the contact-related CDK objects with the tasks equivalent, and working out which data items of the tasks objects were relevant to the sync. I took the same tack as the Starter Kit and decided to ignore the Palm "archive" facility for now.

Each Palm todo task record is represented by a PDTodoDbHHRecord. It has the following fields:

• CategoryId
• Description
• DueDate
• Index
• IsArchived
• IsCompleted
• IsDeleted
• IsDirty
• IsPrivate
• Notes
• Priority
• UniqueId

The elements emphasised above are those that the user described the task with (excluding "administrative" fields like whether it's private). All these task objects are stored within an encompassing object - PDTodoDbHHRecordAdapator.

For the purposes of synchronising to, an Access database with an identical structure was created in "c:\phtodosync\todo.mdb". The table of tasks I called "Records" and could be considered the equivalent of the PDTodoDbHHRecordAdaptor. Each task is like a PDTodoDbHHRecord.

With the setup of the corresponding Access database and the use of the task-related CDK objects, the conduit was pretty much done. It might be regarded as proof of concept rather than genuinely useful at this stage.

In order to actually use try the conduit, it needed to be registered with Palm's Hotsync manager. This was done with the CondCfg.exe program that comes with the CDK. To use the Palm todo database, you need to make your conduit have the creatorID of "todo". As only one conduit can have each creatorID, this means the original Palm conduit needed to be replaced. If you do similar, be sure to note down the initial values for the default conduit so it can be put back easily. The default options on my setup are illustrated to the right.

Using the conduit .exe attached below, the condcfg details were set as follows:
Conduit interface was changed to "COM-based conduit". The dropdown box was filled in with the path and filename to the .exe conduit file (e.g. C:\Conduits\todosync\PHTodoSync.exe). As the desktop data is to be stored in a predefined (hardcoded) database in c:\phtodosync\todo.mdb, the entries for desktop data dir and desktop data file were cleared. After these changes were saved, a Hotsync was performed from the Palm, and sure enough all the tasks on the Palm were transferred to the Access database.

(If for some reason you do want to try the below erm..."experimental" conduit, please note that it ignores any configuration opens you choose in hotsync manager - e.g. desktop to handheld, do nothing etc - it will always try and perform a 2 way sync. Really, really, really back up your data!)