PDA Application Walkthrough

The first prototype for the Pocket PC is partially functional - the screens flow properly, but the data is not fully connected to the (internal) database, nor is the sync-to-PC working.

It is easy to write software for this platform with Embedded VB, which has some signicant limitations, but is sufficient for simple application.

A different Conduit will be necessary, as the Pocket PC conduit programming model is quite different from the Palm model. They can both use the same database, administrative software, reports, etc.

I found the software needed to create a conduit for the Pocket PC platform. However, for that platform I have seen the suggestion to not use the ActiveSync process, but instead have the application contact the database or backend system and perform its own sync; for the prototypes I experimented with both approaches to understand the tradeoffs. The prototype shown here accesses data from a MySQL database, not using the ActiveSync process.

Also, while Palm development can be done 99% with the Palm Emulator (on the PC), Pocket PC development requires heavier use of an actual device.

It's common to have a more stylized application appearance on Pocket PC, than on Palm. In keeping with that, the final application may have more interesting button appearances, non-white background, etc. (Of course it will still have a clean, professional appearance appropriate for this kind of application.)

The default fonts are smaller on the Pocket PC, showing more lines of text per screen.

Note that Pocket PC devices actually have a lower screen resolution (240x320) than the newer Palm devices (320x320). The text is noticeably sharper on the Palm Zire 71 than on the HP Ipaq 5455.

This is as far as I got on the eVB prototype, before proceeding to the next option.

I moved on, because of several factors:

1. The eVB application performance was not particularly good.
2. It was obvious for online forum discussions that eVB has many limitations which surface later in development.
3. It is clear that the C/C++/API approach, as well as the .NET Compact Framework, will be in common use for a long time, but Microsoft recommends moving future eVB projects to the .NET Compact Framework, and is not intending any further development of the eVB tools.