Re: Cocoa/Windows parallel dvlpmt
Re: Cocoa/Windows parallel dvlpmt
- Subject: Re: Cocoa/Windows parallel dvlpmt
- From: Andy Satori <email@hidden>
- Date: Sun, 1 Feb 2004 11:36:49 -0500
The key to Cross platform, and retaining a native look and feel is to
make the native UI as thin as possible. This way your platform
independent logic exists entirely in portable libraries, and the UI can
then be assembled quickly and cheaply in the native environment.
In my case, I've actually gone to the point of doing this such that I
can leverage better UI tools on each platform. On OS X, my library is
a framework that exposes C++ classes that are consumed by Objective C++
UI Controllers. While on Windows, I export the classes as COM objects,
though I may eventually move them to .NET, I'm still not comfortable
with requiring 80 mb of patches and run times to a new install of XP as
a base requirement, and this is what it requires to run .NET 1.1 apps.
The other advantage to this is that I can leverage the better UI
building tools of Visual Basic or Delphi, tools that are more analogous
to Interface Builder than MFC / Visual Studio.
While I haven't deployed anything using this model on Linux, I do have
proof of concept work that implements the same approach using both
Gnome (Bonobo) and KDE. Overall, I'm happier with this approach than I
ever was with my prior cross-platform experiences, using the one tool
to target multiple platforms approach that left me with an app the ran
everywhere and looked native nowhere. And this includes Java both with
AWT and Swing.
Finally, the other thing that is great about this approach is that it
provides a significant speed boost over the alternative solutions.
Please bear in mind that all of this comes from a Windows developer
that is moving away from Windows personally, and now only writes
Windows code for his employer, and is using this very methodology to be
a happy employee. I write my library code in XCode, test the library
on my Mac using a Cocoa UI, and when I'm happy with the results, I open
VPC, and assemble the Windows UI in Delphi or VS.NET.
Andy Satori
Satori & Associates, Inc.
email@hidden
On Feb 1, 2004, at 8:45 AM, Lotsa Cabo wrote:
Phillip,
GREAT mindset! I agree with you 110%.
Too many people these days are stuck in the mud believing that "true"
cross-platform development means writing their app in such a way that
they can simply compile and launch on another platform; for example,
using Java for everything from UI to business to data. And, while
this may theoretically be possible, the end result is usually not
something that feels as if it was made for the target platform.
I'm still in "discovery mode" trying seek out the perfect mix of
technologies for my app so that it can be ported to each platform --
Mac, Linux, and Windows. I've been leaning towards Objective-C, but
was told (on another thread) that it's not very easy to port to
Windows because of licensing. Any information you know of pertaining
to cross-platform ObjC++ stuff would be great.
R/S
Ryan
On Feb 1, 2004, at 8:03 AM, Phillip Mills wrote:
On Saturday, January 31, 2004, at 02:05 PM, Erez Anzel wrote:
I have been happily developing in Cocoa using XCode 1.1. But I have
to port to Windows, very quickly. I want to keep my duplication of
effort to a minimum, so that I can maintain and enhance both
products efficiently.
I've done this kind of thing -- with Linux tossed into the mix as
well -- and it made me a great fan of Objective C++.
My strategy was to use "pure" C++ for everything that was not GUI and
have it compile with as few platform dependencies as possible on all
three targets...lots of STL. I also assumed that the only part of
the GUI that would be portable was the functional design. I think
that by acknowledging that up front, I saved myself a lot of pain
during GUI implementation.
To link the pieces together, my C++ code acted as a library that
could be called by any interface (including a console one that I
wrote for testing). I also defined abstract classes for my C++
library that defined a "virtual" GUI...call-back functions that the
core code needed for display purposes. Those classes then had their
implementations provided by the real, platform-specific
interfaces...either directly on Windows and Linux, or by thin C++
objects within Cocoa/Objective C++ classes.
........................
Phillip Mills
Multi-platform software development
(416) 224-0714
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.