As this article are quite dated, most of the links will be invalid.
Twenty-six minutes and twenty seconds into episode #13 of the season one Babylon 5 episode titled “Signs and
Portents” (originally to be titled “Raiding Party” for you die-hard fans) an alien janitor walks past the screen.
While this lasted for only four seconds of screen time, it took two and a half hours to apply the makeup onto the
extra. I know this because that alien janitor is my dad (he looks a little better in person without that mask on if
you really must know). This attention to detail that the producers of Babylon 5 insisted upon is what made
series a high-quality show. Attention to detail like this is what is needed to design a quality Palm OS program.
This article is part two in a series of Palm OS program nitpicks that I have created. Some of you may think that many
of these nitpicks are trivial or trite, but attention to details like these can make your Palm OS programs rise
above the others. Increasing the quality of your programs to the finest detail will help catch the attention of
potential customers, possibly lead to more sales, and reduce technical support efforts, but they won’t help you get
a part as an extra on a science fiction television series.
User Interface Nitpicks
Do not have a close menu item. This does not make sense on the Palm platform since by switching to another
application closes your program.
Don’t have separate versions for color and black and white. If the user beams the software to someone else, it
not work. Include both the color and black and white bitmaps with the program. We are no longer in the days of
128 Kbyte PalmPilot.
Make popup list width based on the widest data element, as shown in Figure 2. This is easily done by
all of the list elements and getting the pixel width of each item, using the FntCharsWidth() function, and
the maximum value. This value, plus a padding of three pixels, should be the list width. Just make sure that it
not wider than the screen.
Don’t have screen flicker. If needed, do any screen processing in memory, and then copy it to the screen. This
the application look more professional and gives the illusion that it is faster.
If your application is doing some computationally intensive processing, let the user know that something is
happening by putting up a form such as a simple “please wait” form or a more sophisticated form with a progress
Don’t let the user think that his device has locked up.
Don’t cram too much information into one form. If need be, use multiple forms. Some applications, such as
HandyShopper and WordSmith, have excellently designed tabbed preference forms.
Make sure your alert forms use the correct icon. If a dialog is posing a question don’t have the warning icon
Don’t force your application into a particular color depth. Use the color depth that the device is set to when
entered. There may be exceptions to this rule, such as games or image viewers. If you really want to have a
depth that is not standard, give the user the option to enable or disable this.
Make sure that your application works with a 16-bit color depth. I have seen a number of applications that work
in 256 colors but fail in 16-bit color mode. 16-bit color mode is the future for the Palm OS platform so don’t
Don’t over-complicate the user interface. Figure out the simplest way of doing something, even if it means more
coding. Remember that the user does not care how hard it was to code if the program is easy to use. A computer
supposed to be a tool to make life easier for the human, not the other way around.
Make sure that your icons invert properly in black and white mode when selected in the built-in launcher. If
not, then you need to either create a black and white icon or select a different transparent color for your
Make sure your application name is not too long so that it is displayed properly in the built-in application
launcher. No one wants to see a program name in the launcher that looks like this: “TheBestSmellCh…”.
Send a “thank you” e-mail to each of your customers when a program is registered, even if no registration code
is required. This lets each user know that his hard-earned money has been received by the proper party and it
shows him that a means of communication with you is possible.
When you have an update to your program, send a notice to all your registered users so that they know of
improvements to your product.
When you e-mail someone, make sure that their e-mail address is in the “to” field of the e-mail program. Some
people filter out e-mail as spam that does not have their address in the “to” or “cc” field.
Make sure that your program works when launched from a VFS card. This is where the future of Palm computing is
going so don’t be left behind.
If your application stores or uses data on to a VFS card, make sure that you look for more than one card as
there are devices, such as the HandEra 330, that support more than one removable card.
Always verify that the removable card that you are accessing is inserted before you do any file operations.
If you have program specific data stored on a VFS device, put it into the \Palm\Programs\MyProgram directory.
Storing that data in the \Palm\Launcher directory may slow down launchers that search for files in that
Register your application creator ID at PalmSource. Failing to do so may cause
application to conflict with another and make the user very unhappy with you.
Make sure that your application works on Palm OS 5. The Palm OS 5 simulator is available from PalmSource at the
Resource Pavilion and
free to use. While most applications will work
without any modifications, there may be some minor issues that require changes to your code.
If your program only runs on a subset of Palm OS devices (i.e., requires a particular version of the OS or a
particular vendor’s device), make sure that it exits gracefully if run on a non-supported device telling the
user something useful via a form (don’t display something like “Error #0x135A”).
Don’t access user interface structures directly. There is no guarantee that these structures will remain
constant in future versions of Palm OS. If you need to, try to find a glue function that will do what you need.
Include tips for every non-trivial form. Adding a few lines of documentation in the form, also known as “tips”,
reduce technical support requirements.
In your documentation, you may have to include a picture or a screen dump to help the user understand what you
doing. This is not a problem if you use HTML for your documentation as discussed in “McNits: Mike’s Palm Programming
Nitpicks, Part 1”. Remember that a picture is worth a thousand nerds, especially if it is bigger than
(see Figure 1).