 Contents |
 Index |
|
|
|
|
With both Forms Developer and Reports Developer, deploying a single application on multiple platforms--Windows, Motif, the Web, even character-mode--is simply a matter of re-compiling. Both Forms Developer and Reports Developer automatically translate the standard control objects (buttons, check boxes, radio buttons, and so on) to the appropriate format for your target platforms. With careful pre-development planning, you can create a single application that satisfies users across environments, providing each with the native look and feel they expect.
This chapter helps you anticipate the issues you will face when developing portable applications and provides suggestions for ensuring that you can move your application across platforms with ease
If you're using Project Builder to manage your application, see Section 1.2.4, "Managing projects and project documents across multiple platforms" in Chapter 1.
Before you begin designing any application--not just those you intend to port--it's important that you take time to think about the needs you are trying to address with your application. At a minimum, you should have answers to the following questions:
Whether you're designing a new form for multiple platforms or preparing an existing form for a new environment, the issues you face fall into the same two key areas, described in the following sections:
If you've never developed for multiple platforms before, you may also wish to read Section 5.2.3, "Strategies for developing cross-platform forms" for some recommendations on how to approach cross-platform development. If you're developing for character-mode, see Section 5.2.4, "Designing forms for character-mode" for considerations unique to that environment.
When developing a portable application, the first thing you must decide is whether the GUI should look the same across all platforms, or if your users expect the application to inherit the native look-and-feel of their own environment. In most cases, you'll probably opt for the latter approach. However, if users are likely to use the application on multiple platforms, they'll probably want it to look the same on all of them, ignoring local conventions. The only way to determine this is to interview your users, paying close attention to how they work and which tasks they're trying to perform. (See Section 2.1.2, "Defining user requirements" for suggestions on how to determine users' needs.)
Once you've made your decision, the next step is to create an object library for each platform you're supporting. An object library is a set of objects and standards that you create; each object or standard can determine the appearance and layout of an entire frame, window, or region. When housed in an object library, these objects become available to all the developers on your project or site, thus ensuring that even developers working at different locations can produce an application--or different modules within the same application--with a common look and feel.
To fully exploit the power of the object library, it's a good idea to create one library for each of your target platforms. To help you populate your libraries, Form Builder provides the Oracle Applications Object Library, a set of layouts and items that function well in all of Forms Developer's GUI deployment environments (Windows 95, Motif), as well as character-mode. Test these items and objects one by one on each of your platforms. You should be able to add most of the objects to your libraries without modification, although some may need slight adjustment to meet platform-specific requirements.
Section 5.2.3, "Strategies for developing cross-platform forms" provides more details on how to incorporate your object libraries into an overall development strategy.
For GUI terminals, use the Real Inch, Real Centimeter, or Real Point coordinate systems. These systems allows you to size your objects to the exact shape you want instead of being snapped to the nearest character cell size.
If you're designing for character-mode, use the Character coordinate system and turn on the grid snap. This will ensure that your objects' sizes are in multiples of the character cell size. See Section 5.2.4, "Designing forms for character-mode" for more information on designing character-mode applications.
Even on the same platform, monitors of different sizes and resolutions can greatly impact the usability of your application. For example, while a 6 pt. font on a laptop running Windows 95 is unreadable, the same font on a 17-inch monitor is perfectly acceptable. The only way to be certain your application is truly portable is to thoroughly test your application on each of the monitors in the deployment environment.
If there are several different sized monitors in your deployment environment, design for the smallest size. Taking the time to find out which monitors your users have--and how many use each size--can help you plan your application more effectively. For example, if your mobile sales force uses laptops for lead tracking and sales management applications, but everyone else uses 17-inch SVGA terminals, you can simplify your task by restricting the window size of only the two critical laptop applications.
Restrain your use of color to three or four basic colors that work well together. Colors that are typically available on many platforms include blue, red, magenta, cyan, green and yellow.
Using too many colors can exceed the system's maximum color limit and cause background objects to snap to strange colors, leaving only the foreground color intact. Be sure to test your color combination on all target systems, including monochrome, gray-scale monitors, to make sure they work as expected.
Fonts play a fundamental role in the user's sense of familiarity and comfort with a GUI system. Table 5-3 lists the recommended font for each GUI platform:
| Platform | Font |
|---|---|
|
Windows |
MS Sans Serif |
|
Motif |
Helvetica |
When developing a portable application, decide early how you'll use font styles such as boldface, italics, and underlining. (In general, you shouldn't need either underlining or italics; use boldface sparingly, and only for emphasis.) You should also standardize the type size of different display objects. For example, making all labels 10 points will help if you need to translate a font on a different platform.
To meet users' expectations, a ported application must be rendered in the expected font on each platform. To achieve this, you must translate the fonts between platforms using either of these methods:
The next two sections briefly outline these processes.
Note: On Motif, each different size of a given font is considered a separate entity that must be explicitly installed from the font file. For example, suppose you want to port a Windows-based form containing 10, 12, and 28 point Arial fonts to Motif. Rather than simply verifying that Arial has been installed on Motif, you must ensure that each of the desired point sizes--10, 12, and 28--have been installed as well. If Forms Developer can't find the font it needs on the target platform, it substitutes another font using a platform-specific "closest match" algorithm.
Forms Developer provides a font alias file for each platform (UIFONT.ALI,in the ORACLEHOME\TOOLS\COMMON60 directory). In most cases, the file ensures that fonts appear consistently across platforms. However, if you employ custom or non-standard fonts in your applications, some of them may not be recognized on all target platforms. You can tailor the font alias file to define substitutions for the fonts that are not recognized.
Enter each line in the file in this format:
source_font = destination_font
For each font, you can specify these attributes:
<face>.<size>.<style>.<weight>.<width>.<character_set>
Example:
When porting from MS Windows to Motif, change all MS Sans Serif fonts to Helvetica:
"MS Sans Serif"=Helvetica
See the Form Builder online help for more information and examples of font mapping.
When you require greater control over your font aliasing, use classes. For example, suppose you want your poplists and text items to have different fonts on Motif, rather than just imposing a strict conversion of MS Sans Serif to Helvetica. To achieve this:
This approach allows you to customize the font used for each class of objects in your application, thus providing a higher level of flexibility.
Icons are platform-specific. If you use iconic buttons in your application, create a separate icon directory for each platform. Use the same names for the icons on each platform and set the respective environment variable to point to the icon directory. On MS Windows and Motif, this variable is TK25_ICON.
If you include icons in your application, keep the following in mind:
In MS Windows, a button's moat (the emphatic border around a button to designate a default) is very small compared to that on Motif. Therefore, buttons appear to shrink when run on Motif. On Motif, you can avoid this by modifying the Motif resource file, Tk2Motif in ORACLE_HOME/BIN. (Oracle uses Motif resource files to control the visual appearance of UNIX-based applications.)
In general, always provide enough space in your Windows buttons to accommodate the larger button size in Motif.
To maximize portability, make all buttons non-navigable. In Windows and Motif, clicking a button means the user actually navigates to the button. Because triggers are often dependent upon button navigation, this difference across platforms can create significant behavioral differences in your application.
Note: Making Windows and Motif buttons non-navigable is an excellent example of the kind of trade-off you might have to make if consistency across platforms is more important than adhering to standard platform behavior.
The placement and behavior of menus varies across platforms, as shown in Table 5-4:
If you are using a version of Windows that supports MDI and you want your applications to look the same across all platforms, specify in Motif that you do not want to repeat the parent window menu on child windows. Then you can design the parent window menu to look exactly like that on MS Windows.
Note: To prevent the screen from flashing when switching between form module windows, combine all the menu options into one single menu application and use the SET_MENU_ITEM_PROPERTY built-in to dynamically enable/disable the respective menu items accordingly.
Like menus, the placement and behavior of the console also varies across platforms, as shown in Table 5-5:
| Platform | Console Restrictions |
|---|---|
|
Windows |
Appears at the bottom of the MDI window only. |
|
Motif |
Appears on the user-specified window. |
To achieve consistency across platforms, place the console on the parent window in your Motif application to emulate the behavior of MDI Windows applications.
Refer to "Reusable Components" (under Forms Developer Demos) in the Form Builder online help for more information.
| Platform | General Restrictions |
|---|---|
|
Windows |
A known positioning problem causes two lines forming a right angle on VGA screens to actually overlap on SVGA. Use bevels to avoid this problem. |
|
Motif |
(none) |
No application is truly portable if it depends on functionality unique to a particular operating system. Here are some general rules to keep in mind:
Suppose you need to read an image file called OPEN.BMP from your form. In a Windows-only application, you could simply code the path name in the call to READ_IMAGE_FILE:
Read_Image_File(`c:\orawin95\myapp\open.bmp', `BMP', `block1.image3');
If you want the application to be portable, however, hardcoding won't work, since the name of the path is different on each platform. Instead, you can use an external variable to represent the path name.
For example, in Windows95 or WindowsNT:
path_var varchar2(255); ... Tool_env.getvar(`MYPATH', path_var); Read_Image_File(path_var||'open.bmp', `BMP','block1.image3')'
The platform-specific path name, represented by the variable path_var, is appended to the name of the image file, OPEN.BMP. On Window95, path_var resolves to the path name C:\ORAWIN95\MYAPP\. On UNIX, path_var is something like /oracle_home/myapp/.
Section 5.2.3, "Strategies for developing cross-platform forms" explains how this handling of procedure libraries fits into the recommended development strategy for portable applications.
The component is built using Form Builder and PL/SQL native capabilities, so it is portable to all Forms-supported platforms. Because the help text you create is stored in the database, it is accessible to all users, and updates are immediately available to everyone.
To use the Online Help Class in your application:
Refer to the help topic About the Online Help Class" under Forms Developer Demos in the Form Builder online help for step-by-step instructions.
| Platform | Method |
|---|---|
|
Windows |
|
|
Motif |
Calls to loadable libraries (ORA_FFI) |
These objects leave placeholders (empty spaces) on the platforms that do not support them. If you must include these objects in your application, see Section 5.2.3.4, "Hiding objects" for information on how to prevent the placeholders from appearing.
A user exit is a 3GL program you write yourself and then link into a form at compile time. User exits are always port-specific.
Before calling a 3GL program from your portable form, verify that the information and processes on which the program relies are available on all platforms. For example, a program that depends on information from the Windows registry can't access this information on other platforms, which means you may have to re-design the program or abandon it entirely.
Rather than accessing a 3GL program through the user interface exit, consider the use of the ORA_FFI built-in package (Oracle Foreign Function Interface). If you use the user exit interface to access your foreign functions, you must re-link the user exits or replace the DLL for each platform each time a 3GL program changes. Because ORA_FFI allows you to call foreign functions through a PL/SQL interface using PL/SQL language conventions, re-linking isn't required when you modify a program. For this reason, ORA_FFI is the preferred method for accessing 3GL programs from your forms.
This section introduces some techniques you can use to develop portable forms:
While it may be tempting to consider creating a single source that aims at the lowest common denominator for all deployment platforms, this strategy severely limits the aesthetics you can provide in your application. A more effective strategy is to create a single source that delivers applications in each platform's native look-and-feel. The architecture depicted in illustrates how you might accomplish this:
To model your application on this architecture:
Visual attributes are the font, color, and pattern properties you set for form and menu objects. By carefully defining the visual attributes of your form objects, you can ensure that users on each platform enjoy the native look-and-feel unique to that environment.
Many Form Builder objects, such as items and canvases, refer to visual attributes to define their appearance. Visual attributes must be defined in the same module as the object that refers to them.
Visual attributes are usually stored in an object library. It's a good idea to create subclasses of these visual attributes in each module. When you subclass an object from an object library in your form, any changes made to the library object are automatically applied to the form object. However, this does not apply to changes made to the library object's visual attributes. So, by subclassing, rather than coping the visual attributes, you ensure that your modules always reflect the latest definition of the visual attributes.
The GET_APPLICATION_PROPERTY built-in function returns information about your application, allowing you to react dynamically at runtime based on the settings of one or more of these variables:
Depending on the value of a variable, you can dynamically hide objects that are not available on that deployment platform, reposition other objects to take up that space and, if necessary, alter the attributes of an object to suit the standards on that deployment platform. See Section 5.2.3.4, "Hiding objects" for more information.
To prevent users from seeing placeholders on platforms that do not support OLE, VBX, and ActiveX objects, you can put these objects in a separate window invoked from the menu or a button and dynamically enable/disable the menu item or button. Or you can use this code fragment to hide/show the port-specific objects and reposition other objects to take their place:
WHEN-NEW-FORM-INSTANCE trigger: declare ui varchar2(15) ; begin ui := get_application_property (user_interface); if ui = `CHARMODE' or ui = `MOTIF' then set_item_property (`VBXOBJECT1', displayed, property_false); set_item_property (`OLEOBJECT1', displayed, property_false); set_item_property (`TEXTITEM1', position, 43, 4); end if; end;
Note: Item prompts are automatically hidden when you hide the associated item.
If you are creating an application for both character-mode and bit-mapped environments, single-sourcing is probably not the best approach. Developing for the lowest common denominator, character-mode, deprives your GUI users of the ease of use associated with bit-mapped controls. The "Bit-map Only" column in Table 5-8 lists the functions you'd have to avoid:
| Character Mode | Bit-map Only |
|---|---|
While there are methods for disabling these GUI functions in a character-mode environment, this task can be extremely time-consuming and frustrating for you. So, if you know from the beginning that you have to support these two widely disparate sets of users, it's best for everyone--you and your users--to simply create two entirely separate applications.
It's much easier to develop for character-mode if you make Form Builder look like character-mode as much as possible. Table 5-9 lists some recommended property settings:
| Property | Recommendations/Notes |
|---|---|
|
Boilerplate font |
|
|
Coordinate information |
|
|
View |
|
|
View'Settings'RulerView->Settings->Ruler |
|
1
Improves portability of the form from character-mode to bit-mapped environments. If the form will be deployed in character-mode only, use the Character coordinate system. |
As you develop your application strictly for character-mode, keep the following in mind:
When preparing a report to run on multiple platforms, consider the following:
Note: Because screen font and printer font metrics are not always the same, your printed report may not look the same as it did on the screen. In particular, text fields can expand on the printed page, causing adjacent fields to shift and possibly creating new and unpredictable page breaks. To avoid this, use expand-only fields and be sure each field is large enough to accommodate the largest font reasonably possible.
Character-mode reports are often needed in environments where users need to send their report output to bulletin boards, spreadsheets, dump files, or to character-only printers. Character-mode output also provides a number of advantages:
Reports built for bit-mapped environments cannot easily be adapted to character-mode. If you know you will need to run a report in a character-mode environment, it is best to build the report as a character-mode report. However, if you must convert a bit-mapped report to character mode, refer to the Report Builder online help, index entry: ASCII report, creating. You will also find step-by-step instructions there for building a character-mode report.
If you have standalone graphics--graphics that are not part of a container application such as a form or report--porting is fairly straightforward. Most graphics, however, are embedded within forms and reports, which can introduce problems when moving across platforms. When developing graphics for multiple environments, observe the following guidelines:
|
 Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|