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