In 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 create a new application. To do this, you first need to know what the Palm OS provides in the way of user interface elements. Second, you need a description of the elements common to every application.
From this general overview, we move to a concrete example. For this purpose, we discuss a 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 the conduit.
User Interface Elements |
The Palm OS provides you with an abundance of user interface elements. The following is a description of these elements. We also show you some common examples of each type.
Alerts
Figure 3-1 contains an example of a typical alert. It is simply a modal dialog 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 (ordered from mildest in consequence to most severe):
Information
This has an "i" icon. The alert provides to the user some information (for example, that an action can't be completed). No data loss has occurred.
Confirmation
This has a "?" icon. The alert asks the user a question, asking the user to confirm an action or to choose from possibilities.
Warning
This has a "!" icon. You are asking the user if the action is really intentional. Data loss could occur if the action is completed. The Memo Pad uses a confirmation 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 when the user chooses to delete an application, since after the delete, the application is completely gone. Figure 3-1 is a warning alert.
Error
This has a stop sign. This alert tells the user that an error occurred as a result of the last action.
Forms
A form is a general purpose container for one or more other user interface elements. A form can contain buttons, lists, tables, controls, and icons. It can also have a menubar associated with it. Forms can be anything from modal dialogs to containers for lists or tables of data. Forms can be small or fill the entire screen of the handheld.
The look of a form, including the proper placement of buttons, is covered in the Palm OS documentation. You need to scrupulously follow placement guidelines for all elements in a form. Figure 3-2 contains three different forms from the built-in applications to give you an idea of the variability they can have.
Figure 3- 2.
Three forms containing various controls
Menus, Menu Items, and Menubars
Menus, menu items, and menubars are related to one another. A menubar contains one or more menus. A menu contains one or more menu items. Menu items often have Graffiti shortcuts associated with them. Figure 3-3 contains an example of a menubar with two menus in it. One of the menus is open, and it contains six menu items (plus an additional separator bar item). We discuss these features in detail in Chapter 7, Menus.
Figure 3- 3.
A menubar with two menus; the first menu has six items (plus a separator bar)
Tables and Lists
Tables and lists are used for similar purposes. Use a table when you want to displays multiple columns of data and use lists when you need to display a single column. We discuss this further in the section "Tables" in Chapter 8, Extras. Figure 3-4 contains an example of a list on the left and a table on the right. As you can see in Figure 3-4, tables can support different types of data.
Figure 3- 4.
A list (left) and a table (right)
Miscellaneous User Interface Elements
There are a number of other user interface elements. These include buttons, checkboxes, bitmaps, fields, gadgets, labels, Graffiti shift indicators, pop-up triggers, push buttons, repeating buttons, scrollbars, and selectors. Table 3-1 contains an example and a brief description of the typical use for each item. The Palm OS documentation describes in detail the attributes of each type of object and gives you information on where each item should be placed in a form.
-Table 3- 1.
Miscellaneous User Interface Elements
General Design of a Palm Application |
Most applications will contain a certain core number of 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 dialogs as well.
When you sit down to design your application, you'll need to ask yourself the following questions and come up with some reasonable answers to them:
What tasks does the application accomplish?
Obviously, this is a question one would ask about any application on any platform. That doesn't make it any less relevant here. You need to lay out as clearly as possible what the user can do with your application, what tasks the user can perform. Just as importantly, you should have a clear idea of possible tasks that the user can't do.
The essence of the Palm OS and the handhelds is speed and accessibility. Putting a possible feature on the chopping block because it ruins either of these is something to be proud of and is terribly difficult to do in this era of "kitchen sink" applications.
What forms does the application have?
There is minimally a startup form that the user sees when tapping the application icon. Every dialog (other than an alert) or other data view is also a new form. A good rule of thumb is that you will have one form for every view of data. Forms add up fast when you count this way.
What menus does the application have?
Commonly, you will support the Record, Edit, and Option menus. They will be similar to those found in the built-in applications with the same menu items. Often custom menus are also a part of the application.
What dialog boxes does the application have?
Alert dialog boxes give information, ask questions, issue warnings, and report errors.
What is the structure of the application's database or databases?
The database is where you store information that is displayed on the handheld. You need to decide how many databases you will need, how the records are ordered, and what is stored in each record.
What versions of the OS will you support?
You need to decide what versions of the Palm OS you are targeting. As we write this, there are three versions: 1.0, 2.0, and 3.0.
A Palm study found that less than five percent of the Palm OS devices in use were running the 1.0 version of the OS. This number will only shrink as more post-1.0 OS devices are sold and users upgrade their 1.0 devices to the 3.0 OS.
Our recommendation is not to worry about compatibility with the Palm 1.0 OS. Users can upgrade to the 3.0 OS (including IR support and 2MB of memory) for around $100 at the time of this writing. A user unwilling to spend that kind of money is probably unwilling to buy your software. Of course, your particular situation may dictate that you support the 1.0 version of the OS.
Here are the major changes in the 2.0 and 3.0 operating systems:
Palm OS 2.0
Many new APIs, some changed APIs. Support for TCP/IP (on _ 1MB devices), support for scrollbars, and support for IEEE Floating Point (32-bit floats, 64-bit doubles)
Palm OS 3.0
Added support for infrared (devices include an IR port), additional sound support, additional font support, progress manager, possible unique device ID
NOTE: It's very easy to write an application that is intended to support the 1.0 OS and accidentally uses a post-1.0 call (like EvtSysEventAvail). To catch this type of error, include a header file that flags any calls to a 2.0-or-later routine. You can find this header on the CD-ROM. You can also test your applications with POSE using older ROMs. |
What does the conduit do?
If all you want to do is save the handheld data to the desktop as a backup, use the backup conduit. If the user needs to look at or edit the data on the desktop, or if the user needs to transfer data from the desktop to the handheld, then you need to design a conduit and determine what it can and can't do with data. You need to figure out what data is transferred, whether data will be uploaded, downloaded, or synchronized, and what application on the desktop the user will use to view the data.
General Optimization
There are also some important ways to optimize when designing an application:
How the Sample Applications Are Useful |
Some of you may be wondering how useful the Sales application will be to you. Does it show you how to implement all the APIs? Does it contain the essential components of most Palm applications? Here are some answers. The Sales application uses most of the Palm API (except for Category UI) and to that extent offers a broad treatment. Because it isn't an exact clone of the built-in apps, you also see some new design issues and code. It also covers 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, barcoding, serial, and TCP/IP in this manner. The bad news is that the Palm OS is so feature-rich that there are indeed some other areas we don't cover in this detail. We hope there are no glaring omissions. Our goal was not to cover every topic but only the most difficult or important ones. Our examples are created with this goal in mind. (If we goofed, let us know and we will try to correct it in the future.)
User Interface of the Sales Application |
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.
NOTE: This sample application will be used as a basis for our code discussions throughout the book. It and the source code are available on the CD-ROM. |
These are the activities we want the salesperson to be able to accomplish in the application:
The Sales Application Customer List
The user starts the application and picks a customer from a list.
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 without 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 day in and day out 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-5), the individual Customer form is opened.
-Figure 3- 5.
Picking a customer from a list
Occasionally the salesperson may want to create a new customer while out in the field, so 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-6).
Figure 3- 6.
Customer Menu in the Customer List form
New Customer
When the user selects New Customer or performs the Graffiti shortcut, the New Customer dialog you see in Figure 3-7 is shown.
Figure 3- 7.
New Customer dialog
Note that customer records can be labeled private. When a user selects this option and the preferences are set to view all records, we put up a dialog explaining why that customer is still visible (see Figure 3-8).
Figure 3- 8.
Explanation on private record checkbox
The user clearly expects something to happen when selecting the private checkbox. If preferences have been set to hide private records, the record disappears from view when the user taps OK. We put up the dialog to prevent confusion on the user's part when all records are viewable. This is a good example of explaining logical, but unexpected, results.
Beam All Customers
If the handheld has IR (infrared beaming) capabilities, this menu item provides a quick way for the salesperson to transfer all the customer information to another device. When Beam All Customers is selected, the user get the message shown in Figure 3-9. The person receiving the customers also gets status information (see Figure 3-9).
Figure 3- 9.
The status when beaming customers
If the Palm device is not IR capable, the user never sees the item in the Customer List menu. The built-in sample applications always show the Beam menu, but then tell users they can't beam on a non-IR-capable device-we like our way better.
The Customer Order Form
Once a customer is tapped on, the user is shown the individual Customer form. Most of the activity in the application happens here.
Creating an order
The most important activity is the creation of an order. This is done by selecting toys and adding them to the customer's order. Figure 3-10 shows an empty Order sheet and one that has several items in it.
Figure 3- 10.
A new order and one containing several items
Figure 3-11 shows the toys listed by category. First the user selects a category (if the current category is wrong) and then selects one of the toys in it.
Figure 3- 11.
Selecting a category and toy
Once an order is complete, the salesperson closes it and moves on to another customer. Orders can be revisited, if necessary. As there is only one order per customer, selecting that customer from the list automatically takes the user back to the order.
Ideally, a customer should be able to have more than one order associated with the customer form. In a shipping application, we would certainly add that functionality. For the purposes of this book, however, the extra programming doesn't add much new to our explanation of the Palm OS. We leave it as an additional exercise for eager readers.
Modifying an item in an order
The user can modify an item by tapping on the part of it that needs changing. If the toy is wrong, a new toy can be selected. When the item is changed, the item stock number automatically updates to reflect the new toy. If the number is wrong, that can be changed separately.
Deleting an item in an order
Deleting the item can be done in two ways. The quick way is to select Delete Item in the Record menu (see Figure 3-12). If the user failed to first select an item, we give a dialog box reminder prompting an item's selection (see Figure 3-13). Otherwise, we show the user a confirmation dialog just to make sure the delete request was valid (see Figure 3-13).
-Figure 3- 12.
Deleting from the Record Menu
Figure 3- 13.
Deleting an item from an order
It is difficult to say whether it is better to require a user to constantly confirm deletion requests or to allow the accidental deletion of items instead. Two points that drove our decision here were the smallness of the Palm screen and the real likelihood that the user would be moving when selecting items. Remember, there are only a couple of pixels of space between Delete Customer and Delete Item in the Record menu. If you give the user no warning before deleting an item, you can easily turn a mistap into a terrible mistake.
Another way to delete an item is by selecting the Details button, which brings up the Details dialog (see the right side of Figure 3-13). A deletion confirmation dialog is also shown. A third way is to set the quantity to 0, and then tap on a different row.
Changing Customer Information
To change information about a customer, the user selects Customer Details in the Record menu (see Figure 3-17). Delete Customer is used to get rid of the customer entirely. (We talk more about why this information is handled here in "Design Tradeoffs in the Sample Application," later in this chapter.)
There are two different details forms: one for the customer and one for the item. They have different user interfaces. When you follow the logic of the Palm UI, and look at the number of times a user is likely to do either of these tasks, you will understand our positioning of each of these choices.
The Customer Details
The Customer Details is the form in which you change information about the customer or, secondarily, delete the customer entirely (see Figure 3-14). This is not something we commonly expect the user to want to do. Indeed, this is information that is primarily entered and maintained on the desktop. We allow editing to give the user flexibility, not because we think this form will be edited very often. The user is more likely to look at this form to get the customer's telephone number than to change it. As access is through the Record menu, this form is difficult to get to, and it may be hard for the user to remember its location. This is okay if it allows better access for a more frequent activity. It does-to the Item Details form.
Figure 3- 14.
Customer information
The Item Details
Every customer has an detail screen associated with the order, as well. In this form, the user can do three things (from most frequent to least):
The activity most likely to occur is the deletion of an item, because the item amount or type can also be changed in the order itself (see Figure 3-15). But the salesperson can only delete an item from an order in this form. As this is a more common activity than viewing information about the customer, this form is easier to get to for the user.
Figure 3- 15.
The Item Details screen
Deleting the Customer
If the user selects the Delete Customer menu item, a confirmation dialog is shown (see Figure 3-16). A much slower way to delete an item is to select the Customer Details menu item and tap the Delete button in that form.
Figure 3- 16.
Deleting a customer
We provide the user with an option to archive the customer information on the PC, as opposed to deleting it completely from both the handheld and the PC.
Beaming the Customer
The user of an IR-capable device can also beam information about a single user. Selecting the menu item Beam Customer takes care of this. We make sure that non-IR-capable devices don't show the item in the menu (see Figure 3-17 for a comparison).
Figure 3- 17.
The Record menu with beam present and not present
Edit and Options Menus
Last, but not least, we offer Edit and Options menus in our application with the standard Graffiti shortcuts (see Figure 3-18).
Figure 3- 18.
Sales application Edit and Options menus
Developing a Prototype |
Now that we've shown you the application in its final form, let's back up and show you the process and decisions we made to get there. First, let's look at how we prototyped it.
Clarify the Flow of Events
Our prototype design was a mock-up of the basic views that we wanted to have in the application. We came up with those views by listing the actions we wanted the user to be able to do and the order in which we thought they would occur; we discussed the flow of events. Our strategy was to optimize the application so that the more frequent the action the fewer steps it took to complete. We also wanted to emulate the design of the built-in applications wherever possible.
The Start Screen
The first and most important view to create well is the start screen-what your user sees when the application is launched. In the Sales application, the place to start seemed straightforward-with a list of the salesperson's customers. This is a list that can be modified on the handheld, but ordinarily would be created on the desktop. The desktop application should be clever about culling customers from the list if the salesperson isn't visiting them on this trip. It might also want to order the customers either alphabetically or by visit (as the salesperson prefers).
Design Tradeoffs in the Sample Application |
As with any design, we made some modifications that changed the look and functionality of this application. We think it will be useful to you to explain how we meandered about with these decisions.
Adding Items to an Order
There are a couple of things to notice about the design that we ended up with for this action (see Figure 3-19). When the user taps on the customer name, an order form immediately presents itself. As this is the most common action, we focused on minimizing the steps necessary to complete it. In our final design, we managed to reduce the number of steps required to take an order by one. Look at two possible designs in Figure 3-19, and you will see where we saved a step. The example on the left requires the user to first select the customer name and then tap the New Order button below the list (two actions). The example on the right brings the order forward with one less action.
Figure 3- 19.
Two ways to design the selection of a new order
The tradeoff here affects two things. We can make an order easier to create (our solution) or make customers easier to create and edit. For us the choice is obvious; we assume that the salesperson rarely adds new customers or modifies old ones. This is the standard list of customers that our user always deals with when selling toys. In a world where customers came and went more often, we might have chosen differently.
Where to Put Customer Information
The next design issue we tackled was how the user accesses, modifies, and deletes customer information. Menu items or buttons could go either in the startup screen or in the order form. Both choices carry their own set of advantages and disadvantages. Before showing you the logic of our choices, back up and look again at what we want the user of the Palm device to be able to do:
In a desktop application, we are certain that all of these activities would be put in the same menu. On the handheld, we weren't so sure they should be kept together. After some consideration, we chose to put creating a new customer and beaming a customer list in the startup view, because these are the only two general customer items. Every other action has to do with a particular customer, whether that is creating an order, changing the customer's information, or deleting the information from the unit.
Creating a new customer
Clearly, the time when a user is going to create a new customer is in the startup screen while looking at the list of customers. The right user interface for this is a menu item, not a button. This is an infrequent action, so we don't want to waste valuable screen real estate with a button for it. In our solution, getting to the New Customer form takes two actions: pressing the built-in Menu button and selecting New Customer from the Customer menu.
Beaming a list of customers
Our users might share customers with each other; we wanted to give them an easy way of sending customer information to each other (we chose not to support beaming orders, though). The menu item was our way of doing this. It takes two steps to accomplish this task. The user first pushes the built-in Menu button and then selects the item from the Customer menu.
Deleting a customer
You could place this item in the startup Customer List form or in the Customer form. If you put it in the menu of the startup Customer List form, as we did in an earlier version of this application, you need a way for the user to select which customer to delete. The user selects Delete Customer from the Customer menu and a picklist is brought forth from which customers can be deleted one at a time or in group (see Figure 3-20).
Figure 3- 20.
One way to delete customers
However, there's a faster way that requires fewer taps (and no new picklists). Within the Palm user interface model, you delete an item while you are viewing it. Look at the built-in Names and Memos applications (see Figure 3-21). Notice that you start with a list of items and select one. Only at this point can you use a Record menu item to delete the name or memo you are viewing.
Figure 3- 21.
How the built-in Names and Memos applications handle actions
Likewise, in our application the customer is selected from a list and then, while viewing the customer form, the user can delete that client.
A desktop application would not be designed this way. Single-clicking on a customer from the list would select it. At that point, the Delete menu item would delete it, while the Open menu item (or, as a shortcut, a double-click) would open the Order form for the customer. However, the Palm OS is not a desktop OS. Double-taps aren't part of the idiom. Users of a Palm OS device expect a single tap to make an action occur.
You might ask why this model has been adopted. The design makes sense when you realize that the initial items in the startup list are "hot." If you touch them, something happens immediately to switch you to another form. The Palm OS does not have a tap, double-tap model. The Palm model is attractive because it cuts down on the number of steps required to complete the most common actions. Each of these very common actions takes a smaller number of steps because picklist items are hot:
Designing for a Small Screen |
One of the biggest challenges you face as a handheld application designer is how to fit data in the screen space on a Palm device. In the Sales application, this challenge happens when we are trying to figure out the right way to select a toy. We assume that there are more toys than would fit on one list on the screen. One approach might have been to have one long scrolling list-the least favorable solution. Toys, like many other types of items, naturally fall into obvious groups. We chose to take advantage of this by first putting the toys into categories.
Table 3-2 contains three ways that we could have organized the items. Our solution was to go with a category organization. This makes things like special sales promotional items easy to handle. A fast-food restaurant might use a similar approach for taking orders. In both cases, the customer is going to go through categories in certain obvious groupings.
Organizing things alphabetically is another possibility, but one that doesn't make as much sense for our application. Neither the customer nor the salesperson is likely to think about the toys in this way.
Organizing the items by number might have been a good choice from the salesperson's point of view. It is not uncommon to memorize part numbers of items you work with all the time; however, where this organization strategy breaks down is from the customer's point of view. The customer is not necessarily going to request items by number. We imagine the customer thinks in terms of the store's shelves which are themselves organized by category. Our strategy is to match the customer's organizational model. Doing so minimizes the number of steps required to add an item to the order (less category switching).
-Table 3- 2.
Ways of Categorizing Toys
By Category |
Alphabetically |
By Item Number |
Games |
A - C |
00199 |
· Acquire · Mousetrap · Monsterwalk · Siege Towers |
Absolute Terror Tim Acquire Aardvark Arnie Chubby Bunny |
1Aardvark Arnie 2Jane Sit and Spit 3Pretty Patty 4Zebra with baby |
Dolls |
D - H |
100199 |
· Aardvark Arnie · Jane, Sit and Spit · Zebra with baby |
Glow in the Dark Pumpkin Halloween-Princess Happy Bunny PlayAlong |
101Marbles by the 100s 102Ball and Jacks 104Glowing Glop |
Action Figures |
I - P |
200299 |
· Absolute Terror Tim · Chubby Bunny · Daredevil Dan · Sissy Sunny |
Jane, Sit and Spit Monsterwalk Mousetrap Pretty Patty |
200Siege Towers 201Acquire 202Moustrap 203Monsterwalk |
Promotional |
Q - Z |
900999 |
Siege Towers Sissy Sunny Zooming Eyes |
900Glow in the Dark Pumpkin 901Halloween-Princess 903Happy Bunny PlayAlong |
Designing the Databases |
Once you have figured out how to organize the data, your next big decision is to determine the number of databases you should use. We settled on four databases in the Sales application; they are customers, products, orders, and categories.
Customers
The customer database contains the information about the customers. Each customer record contains five items:
Customer ID
A unique customer code assigned at corporate headquarters. If a new customer is created on the handheld, it is assigned a temporary negative customer ID. Corporate headquarters is responsible for assigning a permanent ID after a HotSync.
Name
A string.
Address
A string.
City
A string.
Phone
A string.
The order in the database is the order in which they are displayed in the list. New customers are added at the beginning. There are at least two possible ways to reasonably organize the customer database-alphabetically or by visit order (the first name is the first customer the salesperson visits, the second name is the second visit, and so on).
Products
The product database contains information about each of the toys that can be ordered by the customer. Each product record contains:
Product ID
An integer. This is assigned by corporate headquarters.
Price
A number. This is a cent amount that we can store as an integer rather than as a floating point number.
Name
A string.
Category number
A number. The value is from 0 to 15 and is stored as an index into the category database.
Instead of storing the category number as a separate piece of data directly in the record, we use the category feature of the database manager to store it (see Chapter 6, Databases). Doing so saves a small amount of space and gives us a pedagogical excuse to discuss this feature of databases.
Orders
The order database contains records for each of the salesperson's orders. The order database does not contain records for customers with no orders. Each order record contains:
Customer ID
In order to match a customer to an order, each order contains the customer ID.
Number items ordered
An integer. This is the quantity of each item that was ordered.
Items
An array of items where each item contains a product ID and a quantity.
We considered having the customer's order be part of the customer database, but decided to separate them as a precursor to providing multiple orders for each customer in the future.
Categories
There's a Category UI that we don't implement in the Sales application. It is inappropriate to our application because it is a mechanism for allowing the storing of editable category names. The Category UI has folders at the top-right and items are stored within these categories. The Category UI also provides a mechanism for editing the category names. This is the feature we wish to restrict in our application-products come from the desktop and are unchangeable.
We didn't want to hardcode the category names into the application, either, as product lists have been known to change on occasion. We chose instead to store the information in the application info block of the products database (see "Creating the Application Info Block in a Database" on page 144). This way we can modify it during a HotSync.
The categories are stored sequentially as null-terminated strings. The order of the categories matches the category numbers used in the products database-record 0 of this database contains the name of category 0. For example, if we want to know the name of category 4, we go to the fourth null-terminated string in the app info block.
Designing the Conduit |
A conduit is a desktop application made in a desktop development environment. It uses HotSync synchronization to connect the desktop to the handheld; conduits are responsible for the transfer of data to and from the handheld and the desktop. The user views the data using some application (a spreadsheet, for example, for viewing expense report items). The conduit needs to make sure that this desktop application has the data it needs to handle processor-intensive tasks. Before looking at the design of the Sales application conduit, let's examine this issue of off-loading processor-intensive tasks.
Processor-Intensive Tasks
Using the conduit to transfer the data, move processor-intensive tasks onto the PC and off of the handheld. If you can't move tasks, you should almost always get rid of them.
Palm devices are noted for being both fast and cheap-two of the key features that have made them so popular. One of the reasons they are cheap is they have little bitty processors that don't have much horsepower. Your job as a good application designer is to avoid taxing the handheld's processing abilities. Don't turn it into a slow device-there are already plenty of those around. This means that you may end up making design decisions about your database that don't make sense from a desktop database designer's point of view, but do make sense when you take into account the desktop's superior processing abilities. Here is an example.
Recently, we were involved in porting an application from another handheld platform (with a fast processor) to the Palm platform. This is an application that keeps track of a bunch of vending machines: when they need filling, what products go in what slots, how much money is collected, and so on. The account screen provides a summary of the machines that belong in that account (an account could have many machines or just a few). The machine screen provides a summary of items for that particular machine. In the original platform, as we entered an account screen at runtime, we'd run through the database, summarizing and totalling (for instance, we'd total how many machines needed to be serviced for an account, along with how many total machines an account had).
When we began our port of the application to the Palm platform, this way of handling the task no longer made sense. The hit the user would endure when opening a machine or account screen was too long. So we bit the bullet and moved the summarizing and totalling to the desktop application. This information is now stored in the account database. The price we had to pay is duplicate data in every account (upping by a small amount the size of our databases). It was worth it, however, to have a zippy account screen that instantly displays information about machines.
The built-in Expense application provides another useful example. Let's approach the issue from the point of view of a question.
Q: What feature is missing from the Expense application?
A: There is no expense total.
Why? you might ask. We think it is to avoid an unnecessary processing task that doesn't really provide the user with necessary information. Totals are things a user will care about back at the office when sitting calmly at a desktop computer, not when she or he is rushing from a cab through an airport to catch a flight.
The moral of the story is not to make users pay for processor-intensive tasks if there is any way to avoid it. Sometimes that means keeping functionality but moving the processing elsewhere (as in our ported vending machine application); sometimes that means not offering a feature in the first place (as in the Expense application with no total).
Design of the Sales Application Conduit
Our Sales application conduit handles the following tasks during a HotSync synchronization:
The conduit also needs to be installed and uninstalled. With a commercial application, this process should be handled automatically, invisible from the user.
Design Summary |
By now, you should have a good feel for how to design a Palm application and conduit. You also know about the range and types of tools available to help you with this project. You should also have a good feeling for what types of applications will work well on a Palm device and the types of user interface elements you can easily add to them. Now it is time to turn away from design issues and to the code you need to write to create your application.