Programming Visual Basic for the Palm OS

Chapter 1. Introducing AppForge

Over the past five years, the Palm PDA has zoomed to prominence as the handheld device of choice for the consumer and the enterprise. In that time, the Visual Basic developer has been relegated to the sidelines—the Palm doesn’t run the Microsoft Windows operating system, and its processor isn’t based on a design from Intel. The available development tools mostly favored the C/C++ developer, or they required an individual or corporate investment in a proprietary scripting language.

All that changed when AppForge introduced its flagship product, a VB compiler for the Palm. AppForge calls its product a “family of visual software tools that enables virtually anyone to write engaging GUI software for non-PC computer devices.” (In this chapter and throughout this book, when we mention AppForge, we mean the add-in for VB for Palm OS.)

AppForge is an add-in for Microsoft’s Visual Basic. With AppForge, developers build applications that execute on the Palm PDA from within the native VB integrated development environment (IDE). Instead of compiling code into a Windows executable, AppForge generates a Palm Resource (PRC) file—roughly speaking, a program file.

From a practical perspective, this means that it is very easy to come up to speed with the AppForge tool. Developers can focus right away on forms and controls, events and procedures, without learning a new development environment.

In this chapter, we take a quick look at what it means to develop software for the Palm handheld device, which is very different from the Windows desktop. We provide an overview of the AppForge product—what it is and how it works. We cover installing AppForge onto a development system, and we explain how it integrates into the VB IDE.

After all that, we’ll walk through getting a simple project up and running. Along the way, we’ll touch on some things that are different from desktop VB development, such as cross-platform emulation tools and the user interface controls for the Palm.

Palm Software

If you are reading this book, the chances are high that you are new to Palm software development or to the AppForge product, or very likely both. Writing software for embedded devices—such as the Palm, the Pocket PC, or pagers like the RIM Blackberry—was once the exclusive territory of the professional C developer. Every bit was counted, and every screen pixel hoarded.

This approach is still important—you simply cannot write software for the handheld market as if it were the Windows desktop. Microsoft has been trying that for years with dismal results. Consumers and corporate users do not buy handheld devices for the quality of the Web browser; instead, they want focused tools that enhance personal productivity or enable key business processes, and they want applications that run quickly.

Look in a typical PDA, and you will see organizer software, notepad programs, diet and exercise planners, newsreaders, games and entertainment software, stock applications, and so on. In fact, one of the major reasons for the success of the Palm device is its thousands and thousands of quality software products.

All these successful applications share at least one common factor: they are focused on providing exactly what the user wants, and little else. They do not provide a feature list bloated with nice-to-have features; they do provide timely access to information that really matters—a telephone number, a stock quote, a photograph, or directions to the shopping center.

This book cannot tell you which features are critical to your users and your market—only you can do that. This book will, however, show you when and how to use the available Palm features to structure a program that works well on the handheld device.

If you are completely new to the Palm, you should stop right now and get a book on using the Palm handheld device. This will give you a better foundation for developing software that fits the Palm device. There are many important differences between desktop and Palm development that will force you to rethink the way software is engineered and used.

There is just no way around the fact that handheld devices are small. The Palm OS currently supports a screen that measures 160 pixels tall by 160 pixels wide. The majority of Palm devices have monochrome screens that can display four shades of gray, two of which are black and white.

By way of contrast, consider the font selection listbox in Microsoft Office’s Word application. That single feature of Word is about 240 pixels wide by 270 pixels tall—over two and a half times the available screen size for an entire Palm application. Figure 1-1 shows the listbox with the Palm screen superimposed on it.

Figure 1-1. Sizes of Microsoft Word font selection listbox and Palm screen

The Palm device has no keyboard and no mouse—only a stick that functions as both. The stick is referred to as a stylus. Text entry is done in the Graffiti language—sort of a block alphabet—that the serious user will master. Novices will use the virtual keyboard and tap out their words one letter at a time. Even with practice, it is difficult to key in more than a dozen words per minute.

But there are also many advantages to working with the Palm PDA. The screen is touch-sensitive, which means that you can be very creative in how your application handles user input. The hardware buttons, particularly the scroll buttons, provide other opportunities for innovative input techniques. There are add-on keyboards available if your application relies on significant data input. And the screen limitations themselves impose a discipline—you should constantly consider why a certain feature needs to be on the screen, or if there is a more effective way to present it.

Many Windows applications are open and idle in the background for extended periods of time. The user can probably spare a few minutes to get some coffee while your application is opening files or running a data-mining query. Since the application might be open for several hours, these moments are insignificant over the course of a business day.

The Palm user, however, accesses an application such as the Address Book very frequently during the day, even though she may only use the application for a few seconds each time. Since the Palm runs only one program at a time, an application is always starting and stopping—an inordinate delay in either process can be excruciating. Your design must address response times, in particular how quickly the user can navigate and access the really vital functionality.

Here is something else to think about: most Windows applications are used on a stable desktop, with the user seated in a chair. Consider where the Palm device is most often used—the hand. The user might be in an elevator, or stopped at a traffic light. He is not going to wait 10 or 20 seconds for your splash screen to initialize—after all, the light might change.

Now consider the basic Palm device itself. Entry-level models have a 16 MHz central processor, 2 MB of memory, a couple of AAA batteries. This represents computing power that was nearly obsolete in the 1980s, when the Apple Macintosh was a fast machine. On the positive side, the device contains fully functional serial and infrared ports that offer standards-based communication with computers, cellular phones, and printers.

When designing software for the Palm, you must consider these factors if your application is to have the “Zen of Palm”—that combination of features and ease of use that can make the handheld so compelling.