Forgot your password?
typodupeerror
Apple Businesses

Which Coding Framework for Mac OS X ? 334

Posted by Cliff
from the choosing-your-poison dept.
DrStrangeLoop asks: "I am in the progress of getting into coding for Mac OS X, and I am wondering which GUI framework/language i should focus on. Apparantly, there are at least three options: the Cocoa Objective-C API [I don't want to learn Objective-c, but it seems that's how Apple wants me to code], the Cocoa Java API [gets compiled to PPC binaries, lots of APIs available [think Google], but absolutely no decent documentation to be found] and Swing Java classes [look 'n feel of Cocoa, but portable]. However, the most important feature for me is a clean and easy IPC with BSD layer processes. I figure sockets will work with all options, but what about the other mechanisms? Any suggestions?" Update: 10/13 22:08 GMT by C :For those curious about the Cocoa/Carbon debate, you can find an article that discusses this very issue, here. Thanks to the folks over at Freenode's #macdev for providing the link.
This discussion has been archived. No new comments can be posted.

Which Coding Framework for Mac OS X ?

Comments Filter:
  • by tqbf (59350) on Sunday October 13, 2002 @02:17PM (#4441306) Homepage
    If you need "clean and easy" integration with "BSD IPC" (the native programming interface of the underlying Darwin operating system), you need to be able to use its C-language calling interface. Of the 3 kits you mentioned, Cocoa/Objective-C is the only one that offers that.

    The ready-made integration offered by your two Java alternatives may not be useful for hardcore I/O anyways. How do you get a handle on an fd-based resource (/dev/bpf*, for instance) and then integrate the fd with your event loop?

    My moving-forward plan has been to maintain my application logic in standard C/C++, and use Cocoa/ObjC to build UI (and nothing else) on top of that. Since most good BSD code is asynchronous, and Cocoa/CoreFoundation lets you control the event loop at the "select()" level, this works fine for me.

  • by akac (571059) on Sunday October 13, 2002 @02:23PM (#4441335) Homepage
    Wrong. CLASSIC goes through a compat layer which is probably what you mean. Carbon and Cocoa are FULLY native on OS X. In fact, some Cocoa calls actually call Carbon API funcs. Even Apple developers use Carbon (iTunes) and mix Carbon and Cocoa in the same app.
  • Mozilla (Score:5, Interesting)

    by Fished (574624) <amphigory@gmaCOMMAil.com minus punct> on Sunday October 13, 2002 @02:28PM (#4441355)
    I asked myself the same question a few months ago, and came to the conclusion that unless/until I have an application that requires a native API, I would do everything in Mozilla. In practice, this means a combination of XPCOM, XUL, RDF and javascript. It's like developing a really advanced web page, but you're not stuck in a browser framework.

    Several advantages:

    1. Easy cross platform. Your app will run on any platform Mozilla/Netscape run on.
    2. Easy development. Subjectively, development goes a lot faster than under a traditional framework.
    3. Something you probably already know: most people I know who program already know HTML and Javascript to some degree. From there, it's a very small leap to XUL and Javascript.
    The major disadvantage is that it will necessarily be a little slower than a custom coded native solution. But who cares for most apps? With recent Mozilla versions, it's more than fast enough. Anyway, my $0.02

    Patrick

  • by dpbsmith (263124) on Sunday October 13, 2002 @02:31PM (#4441369) Homepage
    I'm not sure whether it is suitable, but It does give access to the full API via "declare" statements.

    Don't reject it out of hand just because it isn't a "macho" language.

    I don't say it's the right environment for you. I do say you're being foolish if you don't at least take a look at it.

    You can make a very good evaluation because REALsoftwarelets you download a version that is complete, and comes with full documentation (it produces time-crippled applications that only work for thirty days).

  • by statusbar (314703) <jeffk@statusbar.com> on Sunday October 13, 2002 @02:39PM (#4441398) Homepage Journal
    If the app GUI is fairly simple, do the back end in a c++ library, and do the front end in Cocoa.

    But if you have a complex GUI, do take a look at QT/Mac [trolltech.com] from trolltech. It isn't FREE but it is quite good and allows your program to be portable between Mac/Linux/Windows.

    --jeff++

  • by Ageless (10680) on Sunday October 13, 2002 @03:05PM (#4441512) Homepage
    Unless I am sorely mistaken, the kernel that runs OSX is not written in ObjC. While a OS is more than a kernel (as RMS will gladly point out) the bits that talk to the hardware are the important ones and they are not ObjC.
  • by Anonymous Coward on Sunday October 13, 2002 @03:15PM (#4441555)
    Mac users care a great deal about nativity and the app behaving like a good Mac OS X app. (Otherwise we could be using something cheaper and less elegant, right?) Cocoa is the most native thing on OS X. If you use Cocoa, you have an immediate advantage over competitors who use Swing or Carbon.

    With Carbon you have to implement a lot of stuff Cocoa gives you for free. I still haven't seen a non-sample-code Carbon app with proper Unicode support. Then there are things that Swing apps just can't do. (And don't believe Sun's pluggable talk. You can't just plug in Aquaness without designing for Aqua.)

    The Cocoa Java API feels like an Objective-C API anyway, so you might just as well learn Objective-C unless you already have Java back end code.

    Objective-C is way cooler than C++.
  • by the_2nd_coming (444906) on Sunday October 13, 2002 @03:17PM (#4441562) Homepage
    you can still compile C code with an objective-c compiler, infact, Objective-C isw a true supper set of OO features appened to C, so would you then not be able to use Coaca with C code as long as you compile into an objective c binary?
  • by Twirlip of the Mists (615030) <twirlipofthemists@yahoo.com> on Sunday October 13, 2002 @03:28PM (#4441602)
    Who's to say that you can't write good software in Java?

    Absolutely you can write good software in Java. I've seen it done, although I admit that I don't have the mad Java skillz to do it much myself.

    But you can't write good software with Swing. Swing may be a fine user interface toolkit on UNIX, where there are no superior alternatives, but on a Mac, a Swing application-- unless it's specifically tweaked to use the Aqua look and feel-- is kind of an embarrassment. Java Swing apps run on OS X just fine, but they're unpleasant to use.

    this post just makes me angry

    I'm sorry. You get angry at strange things. Must have missed my post in another discussion about how disappointed I am that Mozilla is irrelevant; that post made lots of people angry.
  • Try Qt (Score:1, Interesting)

    by Anonymous Coward on Sunday October 13, 2002 @03:49PM (#4441705)
    Not only is Qt portable across 3 major platforms (MacOS, Linux/Unix, Windows), but its api really rocks.
  • Cocoa (Score:2, Interesting)

    by Anonymous Coward on Sunday October 13, 2002 @03:55PM (#4441731)
    Cocoa is the framework of choice for most OSX programming. The mechanics and syntax of Objective-C is easy to learn--you can pick it up in a couple days. (Making full use of what it provides you is a different matter--it can take months to stop thinking like a C++ programmer and take full advantage of the dynamicism of the language.) If you're doing any GUI programming this is the framework you should use.

    Carbon exists to provide a way for old codebases to run on OSX. Consider it only if you're already familiar with pre-OSX mac programming, and then only if you have a big, old codebase.

    Java is useful for cross-platform server apps.
  • by Anonymous Coward on Sunday October 13, 2002 @04:15PM (#4441806)
    Malice, i think you're the one mistaken. Mac OS X has several layers. At the bottom is the XNU Kernel (mach with some bsd file tools that would usually be in userspace but put here for speed), then there's the DarwinBSD layer (a mix of Free, Open, and Net BSD, with some NeXT stuff thrown in). On top of that is the Core Foundation. Carbon and Cocoa both are atop the core foundation. Carbon is the cleanup of the old Mac OS 1-9 Api. Its a mess. You only need it if you are a legacy Macintosh Programmer. If you know what MPW, Codewarrior, ResEdit and others are, you apply. If you have used a Mac before OSX, you apply. Cocoa is fantastic. It's objective c with some very powerful frameworks. Objective C is just standard C with some simple extensions. The frameworks might take you a while to learn, but thats because they are so extensive.

    A cocoa app takes less code to write and you get it done a lot faster. If you are a programmer, you learn new languages all the time. It took me 2 hours to learn objective c, and I came from a strong c++/java background.

    Its a cakewalk to take a commandline unix app and wrap a cocoa gui around it. The Gui made in interface builder takes up NO CODE.

    You can also intermix c, c++, and objective C.

    Cocoa is the best way for new programmers. If you doubt me, do the Currency Converter tutorial the Carbon way first, then do it the Cocoa way.
  • by pHDNgell (410691) on Sunday October 13, 2002 @04:58PM (#4441982)
    I also thought that it was pointless to create a native application using java, but then, out of necessity, that's exactly what my first OS X application ended up being.

    I have a web-based app that I wanted to create a non-web GUI for (involved various file uploads and stuff that could more easily be handled via a native GUI). The server supports XML-RPC, but at the time, I didn't have an XML-RPC framework I could use from Objective C. However, I did have a fully functional commandline app that did it that I'd written in java.

    So, I just fired up project builder, told it I was writing a java cocoa app, and spent a while getting the UI the way I wanted it, then just plugged in a couple methods to the controller to call the existing code.

    Because this was my first OS X application, it was a learning experience as far as picking up the cocoa concepts and stuff, but it only took a day of me being home sick (and I felt pretty crappy, so I wasn't working all that fast).

    The time I spent learning cocoa concepts was not wasted at all. I figured out how to build frameworks and get them into my application, so I had the stuff I needed to go full objective C. I *copied* the UI I'd already made into a new project, and pasted a lot of the code straight from the java app to the objective C app (mostly controller stuff). Of course, I had to convert the java cocoa calls to objc, but for the most part, that was it.

    Moral of the story: If you intend to write a native OS X app, and you don't have all the parts you need in objc, but you do have most of it in java, do it in java! It was a good proof-of-concept anyway. :)

  • Re:The Master Of C (Score:1, Interesting)

    by Anonymous Coward on Sunday October 13, 2002 @06:18PM (#4442248)
    Pointers are such a simple concept, why do people have trouble with them?

    Imagine bytes in memory are simply numbered pigeon holes. The first hole is '0', and you go up from there.

    A pointer is a variable that holds the address of another pigeon hole. Pretty fucking simple. And from there, it's only a simple step to pointer arithmetic. If a piece of data takes up two pigeon holes, incrementing a pointer of that type will increase the address value by 2.

    The problem really is that not enough people learn about computers. They learn 'programming' as if it was at a higher level than it really is, and this is both bad and stupid. Teach the low level first - you need to UNDERSTAND the computer before you can instruct it.
  • Cocoa-Java Bridge (Score:2, Interesting)

    by mxcantor (315879) <mxcantorNO@SPAMsas.upenn.edu> on Sunday October 13, 2002 @06:20PM (#4442258)
    The answer is really obvious - the Cocoa-Java Bridge!

    Any Cocoa program can use any java class nearly transparently as if it were Cocoa! For some reason, Apple has hushed up this amazing feature. So, create a Cocoa app, and then use Java classes as necessary! Most of your code will run native, but if you need the VM, it'll be started for you.

    This is what I used for my no-longer-being-worked-on front end to MySQL called CocoaSQL http://www.versiontracker.com/moreinfo.fcgi?id=108 87&db=mac [versiontracker.com]

    I basically wrote a cocoa app using the mm.mysql drivers, very simple. The source code should be up there, if it isn't, let me know.

    Good Luck, Max
  • by Anonymous Coward on Sunday October 13, 2002 @06:21PM (#4442262)
    Sorry to say this, but right now QT is f**king ABYSMAL on Mac OS X. Apart from completely disregarding everything about what makes the Apple GUI great - and giving us a set of horrible 'Aqua-like' widgets (if you get a 3 year old to look at Aqua and then get all the sizes and pixel placements wrong) - QT also only implements single-buffering of windows giving really bad redraw. It's horribly slow and also has yet to even try and build as a bundled Framework, meaning that you can't easily do drag-and-drop distribution of applications as you have to manually install into /usr/local/qt using Packagemanager. This is against the guidelines as it goes against easy version control and application file control. My company was pushing for me to use it and I gave up as it was so bloody awful. As it turns out, I managed to port our QT apps to Cocoa with minimum effort and ended up with an app no bigger than 800K rather than the 9MB atrocity everyone else had, whilst keeping the central non-gui C++ code untouched.

    I say that all should keep away from Trolltech QT whilst these problems continue (write once yes, get the lowest common denominator on all platforms) until they either do a GUi abstraction layer to native widgets on platforms or give a better experience than Cocoa development. For chrissakes, they even wrote it in Carbon, but wrong, so that compiles broke on 10.2....
  • Re:my experience (Score:3, Interesting)

    by bnenning (58349) on Sunday October 13, 2002 @10:06PM (#4443074)
    Cocoa using Objective-C is a somewhat outdated programming environment: the GUI design tools were great in the 1980's, but they are pretty dated by today's standards.


    That's a matter of opinion; I and many others would disagree.


    And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++.


    Not really. Objective C has no built in memory management (neither does C++), but it uses a reference counting system that works well enough that you rarely have to manually allocate or free memory.


    I don't see much of a future for Cocoa, at least in its current form.


    Apple does. Virtually all apps that come with Mac OS X are written in Cocoa and Objective C. iTunes and iMovie are Carbon, but that's only because they were designed to also run on OS 9.

  • by akac (571059) on Sunday October 13, 2002 @11:01PM (#4443241) Homepage
    Actually - to all the people who say that you should use Cocoa if you're new to OS X - thats not completely true. I prefer Cocoa myself. But if I was to write an app I meant to be cross platform between OS X and Windows or Linux, then Carbon MAY make more sense since I may be able to reuse the C/C++ code there a lot easier. Of course, you could write your backend in C/C++ and use Cocoa for just the front end. And that would work if you have an app that is in the design stage. But if you are porting apps already designed that intermix frontend with backend (like most apps do unfortunately), then Carbon makes more sense - its closer to Win32 programming as well.
  • by Crazy Viking (230066) on Monday October 14, 2002 @03:57AM (#4444250)
    Hey, if what you are looking for is a GUI framework for OS X then you should look no further than QT [trolltech.com]. It is C++ and cross platform source code compatible (Linux, unix and windoze).

    If time was money we should all sit around waiting to get rich.

  • Check out wxWindows (Score:1, Interesting)

    by Anonymous Coward on Monday October 14, 2002 @08:59AM (#4444940)
    You might want to check out wxWindows. You can find it on http://www.wxwindows.org.

    It's a cross-platform GUI (or all-around) C++ library that works on Windows, Linux (and then implements either Gtk+ or Motif), Mac OS X and I think a few others.

    It's easy to learn although it may feel a bit weird at first.

    However, if you're not interested in (true) cross-platform functionality, then you might as well go with Carbon/Cocoa in C++/Obj-C/Java. :) When I say true cross-platform functionality I mean using each OS'es native interfaces... when compiled on Windows, it's a Windows app. When compiled on Linux, it's a Gtk+ app and so forth.

    I've been able to compile all my code on all three platforms without any significant problems (and all of those problems have been to my lack of knowledge), always using GCC (which ships with Mac OS X and Linux, and is available with the MingW and Cygwin packages on Windows).

    Hope you like it. I sure do. ;)

Going the speed of light is bad for your age.

Working...