Cross Platform Considerations

Suggestions for Cross-Platform Development of Oracle Power Objects Applications.

Preamble

Oracle Power Objects is effective in supporting cross-platform development and deployment. At the same time, because OPO uses native controls on each platform, it would be naive to expect that no effort is necessary to deploy applications across platforms which are attractive and appear nativized to each platform's interface style. In this article I lay out a model to understand crossplatform needs, a strategy to employ in development and a number of interface issues to consider. As will be illustrated, a very small amount of thoughtfulness and planning during development will render the actual porting task relatively trivial.

Understanding Crossplatform Needs

Many organizations are composed of mixed-platform networks. Applications must often be used by individuals with different platforms. When preparing for development, the first issue to consider is what the crossplatform needs for the project will be. Typically one of the following scenarios broadly covers any situation:

A user base more or less evenly divided between platforms.
A predominant user base for one platform with an important group of users who use a second platform.

The first scenario occurs in a variety of cases such as vertical market applications for industries which do not have a pronounced preference toward a given platform. It also occurs in some organizations which have been forced by software availability or been allowed by lack of purchasing standards to grow into an organization with highly fragmented platform acquisition.

The second scenario is seen in two common directions. Often, executives and upper management may use the Macintosh because they were not restricted by cost and prefer the increased work efficiency they get from the Macintosh. Another common scenario is in advertising or design agencies in which users predominately use Macintosh, but accounting tends to use Intel PCs, because of the wider availability of accounting software.

These two examples underscore key differences to remember: even if the number of users who need support by a second platform is small, their political and functional importance or will influence the manner in which the application must be portable. For the case of executives, maybe only the decision support component of the application must be tweaked for cross-platform usage. For accounting, maybe only cross-platform data export or reporting is needed. It is worthwhile to know if only 10% of the application must be cross-platform or if it must be 100% portable.

Cross-platform development begins with strategy

For projects which demand the most consideration to supporting multiple platforms and doing so through a complete lifecycle of development, the following strategies are suggested. Although taking slightly more time at the outset of devlopment, these techniques offer the best appearance on each platform, as well as great savings in code maintenance throughout the release cycle.

The first technique is to develop all forms as classes initially, and build the logic into objects on the class and methods of the class, and then instantiate the class on a form, one form per platform. Then all the objects can be appropriately tweaked on the form to look good on the target platform, but the underlying logic need be changed only on the class.

Secondly, if calls to native machine code are necessary, such as polling to see if the MouseButton is still held down, or to move a file from one directory to another, the preferred way to handle this would be to use a wrapper method, adding such wrappers to either class methods, or as user-defined methods of an application. The wrappers themselves simply consist of a branch based on what operating system the application is executing under. The code in each branch of the "if" statement is specific to the operating system.

Combining these two techniques will result

Specific Interface Differences

Having described the best strategy with which to develop your applications for cross-platform deployment, it is critical to discuss some more specific issues relevant to the correct implementation of cross-platform applications. Use this knowledge either to correctly tweak the platform-differentiated instances of classes or to develop applications that are reasonably appealing on either platform.

Menus

All Macintosh applications have an Apple menu, which is the first menu on the left of the menu bar. To accomodate this, either limit your applications to using the system or application menus and appending to them, or use a conditional structure to set up the Apple Menu. To set up the menu, all you really need is:

   If (gMac) then

          mnuApple = NEW Menu

          mnuApple.Label = CHR(20) 'In the Chicago font, this is an Apple

          mnuApple.AppendMenuItem("About MyApp...",kCmdAbout,0,"")

          mbrMain.AppendMenu(mnuApple) 'Assuming empty menubar

        End if

The reason this works is that the Macintosh OS traps for the ASCII 20 and appends the Apple Menu Items to whatever menu has the Apple character as its title.

The other main differences for menus relate to menu item naming conventions and keyboard equivalents on each platform. Under Windows, the menu item "Exit" is used to terminate an application, while on the Macintosh, the correct terminology is "Quit." If one is unfamiliar with naming conventions or standard keyboard shortcuts on either platform, it would be a wise investment to spend a small amount of time examining the names and shortcuts used by a half-dozen major applications on the relevant platforms.

Fonts

Without question, the issue of fonts and font mapping is quite serious for OPO, whether going from Macintosh to Windows or the reverse. There is no ideal way to handle this issue without actually setting up and using specific fonts on each platform, and resizing the containers in such a way as to look attractive. Of course, this is one very strong reason to use the class instantiation strategy described earlier. If you choose not to take this approach for whatever reason, at least follow these suggestions for a reasonably good appearance.

Never set the font property to "System Font" or "Application Font" without a good deal of thought. On the Macintosh, for example, the System face, Chicago, looks horrible if anything other than 12 point and plain. And the Macintosh Application face, Geneva, is not particularly attractive in anything larger than 9 points (opinion only). Font metric differences also create serious problems when using these options.
Because of size differences between Macintosh and Windows fonts, text in fields on the Macintosh will appear too small for the field which contains it. This is accentuated if the vertical justification is set to top or bottom. For the present time, designing the text areas to be large enough to accomodate the Windows fonts and setting the TextJustVert property to Center is probably the best way to handle it.
In our experience, the best typeface to use for cross-platform work is Helvetica. Helvetica Bold makes for very good titles and labels, and Helvetica itself is a very readable data entry font.

Popup Lists/Popup Menus

Under the Macintosh OS, the label of a popup list is part of the control, such that clicking on the label will popup the list of items. This is not the behavior under Windows. Because both versions of OPO respect the native controls of the target platform, this issue must be accomodated by the developer. To ease cross-platform deployment, use the lowest common denominator and set the label to null, and place any sort of a label to the left of the popup list as a static text object.

Windows

Because resizable Macintosh windows have a "grow box" in the lower-right corner of the window which is used to resize the window, placing any controls within sixteen pixels from the right or bottom of this corner means that the control will cover or be covered by the grow box. There are two options for dealing with this situation:

Consider using fixed-size windows or movable-modal dialogs, if applicable. Given that OPO doesn't support screen geometry, there is typically little need for resizable windows.
Set controls at least sixteen pixels in from this corner. Empty space around the edges of windows is typically better looking as well.

Scrollbars

Standard Macintosh scrollbars are 16 pixels thick, and deviations from this size are to be avoided. The arrow is a bitmap which is scaled to fit in the given space. Because of the bitmap scaling, scrollbars thicker or thinner than sixteen pixels tend to look poor on the Macintosh.

In those cases in which a small scrollbar is necessary, a ten-pixel thick scroller can be used on the Macintosh and look acceptable. This would be the prefered thickness if one needed to create a spinner-style control in OPO.

Bitmaps

The Macintosh does not natively support Windows bitmaps (.BMP). Although OPO automatically displays bitmaps on the Macintosh correctly, developers on the Macintosh are often confused as to how to get a picture which they produced on the Mac into OPO. The best solution is to use a graphics converter, there are several commercial, shareware and freeware tools available.

File and Pathnames

There are some obvious differences between the Macintosh and DOS/Windows filesystems. Take these issues into consideration whenever a routine will be creating files and directories programmatically.

The path delimiter under DOS is the backslash "\" while on the Macintosh it is the colon ":". One possible way in which to handle this issue is by use of a global variable, which is at application startup set to
Macintosh filenames must not begin with a period "."
Windows 3.x filenames must follow the 8.3 naming restriction...
...however, it is typically considered poor form to use filename extensions on the Macintosh, so a conditional statement for file naming may be desirable, but is probably only needed for developers seeking to deliver the most polished applications.

All Controls

Methods Involving Focus: FocusLeaving(), FocusEntering()
On the Macintosh controls such as buttons, popup lists, lists, radio buttons and checkboxes do not actually get focus, so code attached to FocusEntering() and FocusLeaving() will not be executed on the Macintosh. Best to avoid putting code in those methods for such objects. Actually, given that FocusLeaving() gets triggered in ways which many developers find confusing, it may be wise to avoid using these methods altogether.

All Objects

If you design in inches, screen objects will be about 3/4 of the size if going from Windows to Macintosh, because of the Macintosh's true WYSIWYG interface, compared to Windows' approximate WYSIWYG implementation. The solution is to design in pixels. This means that when designing forms, you should select all the contents of the form, and type "pts." This will convert all the selected objects to scale in points, as opposed to inches. At the same time, designing in pixels, while an improvement in some ways, has some side effects such as forms appearing too small on higher resolution monitors, etc.

Buttons

On the Macintosh, standard buttons are white. If the decision is made to use a grey background in a form, be certain to set the DrawStyle property of buttons on that form to 3D Control. Otherwise, the result of white buttons on a grey background is very unattractive.

Following the above suggestions will help in avoiding many of the pitfalls of cross-platform development with OPO. Obviously, the nature of the cross-platform needs may be such that the class instantiation strategy may be overkill, however, the minor interface issues dicussed take so little time to actually deal with in the development process that they can become habit-forming. Developing these kinds of habits in OPO development means that when your application needs to go cross-platform, it will take much less time to get it there.

Prepared by Barry Johnson of Dynamic Information Systems, LLC (NOTE: Outside the firewall).
©1995 Dynamic Information Systems, LLC