Palm OS Programming, 2nd Edition

Designing Applications for Palm Devices

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.

Essential Design Elements

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

• Seamless syncing to a program on a desktop computer

• Small in size, simple in design, fast as lightning (at least for common tasks)

But there is all the difference in the world between listing these elements and knowing how to design an application that uses them. Let’s address each point in turn.

Designing for a small screen size

The size of the standard Palm OS screen is a mere 160 x 160 pixels in a 6 x 6 cm area. As its history has shown, the form factor of Palm devices is absolutely essential. It’s small so people can take it anywhere easily. You should assume that this screen size is here to stay. Unlike some other handhelds that have changed size this way and that, Palm devices will keep this form factor for some time. While you might expect to see some integrated devices with a different screen size, these will be for very specific uses and won’t necessarily pertain to the design of most Palm OS applications. However, although the size will probably remain constant, you may see the number of pixels in that area increasing (for higher resolution). An example of this is the Sony Clie with its crisp, clear 320 x 320 pixel screen.

The data you present in an application needs to be viewable in the 6 x 6 cm area. Because the area is so small, you will need to break data into parts. While keeping the data in logical groups and relying on different views to show each element will help, you will undoubtedly need to iterate your design several times to get it right.

Look at how the Date Book handles the presentation of appointments, for example. If the user has many appointments in a small period of time, that portion of the day is shown. The user doesn’t have to scroll through large gaps or look at lots of blank areas. The application shapes the way the data is presented to accommodate a small screen.

Start the design process by mocking up a couple of screens of data. See if the data falls into logical groups that fit nicely in the small area. If you are requiring your users to scroll back and forth continuously, rethink the organization. Here is the first rule to remember: the screen size drives the design—not the other way around.

If you are making the user horizontally and vertically scroll through blank areas continually, redo your design. Trying to display too much data can require the user to do too much scrolling; too little data can require flipping between too many views. You have to find the right balance.

Limiting text input on the handheld

HotSync and wireless technology make text input far less necessary on the handheld. The small screen size and lack of a keyboard make text entry difficult. All this leads to an ironclad truth for you to remember: a Palm handheld is not a manual text input device. The user has a nice desktop computer that contains many good things to facilitate text entry: keyboards, big screens, and fast processors. A Palm handheld has none of these things. These facts lead to another rule in designing for the Palm OS: data is entered on the desktop and viewed on the handheld.

Obviously, we are not excluding all data entry or even trying to limit some types. For example, the application we create in this book is an order entry application. In this case, the handheld user is not required to enter text, but instead picks items from lists. This works nicely because picking things is easy, while entering text is hard. It is also clear that there are some obvious places where users need to enter data on their handheld, such as in the To Do list. Apart from effortless data entry, you should steer your user toward adding data on the desktop.

Tip

Symbol’s SPT 1500 provides a great example of effortless data entry on a large scale. With this device, the user has a way to enter data (via the bar code reader) quickly and easily while not sitting at a desktop.

Where your application does allow the user to input something, you will need to support the system keyboard, Graffiti input, cut, copy, paste, and undo in the standard manner as outlined in the documentation. Likewise, you need to support any shortcuts to text entry that the Palm OS documentation describes.

Seamless syncing

The bold stroke of providing a convenient cradle and an easy-to-manage connection with the desktop has been crucial to Palm’s success. Palm engineers designed these handhelds to exist in a symbiotic relationship with another computer. As a result, an enormously important part of your application is the conduit—this is code that runs as part of the HotSync process on the desktop and transfers information to and from the handheld. In a symbiotic relationship, both organisms rely on each other for something, and both provide something to the other, just as in our Palm OS application and our desktop conduit.

The conduit will handle communication between the handheld and the outside world. The handheld portion of the application will do the following:

• Offer the user data viewing anytime and anywhere

• Allow the user to somewhat modify the data or arrange it differently

• Do tasks with as few taps as possible

Syncing commonly occurs between the handheld and a corresponding application on the desktop, but syncing is not limited to this model. Here are other scenarios for syncing:

• A conduit can transfer data to and from the handheld and corporate database that exists on a remote server.

• A user might fill out a search form on the handheld that the conduit would read and use to perform a web search. The search result would then be transferred back to the handheld for the user to view.

• A conduit could sync the Address Book to a web-based Personal Information Manager (PIM). Thus, while the data may reside far away, the web-based storage ensures that this information is available to a user who travels anywhere in the world.

Making the application small

The handheld portion of the application needs to take up as little space and memory as possible. There isn’t much heap space and storage to go around (this was true in 1998 when we wrote the first edition, and is still true in 2001). To end up with a good design, you must be absolutely ruthless about this. Trim the size and keep the number of tasks your handheld application performs to a bare minimum.

Later, we will talk about ways to optimize your application programmatically. For now we simply want to get your thinking clear about the tasks of the handheld application and the conduit.

Making the application fast

Handheld users measure time differently than desktop computer users. One is moving; one is sitting still. Handheld users are usually doing more than one thing—whether that is talking on the phone or walking through a store with a list. Contrast this with the desktop user who is sitting at a desk and will most likely be there for a long time.

The desktop user will wait patiently for an application to launch, in contrast to the handheld user who is on the move. If you make the handheld user wait a minute before your program is ready to use, you won’t keep that user. Speed is absolutely critical. This is true not only at application launch time but throughout its use. If you make that process too slow or require flipping through too many screens, your user will give up. The Palm is a lively little machine, so don’t bog it down with slow applications.

Always remember that there are enormous problems when attempting to do things on a handheld that you could do easily on a desktop computer. It has a pip-squeak processor with no more power than a desktop machine in the mid-1980s. As a result, you should precalculate as much as possible on the desktop. The stack space is so abysmally small that you have to be careful of recursive routines or large amounts of stack-based data. The dynamic memory is so paltry that your global variable space must be limited and large chunks of data can’t be allocated in the dynamic heap.

If that were not enough, the amount of storage space is tiny. For that reason, your desktop portion of the application needs to pay attention to which data the user really needs in this sync period. In our order entry application, we should download data only on customers whose information the salesperson is going to use in the near future. Customers who won’t be visited in this time period should be left out.

Rather than bemoaning the sparseness of your programming options, you should keep two things in mind: (1) it’s a great programming challenge to create a clean, quick handheld application under these conditions and (2) the very existence of these conditions is why Palm devices are outselling everything else around. If you design for the device instead of beating your head against the wall for what you can’t do, you’ll end up with an application that millions of people might want.

Tip

Look, you can scream all day about the slow processor and the tiny application heap, but it won’t help. (If you aren’t screaming now, you will be after you do some development or talk to a veteran Palm programmer.) We just gave you very good reasons for the processor speed and the small amount of memory. Your job is to write great applications in spite of these limitations. Anybody can write a great application with tons of processing power and vast heaps of memory. You get to do more with less.

User Interface Guidelines

The documentation that comes from Palm contains user interface (UI) guidelines. These docs cover much of what you need to know. Follow them. What the docs don’t tell you, we do. Follow our advice.

Designing your application to behave like the built-in applications can also be a good idea. For example, if you have an application that needs to display records similar to Address Book, then copy the format used in the Address application (including the location of items). Palm has provided the source code to the built-in applications because it wants to facilitate your use of them. Mimic them wherever it makes sense.

The guidelines also discuss the display of different views in your application, navigating between views, and how to convey information to the user. Not surprisingly, the guidelines also emphasize the importance of speed and optimization in your application. You should also check Palm’s web site for system updates and the release of new Palm devices.

Elements in a Palm Application

Now that you know something about designing a Palm application, let’s describe its two components. After that we will look at how they communicate with each other.

The two-part solution

Most Palm solutions are composed of a handheld application and desktop conduit:

The handheld portion

This is the portion that resides on the handheld and allows the user to view and manipulate data. Part II of this book deals with the creation of this application.

The conduit portion

Here you have code that handles syncing the data with a desktop application. Part III shows you how to create this part.

The handheld portion has an icon that is displayed in the application list. Users will usually use the Palm Install Tool from a Windows or Macintosh machine to install your application (it installs the application on the next synchronization).

HotSync Overview

When a user puts a Palm OS device in its cradle and presses the HotSync button, the handheld application begins communicating with the desktop conduit. For example, the Address Book has a built-in conduit that synchronizes the address book information on the handheld with the address book information in the Palm desktop PIM. If a new entry has been made in either place, it is copied to the other. If an entry has been modified in either place, it is copied to the other. If an entry has been deleted in one place, it is usually deleted in the other.

Third parties provide other conduits that replace the Address conduit so that the device’s address book synchronizes with other PIMs (Microsoft Outlook, for example). You’ll usually want to write a conduit for your application’s database that will upload and download information in a manner appropriate for your application.

For example, the Expense conduit reads the expense information from the handheld, fills in a spreadsheet based on the information, and then deletes the information from the handheld. From a user’s point of view, this is ideal: they get their information in the standard, easy-to-use form of a spreadsheet on the desktop. The Palm OS application doesn’t have to worry about creating reports; its only purpose is recording expense information.

If you don’t want to write your own conduit, then a backup conduit is provided. It backs up any database marked to use the backup conduit.