Building an Application
By the time you read this, or shortly thereafter, Satellite Forms Trial Edition version 2.0 will be available as a free download from the SoftMagic web site, http://www.softmagic.com. The Trial Edition is an excellent tool for familiarizing yourself with PalmPilot application development, prototyping PalmPilot solutions, and laying the groundwork for full-scale deployments without traditional programming.

The remainder of this article outlines how to quickly create a Satellite Forms application, using a sales order application an example. We begin by thinking about the data required by this application and constructing data tables. Based on these tables, we build screens that make up the application's user-interface, and use actions and filters to increase its navigation and data manipulation capabilities. We then enhance the application with business logic through the scripting language. Finally, we discuss connectivity to corporate databases. Figure A illustrates this process.

FIGURE A


The iterative development process provides many opportunities to solicit user feedback. Roll over picture for a larger image.

Working with Relational Databases
Like many application development tools, Satellite Forms stores data in relational database tables. End-users view and manipulate this data through a graphical user interface (GUI) consisting of a set of forms and controls. If you have experience using Microsoft Access, Oracle, Visual Basic, dBase, or other database programs, you can apply this knowledge directly to Satellite Forms. If you haven't ever worked with relational databases before, don't worry. The concepts are not difficult. Skimming the introductory chapter of a book at your local bookstore should do the trick.

Briefly, relational databases store data in objects called tables. Each table contains a specific set of data (e.g., Customers or Orders or Line Items). Tables manage data in rows and columns, similar to spreadsheets. The Orders table might contain columns for Order Number, Order Date, and Purchase Order Number. Each row, or record, of the Orders table contains information about an individual order.

Certain columns relate information from one table to another. For example, the Orders table tracks the customer who placed an order. Rather than store the customer name directly in the Orders table, we store a reference (called a foreign key) to the corresponding record of the Customers table. Doing this saves space because references are typically numbers rather than long names. It also adds flexibility. When information changes (e.g., the customer name changes), it is updated in a single place (the Customers table), and all Orders automatically reflect the updated information.