I’ll admit I was excited but a little skeptical when I first read the announcement of the release of AppForge. Excited because here was a product that promised to unite two things I dearly enjoy, Visual Basic and Palm development, but skeptical at the prospect of translating VB and its large runtime footprint onto a diminutive PDA. At first pass, AppForge appears to be an ideal value proposition: Take the refined, powerful VB IDE and leverage it into a Palm development tool—how can you lose? There are some problems, however, as we’ll get into later in this article. But first, what is AppForge?

AppForge installs itself as a Visual Basic IDE add-in and provides a new project template (AppForge Project), which replaces the standard VB controls with analogous Palm widgets collectively referred to as ingots. It provides label, textbox, list-box, combo-box, shape, timer, radio, checkbox, grid, command button, animation, and image ingots, which you use to build the your application’s user interface. Figure A shows an AppForge form holding several ingots.

Figure A
The main form of the sample TVToday application, showing a few ingots

AppForge lets you build your database tables using Access and provides a tool to convert them into and from Palm’s PDB format. Most Access field types are supported, but there are some, like Decimal and Currency, that don’t have direct PDB analogues and can’t be converted. Check the AppForge user’s guide for details. When you create a new AppForge project, the project template automatically references a set of database access routines for you.

Although the method of accessing databases on a Palm will seem crude to those used to higher-level techniques like ADO or DAO, AppForge’s standard utilities make things as easy as possible by making the data sources anonymous. That is, your application effectively doesn’t care if it is reading from an Access MDB or a Palm PDB; the code you write to do so is identical. The only part that you, as a programmer, have to take care of is detecting whether your app is running in the IDE (check the constant APPFORGE) and, if it is, specifying a full path to the MDB file when opening it.

While building an application, you write real VB code in a real VB project in VB’s IDE, and all the debugging features of the IDE remain available while building and testing it. No need for ROM images or emulators; you can test your work right where you wrote it. Figure B shows the VB IDE editing a sample AppForge project.

Figure B
The VB IDE while editing an AppForge project

To run your application on a Palm, you first have to upload the AppForge runtime component, or booster, to it. Once that is done, you can invoke AppForge’s prc compiler from the AppForge menu, upload the app to your handheld, and continue with your testing.

Going on a test drive
To get my bearings with AppForge, I worked through the TVToday tutorial, which demonstrates the process of building an application that reads TV schedule information out of a database and allows the user to browse the schedule by day and time or by genre. I wasn’t far into the tutorial (step 3 of lesson 1, actually) when I discovered one of AppForge’s quirks: It requires a new form to be saved to disk before an ingot can be added to it. This is contrary to the way I (and most other VB developers I know) build a form—it usually has several controls on it already before it gets saved for the first time. It’s a minor thing, and while I think I understand why AppForge works that way, I still found it irksome until I got used to it.

I hit my second snag when uploading the compiled TVToday program and runtime booster to my old workhorse 2-MB Palm III. To say that the AppForge booster is big would be a serious understatement. At 335 KB, the booster is, in fact, a monster—so large that I had to do some housecleaning to get enough free space in order to successfully install it onto my Palm.

Do you use AppForge?

Does your organization use AppForge? If so, do you love it or hate it? Send an e-mail to the editors and tell us about your experiences with AppForge.

Once I had enough memory to install it, however, the sample program worked fine. Database access was noticeably slow, but on the whole, the application seemed to be responsive and performed well. I checked the time, and in a little under two hours, I had built a functional and very nice-looking Palm application. Rapid Application Development, indeed.

Forging ahead
With the basics now under my belt, I decided to play around a little. I quickly discovered that AppForge implements only a subset of VB’s core features. This is actually to be expected, considering how many of VB’s features are based in COM. The user’s guide explains it all clearly and includes a reference section detailing the differences between AppForge and VB. For example, Class modules aren’t supported, and neither are some built-in types such as variants and collections. Many objects that are supported have only a subset of their original methods or have slightly different method declarations than their non-AppForge counterparts. Obviously, standard ActiveX controls and components aren’t supported either.

The AppForge compiler does a nice job of catching differences like these for you, but of course, VB’s compiler and Intelli-sense are ignorant of any such restraints. They will happily let you do things that AppForge chokes on, like overlap controls on a form, try to open a form modally, and so on. As a result, until I got used to the differences, I found myself referring to AppForge’s help files constantly, wondering, “Can I do that?”

What do you want?

Do you have a favorite Palm development tool you’d like to see us talk about in the Pocket Programming column? Send the editors an e-mail.

So what’s the verdict?
Despite niggling complaints, I found AppForge to be a very capable Palm development tool. Being able to use the product from within a familiar and powerful development environment is certainly a plus. Your first few hours with AppForge might be frustrating as you learn some of its limitations, but it’s easy to become productive quickly. By leveraging Visual Basic, AppForge inherits many VB advantages: rapid development, easy debugging, and so on. Unfortunately, it also inherits the traditional knocks against VB: relatively steep system requirements and large runtime library.