Palm OS Programming | O'Reilly Media

Content preview·Buy reprint rights for this chapter

Palm has single-handedly defined the handheld market. Its operating system has dominated since it raced to the front of the pack of contenders six years ago. This is true even in the face of repeated handheld salvos launched by software giants such as Microsoft and Apple, and hardware giants such as Hewlett Packard and Compaq. Competitors have repeatedly attempted to penetrate this market and failed. The question that you have to ask yourself is, what did Palm figure out that others didn't? How did Palm at first succeed and continue to succeed even when so many others failed? The answer is easy to say but takes the rest of the chapter to explain. The simple truth is that they understood the magic formula—they figured out what customers really needed in a handheld and how much they were willing to pay. Wait, don't just gloss over this last sentence. Mull it over a bit and let it influence your thinking about your own software development ideas and how you evaluate the Palm OS.

Over the last five years, the market for handhelds has changed dramatically in many ways. The customer base has significantly broadened—there are early adopters, loyal followers, and business enterprise users, mixed with growing numbers of less-sophisticated general consumers. All of these folks are buying handhelds to organize differing aspects of their lives and they have enormously varying tolerances for difficulty and desires for the latest cool features. As of mid-2001, Palm and its licensees have sold more than 13 million handhelds and they control close to 80 percent of the market. This is a lot of people using a lot of handhelds.

This is all great news if you want to write software for the Palm OS platform. There are lots of potential customers. Whether you are developing consumer software, or enterprise software for thousands to tens of thousands of units, or a vertical application for a particular niche market, the Palm OS/device combination will work for you. It will, that is, if you pay attention to the key features that have made it successful.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Over the last five years, the market for handhelds has changed dramatically in many ways. The customer base has significantly broadened—there are early adopters, loyal followers, and business enterprise users, mixed with growing numbers of less-sophisticated general consumers. All of these folks are buying handhelds to organize differing aspects of their lives and they have enormously varying tolerances for difficulty and desires for the latest cool features. As of mid-2001, Palm and its licensees have sold more than 13 million handhelds and they control close to 80 percent of the market. This is a lot of people using a lot of handhelds.

This is all great news if you want to write software for the Palm OS platform. There are lots of potential customers. Whether you are developing consumer software, or enterprise software for thousands to tens of thousands of units, or a vertical application for a particular niche market, the Palm OS/device combination will work for you. It will, that is, if you pay attention to the key features that have made it successful.

So, here are those key features. Here are the elements of Palm's magic formula to a successful handheld:

Easy to carry
Inexpensive
Expandable (both for a user and a developer)
Effortlessly connects with a desktop computer
Works great and is simple to use

Every feature matters—you can't take one out of the mix and still have the same successful handhelds. So, while you may see some of these features incorporated into competing handhelds, you don't see all of them. As a result, it is clear to us that Palm continues to understand the handheld market better than its competitors and will continue to be far more successful. So, pay attention to the whole list of features. Likewise, notice how competing handhelds differ (later on we will look at some of the key differences). As you will see, Palm handhelds are great devices not because of one particular feature, but because of the combination of features.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

It would be good to stop at this point and examine why this company succeeded when so many other companies failed. How was it able to produce a successful handheld? It wasn't experience in hardware design—companies like Apple, Casio, and Hewlett-Packard clearly had more. It wasn't the breadth of features—Windows CE and Newton devices had more. It wasn't the price—Texas Instruments' Avigo was cheaper. So what did the Palm offer that all these other companies weren't providing? The answer was in the combination of features. It was a small, inexpensive handheld that worked great. These original units fit in a pocket easily, cost substantially less than most of the competitors' products, and did tasks that handhelds were uniquely qualified to do (like provide address books and calendars). Wait, wait, some of you might be stuttering, What about the list of features, the processor speed, the amount of memory, and the pixel depth of color screens? Nope, those things weren't compelling ingredients in the success story.

So, let's return to the list of key features and discuss them relative to the current situation of the handheld world. Also, let's look at the features, not in order of their importance, but in terms of how easy they are to understand. (As you will see, size is pretty easy to figure out, defining "works great" is a different kettle of fish.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Palm OS devices are small—they fit in a hand or a pocket. This was true six years ago and is still true today. Palm devices fit in anyone's pocket—whether it is the biggest device, the Palm VIIx, or a smaller one such as a Handspring Visor Edge. This is enormously important in understanding the success of the Palm. Other handhelds were made that didn't fit in a pocket and they bombed. In Table 1-1 you can see the footprint of some Palm OS devices to see what these magic dimensions are.

Table 1-1: Palm OS device dimensions
Device	Height (in.)	Width (in.)	Depth (in.)	Weight (oz.)
Original PalmPilot	4.7	3.2	0.7	5.7
Palm m100	4.7	3.2	0.7	4.4
Palm Vx	4.5	3.1	0.4	4
Handspring Visor	4.8

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Moving from size to cost, we encounter another item that has always been important in Palm's success: the price of the units is quite modest compared with other choices. This was true five years ago when a Palm device was half the cost of that of its competitors and it is still true today when Palm devices, whether made by Palm or a licensee, are still much cheaper. (See Table 1-5, which contains a vast array of comparisons.)

We believe that low entry price is a critical part of the equation of a successful handheld. Early adopters will buy whatever new gadget they want, regardless of price—they are by definition gadget fanatics who have to have the latest toys. Mainstream consumers who start using a new electronic device—be it a cell phone, VCR, DVD player, or handheld—seriously consider price. Users debating between a handheld purchase of a couple hundred bucks probably won't compare it to the possibility of buying a notebook computer instead (around $1000). Once the price of a handheld nudges into the $600 to $800 range then the jump to a notebook computer doesn't look so large. Furthermore, there are many new customers who will consider a couple hundred dollars to try out a new device and who won't even stop to look at a device over the magic $500 amount.

Price matters. So the real question becomes, what is the price point that justifies the utility of a handheld? Palm and its licensees set that threshold much lower. This strategy puts handhelds in a lot more hands.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Palm devices are simple, but are designed to be expandable. This was true from the very first Palm device to the current models. Let's look at hardware and then software to see what this means.

Palm devices come with very few types of built-in hardware features. While hardware features have changed over the last six years, this has been not so much an addition of features as an improvement of the existing ones. See Table 1-4.

Table 1-4: . Palm hardware features
Feature	Early units	Current units
ROM/Flash RAM	512K	2 MB
RAM	128K	8 MB
Screen type	Black and White	Grayscale and color
Infrared	No	Yes
Connection type	Serial	USB and serial

There are Palm OS devices that have bar code scanners, modems, MP3 players, and memory sticks; they are just not on every device. Likewise, you can buy modems, cell phone attachments, keyboards, and Global Positioning System (GPS) add-ons for a Palm handheld. From this, it is easy to see that Palm's strategy is to have this minimal set of basic features and encourage licensees and other hardware device makers to offer optional device enhancements.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Another one of the key features of a handheld is that it does not function independently. People want to use it in conjunction with their desktop computers. They also want it to work perfectly and easily.

Indeed, one of the necessary features that makes the handheld so useful—its small size—means that it simply can't do some tasks or have some hardware features. As a result it is absolutely dependent on a desktop computer to provide what it lacks.

Almost more important than what Palm OS devices have is what they lack. Palm OS devices do not have keyboards, full text recognition, or powerful processors.

Now, reflect for a moment on why this is so. Adding any of these features requires changing the magic combination of speed, size, and price that has made the Palm devices so popular.

Palm has announced that the next version of the OS (we'll call it 5.0, even though it may not actually ship as that number) will work on ARM processors, rather than the current 68K processors. This will provide more processing power. ARM processors, although somewhat more expensive than the current 68K processors, are very battery-efficient.

Designing a device with a keyboard is a double problem: it radically affects the size and it changes the types of things a user will attempt to do. If there is a keyboard, a user will expect to be able to enter text easily. But in order to handle extensive data input, you need a system that can support that type of activity, a processor capable of handling it, and screen that is big enough and clear enough to display it. Once you have both a system and a fast enough processor, the price has crept so high that users go get laptops instead; for just a few dollars more, they get a lot more capability.

By removing both the keyboard and any real way of handling text input in quantity, Palm kept its focus on the kind of device it was providing. Palm's strategy was to deliberately create a device that was an extension of a desktop computer. Think of the handheld as a "tentacle" (using the metaphor of the creator of the Palm, Jeff Hawkins) reaching back to the desktop. It is a window onto the data that resides on the desktop. Having this sort of window is so useful because it can be taken anywhere. Palm figured out that to be taken anywhere, it has to fit almost anywhere. So, absolutely, positively no keyboard.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now, we are into very subjective stuff and we are the first to admit it. When we say a handheld has to "work great and be simple to use" many of you may justifiably want a much more exact description of what this means—how the various combinations of features that go into the creation of a particular handheld translate into a great user experience. We would be the first to admit that how you compare and measure things like great backlit color screens against long battery life is notoriously open to debate. Whether the presence of a cool MP3 player or the ability to look at web pages is more important than the price is debatable.

It would be great to see about five years into the future when it will be obvious which were the right choices for today's customers. We could all pontificate about how we knew all along that this set of features and device options were the golden ones. Barring the presence of a rift in the time-space continuum, however, we are forced to guess. So, we will tell you about our guesses and Palm's guesses. We will tell you what Palm thinks "works great and is simple to use" means. These guesses have led to design decisions in the Palm OS and on Palm OS devices that will determine how you develop for this platform. Stated most generally, what Palm means when it says "works great and is simple to use" is that usability matters more than looks, and simple common features that work well are more important than lots of built-in choices. Quintessential handheld tasks better be easy to do and faster than lightning.

Let's see how these general ideas translate into current day device and OS decisions. First, let's examine the battery life issue, which we file under the category of "usability matters more than looks."

Palm OS devices, whether built by Palm or by its licensees, last a long time between battery changes or recharging. This is a big deal at Palm. Look, for example, at Palm's color m505 (a new device as of May 2001). Reviewers have said its screen isn't as clear as those of Pocket PC color devices. But the m505 has a much longer battery life than the color Pocket PC devices. This is an important difference and one you should not gloss over—it will dramatically affect how people use each device.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Here are the elements of that magic formula again:

Easy to carry
Inexpensive
Expandable (both for a user and a developer)
Effortlessly connects with a desktop computer
Works great and is simple to use

You, as a software designer, are responsible for adding to the expandability of the platform by creating software applications that work great and are simple to use. Part of this task is up to you and we can help you with the rest.

Here are our jobs:

Your job: Come up with the great application idea (if you don't already have one).
Our job: Help you understand what's involved in making a good idea into a Palm application that is simple to use and fast. We tell you about good Palm OS design. We also tell you what belongs in the handheld application and what belongs in the conduit. We give you some design guidance and tell you where to find information in this book.

We spent so much time discussing what makes Palm OS handhelds successful so that you would understand the design philosophy behind a Palm OS application. We do this in part, because handheld software is not like desktop software (any of you desktop software designers will have a bunch of bad design habits that you need to ruthlessly crush). These are the essential elements for which every Palm application needs to be designed:

Small screen size
Limited text input on the handheld

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In this chapter, we have described Palm devices, the circumstances that governed their design, and the history of Palm's success with this combination. Then, we discussed application design in light of the devices' history, design, and future directions. Last, we discussed the important elements in a Palm application and gave you some rules to help you start thinking about application design.

Now it's time to look more closely at development environments for the Palm. We tell you what is out there and how good it is. Following that, we turn to UI and design issues. As you read further, remember the magic formula and what applies most to you—applications are fast, simple, and small.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

This chapter deals with the what and how of the Palm OS and its features. First, we describe what you're programming for—the relevant aspects of the Palm OS. Then we show you how to do it—the available development environments. By the time we are through, you should have a good idea of the range of applications you can create for the Palm OS, the coding requirements, and which development environment you want to use.

Let's start with a piece of good news—there is a development environment for programmers of all types. Whether you are a C++ master or a Visual Basic newcomer, the popularity of the Palm platform means there is an environment for you to use.

Developing for the Palm OS is in some ways similar to other platforms and in other ways strikingly different. Two important similarities are as follows:

Applications are event-driven.
You can use anything from C++, to standard C code, to assembler, to scripting.

Differences tend to center around features crucial to the device size and purpose. These include how the Palm OS handles:

Memory requirements
Application and data storage
Connectivity of the device to the desktop

Most importantly, you should remember that the relationship between the device and the OS is extremely tight. Further, everything has been built on the premise that the handheld is an extension, not a miniature version, of the desktop. It specializes in ensuring that mobile tasks are simple and fast.

First, let's examine this tight interaction of the OS and the applications on the handheld. The Palm OS runs on top of a preemptive multitasking kernel. One task runs the UI, while other tasks handle things like monitoring input from the stylus. The UI permits only one application to be open at a time. Thus, when your application is open, it (more or less) has control of the entire screen.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Developing for the Palm OS is in some ways similar to other platforms and in other ways strikingly different. Two important similarities are as follows:

Applications are event-driven.
You can use anything from C++, to standard C code, to assembler, to scripting.

Differences tend to center around features crucial to the device size and purpose. These include how the Palm OS handles:

Memory requirements
Application and data storage
Connectivity of the device to the desktop

Most importantly, you should remember that the relationship between the device and the OS is extremely tight. Further, everything has been built on the premise that the handheld is an extension, not a miniature version, of the desktop. It specializes in ensuring that mobile tasks are simple and fast.

First, let's examine this tight interaction of the OS and the applications on the handheld. The Palm OS runs on top of a preemptive multitasking kernel. One task runs the UI, while other tasks handle things like monitoring input from the stylus. The UI permits only one application to be open at a time. Thus, when your application is open, it (more or less) has control of the entire screen.

Because applications run within the single-user interface thread and can't, themselves, be multithreaded, the multitasking provided by the kernel is for the operating system's use only, and isn't available to you.

Memory is handled in an unusual fashion (discussed in detail in Chapter 6). The RAM on a Palm OS device is used for two purposes:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The second part of the Palm application is the desktop connection. Because a Palm device acts as an extension of the desktop, it is crucial that information be easily exchanged. Conduits are the mechanisms for doing this (see Figure 2-1).

Figure 2-1: Conduits control the exchange of information

A conduit is code on the desktop that is called during a HotSync to manage the flow of information between databases on the handheld and the desktop. Conduits register the database or databases for which they are responsible. Note that each database should have only one conduit responsible for it. Conduits are created using the Conduit Development Kit (CDK) for Windows or Mac OS.

Applications that do not have a conduit portion use a system-provided one instead. This conduit is used for backups and is part of HotSync. This backup conduit copies the application data or database from the device and stores it as a file. You specify that you'd like a database to be backed up when you create a database. Think of this as the "If you can't afford an attorney, one will be appointed for you at no charge" conduit—the last resort.

During a HotSync session, the backup conduit is called for databases that have been marked as needing backup. At this point, it copies each record from the database and copies database header information into a file. This file can then be used to restore the state of the device (including applications) if necessary. For example, if the user has to replace a handheld it takes only a sync to restore it to the previous handheld's state.

More sophisticated conduits do more than this basic copying of information. They can read or write specific information to or from the device. For example, a conduit for a sales application might handle the downloads of new price lists, overwriting any existing price list that has expired. It might also be responsible for uploading a database of sales orders.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As we said earlier, the good news is that there are many different development tools available for Palm programming. There is everything from a collection of tools that let you write C code to polished forms-based packages that require only modest amounts of scripting. From this gamut of choices, you should be able to pick the right tool for the type of application you want to create. Before we discuss the advantages and disadvantages of each choice, however, we describe each environment.

For the development of the handheld portion of your Palm application, you can write code on Windows, Unix, or Macintosh platforms. Palm's official development environment, CodeWarrior, is available for both Windows and Macintosh. Unix and Windows programmers have access to a free set of tools—PRC-Tools based on the GNU C compiler, or GCC—and there are packages for Windows-based form development. Last, but not least, programmers can use 68K assembler or other languages.

The official development environment for the Palm OS is Metrowerks's CodeWarrior for Palm OS. This allows you to create ANSI C and C++ programs on either Windows or Macintosh systems. CodeWarrior for Palm OS costs approximately $369. Here is a description of the tools that it gives you for Palm OS development:

Constructor for Palm OS: Constructor is a graphical resource editor that you use to create the UI elements of your application (see Figure 2-2).

Figure 2-2: Creating an application's resources using Metrowerks Constructor

CodeWarrior Integrated Development Environment (IDE)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The following sections describe several useful alternative development environments for the Palm OS.

There are two different full Java environments, as well as two Java-like environments. Keep in mind, however, that there is a definite overhead to using Java (interpreters and garbage collection take time, virtual machines take storage space).

Section 2.4.1.1: Sun KVM

Sun's approach to Java is to provide a way to write Java applications that will run across multiple platforms. Since the Java 2, Standard Edition is too large to run on small devices like those running the Palm OS, Sun has defined Java 2, Micro Edition (J2ME), a subset of the standard edition with new class libraries.

Sun has defined configurations : APIs targeted at classes of devices with related characteristics and limitations (memory, speed, and so on). The configuration for Palm devices is the Connected Limited Device Configuration (CLDC), which targets devices like PDAs, cell phones, and two-way pagers.

There are also profiles , which are more specific. There are two profiles of interest for Palm OS devices: the PDA profile (which, at the time of this writing, was not yet defined) and the Mobile Information Device Profile (MIDP). MIDP applications are called "MIDlets" and can run on any CLDC configuration with the MIDP profile.

Sun has a version of the CLDC configuration and MIDP APIs for the Palm OS at http://java.sun.com/products/midp/palmOS.html.

Section 2.4.1.2: IBM VisualAge Micro Edition

This product uses a slightly different approach than Sun's write-once run-anywhere strategy. Instead of a portable API across different platforms, VisualAge provides native access to all of the Palm OS. You call the same APIs that a C programmer would call. It provides support for using Java as an alternative programming language, as opposed to Sun's approach, which views Java not just as a language, but as a portable platform.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Palm devices are so numerous and applications so popular that there are even a couple of third-party development environments specifically for creating specialized forms-based Palm applications.

Satellite Forms, by Puma Technology, is an environment for creating very sophisticated Palm OS applications. In Satellite Forms, your application consists of a number of database tables and forms. Each form is tied to a specific table. UI elements on a form can be tied to fields from the table. For example, a checkbox will display the value of a Boolean field; tapping the checkbox will automatically update the field.

Instead of using C/C++ code, you control the actions of the application in one of two ways:

You specify a set of built-in actions that occur when the user taps a control. For instance, when a button is pressed, you could request (among many choices) that a new form be opened or that you return to the previous form.
You specify custom code that you want executed. The code is created using a scripting language that is very similar to Visual Basic.

The application comes with a number of built-in controls as well as a library of routines. Satellite Forms also has an extension mechanism that allows you to write C code for your own new controls and new libraries (imagine, for instance, a library of financial routines or a new UI control).

Satellite Forms has an ActiveX control that is connected to a HotSync conduit. You can use the ActiveX control during HotSync to copy any table to, or from, the Palm device. The tables are stored on the desktop as DBX files (standard dBase files), which can be easily integrated with any database.

As of the writing of this book, the price tag for Satellite Forms was $795 (plus license fees for the runtime engine). You have a couple of limitations, as well. It only runs on Windows and applications you create require a runtime library on the Palm device. There is also a charge to license the runtime library, which can make it very expensive to deploy applications built with Satellite Forms. There is a demo version (which limits the number and size of the tables you create, and doesn't allow the creation of new projects) available at the company's web site (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that you have a good idea of the choices for creating applications for Palm devices, it's time to figure out which is right for you. It should not be surprising that Windows programmers have the most flexibility; Macintosh and Unix folks have none. Let's look at the Macintosh, Unix, and then Windows choices in order.

CodeWarrior for Palm OS is currently the only way to do development on Mac OS 9 and under. The good news is that CodeWarrior for Palm OS started on the Macintosh, so you can be assured that it's a robust, elegant product.

If you use Mac OS X, you have the option of using PRC-Tools.

You'll be using PRC-Tools for your development environment. This isn't really a disadvantage, however. If you are accustomed to twiddling around with Unix in the first place, then the slightly more complex setup of PRC-Tools (e.g., the need to use makefiles) won't even get a twitch out of you. Plus, it's free.

You have quite a bit of choice, as every environment we have discussed is available on Windows. Let's try to eliminate some of the options by focusing on what might factor into your decisions:

Assembly programming: If programming in assembly is your cup of tea, then ASDK is for you.
C/C++ programming: If you are an ardent C programmer, use CodeWarrior or PRC-Tools. If you are an occasional or hobbyist programmer, then PRC-Tools is probably your best choice, given its attractive sticker price. While it is more flexible, it is also more difficult to use (it requires familiarity with makefiles and command lines).

For greater usability, we suggest that you go with CodeWarrior. The project-based IDE can make development much easier.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you are creating a conduit for your Palm application, you need to do so on Macintosh or Windows using Palm's Conduit SDK. The Conduit SDK comes with the following:

Header files
Libraries
DLLs
Frameworks
Source code for sample conduits

Under Windows, a conduit is a dynamic link library (DLL) that is called when a HotSync occurs. An install DLL is provided for you to register your conduit with HotSync. On Mac OS, a conduit is a shared library.

Conduits have access to databases on the Palm OS. The Sync Manager handles the complexities of communication; it is not your concern. You simply call routines to read and write records in the database. The Sync Manager handles the communication protocol.

In order to develop conduits for Windows, use a compiler that can generate 32-bit DLLs (the compilers supported by Palm are Visual C++ 6.0 or Metrowerks CodeWarrior for Windows). For Mac OS, you can use any development environment that has the ability to create shared libraries (CodeWarrior for Mac OS is a likely candidate).

C++ classes that simplify creating a synchronization conduit are provided by Palm (Generic Conduit Framework). These C++ classes are the basis of a number of sample conduits. As your application's syncing needs differ from what is provided by the Generic Conduit Framework, the C++ classes become less useful, and you might wish to consider reverting to the underlying C/C++ Conduit Manager API to make things work properly.

Presently, Java conduits work only on Windows. Conduits written in Java can take advantage of Java Database Classes (JDBC) for easy interaction with database engines. The sample code that is part of the Conduit SDK, Java SyncSuite, uses JDBC to interact with an Oracle database.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You should now have a good idea of which development environment you want to use to write your Palm OS applications. You should also know enough about the features in the Palm OS and the devices to make intelligent decisions about the types of applications that you can create for Palm devices. Next, we discuss UI issues in more detail.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that you know about the features of the Palm OS and you have figured out what development environment you are going to use, it is time to design a new application. To do this, you need to know what the Palm OS provides by way of UI elements. Second, you need a description of how and where these elements are used in an application. To this end, we show you several forms, dialog boxes, and alerts; we discuss what works and what doesn't, so that you can intelligently design your own projects.

From this discussion of UI elements, we move to the more general discussion of key issues that need to be addressed in the design of any Palm OS application. We cover everything from what OS versions you should support to determining what tasks an application should accomplish.

From this general overview, we move to a concrete example: the UI of the Sales application. This is the sample application that we are going to create and then dissect in this book. We show you its design, what actions the user performs, how we prototyped it, and the design complications we encountered. Once we've covered the handheld portion of the application, we turn to a description of its conduit.

Throughout this discussion, keep in mind the important principles you learned in Chapter 1 about the design of a Palm OS device. Remember also that a Palm application needs to work great and be simple to use. This means that quintessential handheld tasks must be simple to do and faster than lightning. A good application also has to take into account the small screen size, limited memory, and limited processor ability.

With these application goals in mind, examine the UI elements that Palm OS gives you and the principles of design we recommend. If you fit your application within this model, all it needs is a great idea. If you don't, your application will be lackluster, bloated beyond recognition, confusing, and a waste of a great idea.

The Palm OS provides you with an abundance of UI elements. In what follows, we give you a description of these elements. We also show you some common examples of each type and, where relevant, give you guidelines on its placement and use. (Later chapters show you how to create them and implement them in your code.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Palm OS provides you with an abundance of UI elements. In what follows, we give you a description of these elements. We also show you some common examples of each type and, where relevant, give you guidelines on its placement and use. (Later chapters show you how to create them and implement them in your code.)

Figure 3-1 shows a typical alert. It is simply a modal dialog box that displays a title, a message, an icon, and one or more buttons. You are responsible for setting the text of the title, the message, and the button(s). You also specify the type of alert. It can be any of the following types (arranged from mildest in consequence to most severe):

Notification: This has an "i" icon. The alert provides the user with some information (for example, that an action can't be completed). No data loss has occurred.
Question: This has a "?" icon. The alert asks the user a question and asks the user to confirm an action or choose from possibilities.
Warning: This has a "!" icon. It asks the user if the action is really intentional. Data loss could occur if the action is completed. The Memo Pad uses a question alert for deleting memos, since the user can choose to save an archive on the PC (thus the data is not lost). However, the system uses a Warning dialog box when the user chooses to delete an application, since after the delete, the application is completely gone. Figure 3-1 shows a warning alert.
Error

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now we are going to turn to more general issues of design. First, we are going to explore how the audience and expected use of an application can shape how it is designed. To this end we will compare three applications: the built-in Date Book, Datebook+, and DateBk4.

The application, DateBk4, by Pimlico Software ( http://www.pimlicosoftware.com) has been extremely popular with Palm users through several revisions. It is so well liked that Handspring is shipping a simpler version of the application, called Datebook+, on all Handspring Visors. This situation allows us a unique opportunity to study one type of application (the scheduling type) that has been designed for different audiences. The built-in Date Book and Datebook+ are designed for everybody. DateBk4 is for sophisticated Palm power users. Both Datebook+ and DateBk4 are intended to offer the Palm user more useful alternatives to the built-in Date Book application.

The author of DateBk4 and Datebook+, C. E. Steuart Dewar, has graciously allowed us to use his applications as Palm UI teaching tools. His work is a great choice because:

It has been designed for more than one audience.

DateBk4 has previous versions (so its design and features have been subjected to user feedback and revisions).

DateBk4 is very popular and therefore, by definition, must be useful to many real Palm users. (This is a important criteria for judging the UI of any application!)

We'll show you the design decisions the authors of each application made for their audiences. We'll explain the issues that influenced their choices, which design rules they violated and why, and in general tell you what we think. In the instances where we might disagree with design choices, we offer you some other alternatives to consider.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that you have seen some examples of the UI objects available on the Palm OS, and seen how the audience of an application can affect its design, it is worthwhile to show you some well-designed and not-so-well-designed forms. We will also point out important placement rules that agree with Palm's own guidelines along the way.

Here are the important optimization rules to use when designing your forms:

The quintessential handheld tasks your application provides should drive the design.
Minimize the number of taps and time to complete frequent actions (follow the 80/20 rule).
Minimize screen clutter by hiding infrequent actions in menus and other forms.
Provide command buttons for common multistep activities.
Minimize switching screens for common tasks.
Be clever in implementing unique aspects of the application.

In these next sections, we will show you some forms that in some ways follow these placement rules and in some ways that violate them. You should keep these optimization rules in mind as we look at their designs.

We are looking at the To Do list as an example of a well-designed main form of a built-in application (Figure 3-34).

Figure 3-34: The To Do list

Some of the essential features of any main form of an application are:

It uses the entire screen or in other words, it is modeless.
It has a title (tapping on the title in OS 3.5 or later should display the menu bar).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Most applications contain a certain number of core user interface elements. Even the simplest application will, at the very least, need a form and some controls. Most applications go well beyond the minimal number of features and have multiple menus, forms, and dialog boxes. You will have to decide about these forms, as well as the types of screens (black and white, grayscale, color, pixel depth) that you will support. There are also OS versions to support or ignore. Finally, and most importantly, there are a couple of gotchas that commonly get programmers from the desktop world. Let's look at these first.

There are two common problems that desktop programmers stumble upon when they enter the handheld world: what to do about passwords and where to put the Exit button. Thankfully, we can tell you exactly what to do about both of these situations.

Section 3.4.1.1: Handling passwords on a handheld

In the desktop world, it is common to present a dialog box in which the user enters a password where the actual letters or digits in the password are obscured with asterisks (*) or other symbols. You must not obscure a password on a Palm handheld. Instead, show the actual letters and digits the user enters in the dialog box (see Figure 3-44).

Figure 3-44: Entering a password in the Security application Password dialog box

You also need to show the actual letters and digits in any verification dialog boxes and in an initial dialog box that you present to allow access to your application (that has been password protected). There are two good reasons for this absolute rule:

The practice of obscuring passwords came about on the desktop because someone might well be looking over your shoulder at the screen when you need to enter the code. (It is kind of hard to pick up a desktop computer or hunch over enough to cover the screen.) This situation does not exist on the handheld; a user can easily move or shield the entire screen to hide what is being entered.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Some of you may be wondering how useful the Sales application will be to you. Does it show you how to use all the APIs? Does it contain the essential components of most Palm applications? Here are some answers. The Sales application uses much of the Palm API and, to that extent, offers a broad treatment. Because it isn't an exact clone of the built-in apps, you will see some new design issues and code. You also get to see our reasoning behind the design choices we make. The application implements databases, beaming, menus, dialog boxes, and Find. Another crucial component is the detailed description of its conduit. We hope that much of what is mystifying about conduits is clarified in our descriptions and the code we create.

We also cover some Palm OS features in smaller sample applications. We handle tables, serial, and TCP/IP in this manner. Indeed, we try to show an implementation of most UI objects in at least one sample application. Our objective was to treat the easiest issues lightly and spend much more time on the most difficult or important ones. Our examples are created with this goal in mind.

Here are some of the important coding tasks you will be able to do in your own applications when you have worked through our examples:

Create forms, menus, alerts, and dialog boxes in a Palm application.
Create and use most UI objects in the Palm OS.
Create multiple databases; add, delete, and modify records in those databases as necessary.
Support Find.
Support Exchange.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The sample application we are creating is a forms-based application that will be used to record orders. This application is for a person who sells toys to stores. These are the activities we want the salesperson to be able to accomplish in the application:

Create a new order for a customer.
Delete an order.
Delete or modify items in an order.
Beam a customer to another device.
Modify, delete, or create a new customer.

The user starts the application and picks a customer from a listFigure 3-45.

Section 3.6.1.1: The Customer list

This is the startup form of the application. It is a list of all the customers that our salesperson normally sells toys to during that selling period. The user can tell which customers already have orders because those who still need orders are in bold.

We admit that bolding an item to indicate status is a subtle, if not obscure, design element. Its presence is reasonable when you remember the audience of this application. The same user will use it daily for taking orders. The bolding of an item in a constantly used application may be warranted, while it may not be in a more general purpose application. In any case, a user who doesn't know what the bold is for is not hurt—it's just a shortcut for the experienced user.

When a name is selected from the Customer list (see Figure 3-45), the Order form for that customer is opened.

Figure 3-45: Picking a customer from a list

For the rare occasion that the salesperson may want to create a new customer while out in the field, we provide this capability on the handheld. On Palm devices with IR capability, the salesperson might also want to beam customer information. Both these actions are handled in this form as part of the Customer list record menu (see Figure 3-46).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·

Table of Contents

Section 2.4.1.1: Sun KVM

Section 2.4.1.2: IBM VisualAge Micro Edition

Section 3.4.1.1: Handling passwords on a handheld

Section 3.6.1.1: The Customer list