This chapter describes the application development cycle and the application development model best supported by RapidApp. It includes the following sections:
“Development Cycle” describes the typical development cycle for creating an application with RapidApp.
“Development Model” discusses the general development model supported by RapidApp.
The RapidApp application development cycle typically consists of the following steps.
Use RapidApp to create a graphical user interface for your application.
Before you build, debug, or run your application, generate the C++ code.
Add user-defined code to your application.
See “Generate Code.”
Test your application.
Use RapidApp to refine your interface based on testing and feedback.
Develop and test any external (that is, non-interface) functionality required by your application.
If you used EZ convenience functions, replace them with production code.
Perform final testing and make necessary revisions.
Create a custom Desktop icon for your application, and edit the FTR file to customize the icon's behavior.
Create a minimized window icon to represent your application when iconified.
Customize your application's installable images.
Testing an application involves compiling, running, debugging, etc. All of these tasks are accessed through the Project menu. When activated, these tasks launch Developer Magic tools, such as the Build Manager and the Debugger, which must have been previously installed. For information on these tools, see the Developer Magic: ProDev WorkShop Overview.
For example, to compile your application, choose “Build Application” from the Project menu. This launches the Developer Magic Build Manager. If you are currently using the debugger, the executable is automatically detached from the debugger and reattached when the compilation is completed.
You can configure the Makefile created by RapidApp to automatically create a static analysis fileset and database for all generated files. To do so:
The next time you build your application, RapidApp creates the static analysis files. The files are kept in a subdirectory named <DirectoryName>.cvdb, where <DirectoryName> is the name of your project directory, so they do not clutter the work area. To launch the Static Analyzer:
After creating the static analysis files, choose “Browse Source” from the Project menu.
 | Note: If you add new files outside RapidApp, you need to add them to the fileset file manually. |
Typically, applications that appear on an SGI workstation have a desktop icon which, when double-clicked, launches the application. RapidApp offers a generic desktop icon in the icon.fti file. To include an icon with your application, do the following:
Customize the generic desktop icon, using IconSmith.
See Chapter 2, “Icons” in the Indigo Magic User Interface Guidelines for guidelines and Chapter 11, “Creating Desktop Icons: An Overview,” in the Indigo Magic Desktop Integration Guide for instructions on customizing the look and behavior of your application's Desktop icons.
If necessary, modify the behavior of the icon by editing the desktop.ftr file.
If you plan to publish and distribute your application, supply a unique desktop tag.
The desktop tag lets the system know that the icon is tied to your application. (RapidApp supplies a default tag which could conflict with other applications developed through RapidApp.)
To get a desktop tag, send email to [email protected].
When the tag is returned to you, go to the Project card in the Preferences dialog and enter the tag number in the Desktop tag field.
When RapidApp generates code, it places the tag in the icon.ftr file automatically.
When the user iconifies your application, the icon should be representative of your application. RapidApp supplies a default icon in the <Application>.icon file where <Application> is the name of your application. This is an sgi.rgb image file and can be modified in any editor that handles such files.
For more information, see Chapter 3, “Windows in the Indigo Magic Environment,” in the Indigo Magic User Interface Guidelines for guidelines and Chapter 6, “Customizing Your Application's Minimized Windows,” in the Indigo Magic Desktop Integration Guide for instructions on creating minimized window icons.
RapidApp automatically generates the files required to create an image that users can install with the Software Manager installation tool (swmgr).
To generate a default image:
Go to the directory that contains your source and enter:
% make image
This creates a subdirectory named images containing the installable image. Remember to include all of the files in this directory in your distribution.
The default image created by RapidApp consists of a minimal set of application files: the executable, the default resources file, the Desktop icon, and the FTR file. You might want to customize the image to include other files, divide the product into base and optional subproducts, or include commands to be executed after installation. For example, if you have reference pages (man pages) for your product, you should edit your images to include them.
To edit your product's images:
From the Project menu, choose “Edit Installation.”
This launches Software Packager, a graphical tool for creating and editing installable images. For complete instructions for using Software Packager, consult the Software Packager User's Guide; Chapter 1, “Packaging Software for Installation: An Overview.”
RapidApp can significantly simplify the process of creating an application, not only in creating the interface for your application but also in managing the development of your application from prototype to finished product. To provide this support, RapidApp assumes a certain application development model. Although you can “go around” RapidApp and force it into a model that it isn't intended to support, you won't derive the full benefits of using RapidApp.
The key features of RapidApp's development model, which are described in following sections, are:
“Object-Oriented Components”—describes how RapidApp builds applications from object-oriented components
“Code Management”—describes how RapidApp manages automatically generated and user-generated code.
RapidApp supports the object-oriented architecture defined by the IRIS ViewKit class library. The fundamental building blocks in the IRIS ViewKit library are components, which are C++ classes that encapsulate one or more widgets and define the behavior of the overall components.
As an example, consider a simple spreadsheet. You can create a spreadsheet interface using IRIS IM text field widgets for the individual cells and an IRIS IM container widget to display the text fields in a grid. An IRIS ViewKit spreadsheet component can be a C++ class containing not only these widgets, but also the code implementing the spreadsheet functionality. In your application, you can then instantiate a spreadsheet component and interact with it by calling various member functions. If the spreadsheet component is properly designed, you can reuse it in applications needing a spreadsheet. Furthermore, you can extend the functionality of the basic spreadsheet component by creating subclasses as needed. For example, you can implement a general-purpose spreadsheet component, then create subclasses in other applications adding special financial or scientific functions.
RapidApp allows you to define a component consisting of one or more widgets. When you do this, RapidApp places in a C++ class the widgets in the component along with the callbacks and other resources for those widgets. You can specify the name of the class as well as the name of the files in which RapidApp places the code. When you create a component, RapidApp also adds it to a special “User-Defined” palette. You can select the component from this palette and add it to your interface just like any other interface element.
You can nest components, building more and more complex components from simpler elements. Ideally, you can even view your entire application as a component, allowing you to incorporate it later within a larger application or suite of applications. RapidApp encourages this approach by automatically encapsulating the entire contents of each top-level window in your application within separate classes if they aren't already components; each top-level window of your application then simply creates instances of these classes. You can just as simply instantiate these top-level classes as part of another application.
 | Tip: A good technique for developing applications in RapidApp is to create collections of small components. It's easiest to get the layouts you want by working with smaller, simpler pieces that are “frozen” as self-contained objects. Then you can use these components to construct more complex objects. |