Programming Visual Basic for the Palm OS

Conduit Design

There are several major design principles for a conduit. The first, and most important, is that the conduit runs as quickly as possible. No one wants to wait while synchronization grinds on and on. Honoring the fast and slow sync flags will help you to optimize performance. A fast conduit also minimizes the use of the Palm device’s serial port. This is important, because serial port use can drain the PDA’s batteries very quickly.

The second principle is that a conduit must always move application data in a natural way between the Palm device and the desktop. Your user relies completely on this behavior. She also relies on the conduit to restore all data in case of a disaster. If your conduit is not correctly implemented, or has bugs, user acceptance of your application will suffer greatly.

A third principle is that your conduit must be able to run without attention from the user. While this is a good design principle for software in general, it is especially important for a conduit. This is because the user might be synchronizing from a remote location, communicating with the HotSync manager over a modem or network connection. The user will not be able to respond to any prompts or dialog boxes that a conduit might display on the desktop. This will cause the entire HotSync session to hang.

Palm provides some more design guidelines in the C/C++ Conduit Companion; you should certainly study those before implementing your own conduit.

If you are building a mirror-image conduit, then follow the logic diagrammed earlier in Tables Table 4-2, 4-3, and 4-4, as they apply to your application. If you don’t allow desktop editing of data in your application, for example, then your conduit doesn’t have to support it, either.

Having a user interface and allowing the user to override the conduit’s default behavior will help you achieve acceptance. If at all possible, support uploading or downloading all records from your user interface.

Note that if your Palm database design maps into a relational database, and you used the AppForge database tools described in Chapter 4, then you can likely use the Universal Conduit. We discuss the pros and cons of the Universal Conduit in Chapter 5, and show you how to use it to integrate SQL Server data into your applications.

When Not to Use a Conduit

Not all synchronization situations require you to implement a conduit. It is perfectly appropriate to make a new database from scratch and download it to the device, if you know that all or most of your application’s data has changed.

Simply generate your database from the new data, and put it in the HotSync installation directory.^[28] The database will be automatically deployed to the device with the next synchronization, overwriting any existing PDA data in the process. If your application has a database that is read-only, and that is periodically refreshed, you can use this technique. If your sales department produces a list of prices that changes monthly, then you don’t need to execute a conduit every day.

Not having a conduit can greatly simplify the distribution of your application. You don’t have to worry about developing an installation script for your conduit and its associated runtime objects.

If the Palm Desktop is configured properly, the Windows default shell action for PRC and PDB files is to call the Palm Instapp.exe program, which will copy the file into the Palm desktop installation directory.

This means that you can post your database files on the Web or in ZIP archives. When your user downloads or extracts your file and double-clicks it, it is queued for installation at the next HotSync.

---

^[28] You can use the InstallAide functions to do this, which are part of the Palm Desktop. These functions are described in the CDK documentation; we don’t discuss them in this book.