Re: Cross Platform Obj-C?
Re: Cross Platform Obj-C?
- Subject: Re: Cross Platform Obj-C?
- From: Graeme Hiebert <email@hidden>
- Date: Tue, 7 May 2002 07:17:17 -0700
On Sunday, May 5, 2002, at 09:04 , Nathan Zamecnik wrote:
I would write all your generic objects, like containers, lists,
manipulators
etc. in ANSI C++. Anything that manipulates data behind the scenes
really.
That way it is transferable to any platform. Or, you could write it
all in
Objective C so long as you don't use any of the Cocoa Objects...which
IMO is
where Objective C gets it's power.
But using the Standard Library and C++ (Or the standard library of C w/
Objective C) for the generic parts of your program would be acceptable.
Basically, anything that is not interface. This leads to the second
part.
I would then create the interface for all my programs in their native
code.
I agree with this 100%, and am in the midst of putting together a small
C++ class hierarchy to do just this.
My employer has an applications which performs some heavy-duty
scientific operations (GIS data translation and manipulation). It is
available on Windows and various UNIX platforms, and provides an API to
allow programmers to take advantage of its power. It has a user
interface on Windows, but not on any other platform.
A part of the user interface is seventy or more little dialog boxes to
change the "settings" of various input and output formats. As the
"portability" guy, I want our UNIX users -- particularly Mac OS X -- to
be able to take advantage of the settings dialogs, and perhaps other
parts of the user interface.
My belief is that each operating environment (even Windows) has a
culture, and that culture must be respected in the user interface. This
is reinforced by the "API" nature of our product, as we cannot presume
to tell our users what application environment they must write for;
indeed, they may be integrating our product into a legacy application.
My mini-framework allows one to write the "controller" part of a user
interface in C++ -- which I'm guaranteed will be available without
hassle on all supported platforms -- and to allow a "driver" layer for
the graphical operating environment to translate user events to
high-level messages sent to the controller class.
The design is built on flexibility and simplicity. The objects involved
are as generic as possible, given that they need particular behaviour.
A given "user interface" unit can be loaded as a part of a dialog (where
the native UI supports it), or as a separate modal dialog box (which
Windows users seem to prefer for some reason). Because my code layer is
provided for portability of controller objects, and not a foundation for
a user interface application, the application is still ultimately in
control of the whole user experience.
Eventually I'd like to add the ability to construct a user interface
from an XML file, as a "fallback" for a particular interface which has
not been coded on the target platform, but the system will always look
first for a "native" interface (e.g. a nib file with the given name) to
attach to the controller, and then build it from the XML file only if
that cannot be found. First, however, I'm just requiring that the
graphical portion be defined on the target platform.
I'm part way through writing up an overview of how this all fits
together, and then I will be prototyping a simple application with a
couple of interface elements, running in two different languages -- most
likely Cocoa and Swing, I'm thinking. (If that doesn't convince my
boss, I'll write a simple controller class that loads up Tcl code from a
named file to act as the controller for a named user interface. He's a
big Tcl guy; if that doesn't get him, nothing will. :^)
I'm doing this primarily in my own time, and intend to make it publicly
available. Unfortunately time is something I don't have a lot of these
days. (As I said, I'm the portability guy at work, and we're in the
middle of updating a million lines of C++ code to use "new" iostreams so
that that our code will be fully dotnettable.)
-g
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.