Slashdot Mirror
Which Coding Framework for Mac OS X ?
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.
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.
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.
Several advantages:
- Easy cross platform. Your app will run on any platform Mozilla/Netscape run on.
- Easy development. Subjectively, development goes a lot faster than under a traditional framework.
- 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.02Patrick
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
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).
"How to Do Nothing," kids activities, back in print!
But if you have a complex GUI, do take a look at QT/Mac from trolltech. It isn't FREE but it is quite good and allows your program to be portable between Mac/Linux/Windows.
--jeff++
ipv6 is my vpn
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.
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++.
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?
I am the Alpha and the Omega-3
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.
I write in my journal
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.
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.
-- The world is watching America, and America is watching TV.
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.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
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.
If time was money we should all sit around waiting to get rich.