Which Coding Framework for Mac OS X ? 334
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.
You also have Carbon (Score:5, Informative)
Cocoa just makes things a lot easier.
I like to think of it this way (though technically its wrong, its a nice way to think of it): Win32 == Carbon;
Native, native, native (Score:2, Informative)
Don't use Cocoa (Score:0, Informative)
learning objective c (Score:5, Informative)
Get a beginners book and work your way through it. I recommend Cocoa Programming for Mac OS X by Aaron Hillegass, published by Addison Wesley, ISBN 0201726831. This seems to be what most people learn from.
Cocoa all the way (Score:5, Informative)
Cocoa, because of it's past with NeXTstep, has a lot of emphasis on rapid-prototyping and dynamicism. Lots of delegation, lots of easy stuff to do to get an effective solution. As for Java, I'd have to follow Aaron Hilldegrass' advice... don't. Not on the Mac, not unless your goal is cross-platform. If you're writing for the Mac, write in Objective-C, C++, or even REALbasic, but not Java. There's simply no good reason.
Having written nearly identical programs many years ago for Mac, PC and NeXTstep, I'd say this. Mac and PC (Mac = traditional Toolbox on OS7.x) and Win32 are roughly equivelent to get the work done. Different, but one isn't necessarily easier. The NeXTstep app was implemented in 1/3 of the time, and that included me learning NeXTstep.
Re:Don't use Cocoa (Score:4, Informative)
Carbon was designed to ease the porting of old OS9 apps to OSX, and AFAIK is meant to vanish.
You'd better use Cocoa and learn ObjC
My two cents.
Nothing wrong with Objective C (Score:5, Informative)
I love C++, templates, and think nothing of derfrrencing a pointer to a vector of objects that are stored in a crazy containter that I cobbeled together last night while high on cough syrup and mountain dew:
However -
Objective C kicks ass for GUI apps. It's easy to learn, and hides some of c's rough edges, and it's fast to compile. Make no mistake - nobody's going to code the next operatig system in it - but for GUI apps, take this good tool and run with it.
Why not Java / Swing? (Score:1, Informative)
Forgive my inexperience with OSX programming, but some of the features you seem to be interested in are not OSX specific.
Easy IPC can be accomplished numerous ways using vanilla Java (RMI, conventional Thread communication), and you can go with CORBA for language-neutral IPC. And I think Java Threads are as good or better than BSD processes.
The UI decision is less important than the underlying program architecture and language/framework choice. Swing is the most obvious choice, but there are others [xwt.org].
Re:learning objective c (Score:3, Informative)
I agree, I used to program on the NeXTStep platform (my placement/internship company were typesetters, the native PostScript came in handy) and it is virtually (I may be completely wrong here, I havent touched OS X, let alone Macs ;) ) the same thing, just a tad older
With our NeXT systems, you could program in Objective C (being the staple diet), but you could also use C/C++ code as well if you wanted. It won't take to long to get used to (I've heard some peeps say that Objective C is more of a proper OO than C++, but I'm not taking any sides here!)... plus as a programmer, once you know the basics it is just a case of getting used to the semantics, syntax style and quirks of the different language you're learning. Good Luck!
Speaking from experience... (Score:0, Informative)
First of all, Java. Java unfortunately is still too slow in its execution time. Yes there have been improvements, but they're not up to par yet.
Cocoa is alright, except that it uses Objective C. Objective C is a bastard child of C and C++, and it doesn't really mesh too well.
Which leaves Carbon. Nice, clean C++. Speedy execution too. Go for Carbon.
Now Nextstep, that's a whole different ballgame.
Re:Cocoa all the way - Mod Parent Up (Score:5, Informative)
Now, for my own two cents regarding Java+Cocoa: Don't do it. Some friends and I programmed a Jabber-based instant messenger in Java and Cocoa before OSX was officially released. Working with the beta frameworks was a nightmare, for one simple reason: Nobody else was doing anything with Java and Cocoa. To my knowledge, there are only a handful that work with it now.
Like other posters have said, if you're just starting out on a platform, get over your fear of learning a new language. Objective C + Cocoa on OSX and C# + Windows Forms on WXP are the way to go. Also, Carbon, like MFC on Windows, is only really useful if you've got a lot of experience with the older Mac operating systems. There's a lot of cruft in there that's not really necessary and can be a pain to learn. You should find yourself developing a lot cleaner code a lot faster if you take the time to learn the newer tools available.
Have fun. =)
Obligatory resume (on topic because it lists the project!... riiight): http://www.cs.hmc.edu/~awooster/resume.htm
Re:Don't use Cocoa (Score:3, Informative)
There was a session on this at this spring's developer conference. Even applications like TextEdit, which you'd assume would be pure Cocoa, considering the source, use a combination of Cocoa and Carbon code in them.
Your generalization is wrong, sorry.
Cocoa / Obj-C (Score:5, Informative)
Definitely, learn [apple.com] Cocoa and Objective C if you can, just for the experience of realizing how much better it is that most of your other choices. With InterfaceBuilder [apple.com], you can completely abstract your UI [apple.com] from the core of your code.
Since you say you want to use the BSD layer, I suggest making a command-line [apple.com] version of this core code first (you can do this in C or C++), since this will be immediately more portable to other Unices. Once that is done, tying that code in with the UI you build in InterfaceBuilder is simple.
Also, there are some pretty interesting [apple.com] native IPC libraries [apple.com] in Mach. If you don't mind your code [apple.com] being tied to Mach, you should check that out as well.
Oh, did I mention that Apple's developer tools and documentation are free for download [apple.com]?
How about Qt/Mac (Score:3, Informative)
I used gtk for a while and now switched to Qt. It is just wonderful. I can just recommend it to anyone who is willing to use C++/perl/pyth/ruby or so. It is pretty solid, and (wit exeption of the moc-precesser) very beautyfully designed. It is portable and available on Win/Unix/Linux/MacX.
I ported some of our apps to Qt/Mac. Well, I recompiled the Qt stuff and the porting was related to other parts.
Even though many people don't seem to realize, it Qt is fully GPL. The plain, good ol GPL. So if you project is GPL it is a very good choice. If not, you probably have the money to pay and it is still a good choice.
Cheers, Peter
Java Cocoa (Score:5, Informative)
All that said, I would strongly recommend you take the time to learn ObjC Cocoa. I use Java Cocoa when I am grafting a Cocoa UI onto Java code, but ObjC is still faster (though the gap is narrowing) and I still honestly believe the language is still a bit more productive due to things such as Categories, Smalltalk-style method names, and other things. If you know C and Java and are familiar with the concepts of reference-counted garbage collection, learning ObjC will take you the better part of a morning.
Re:learning objective c (Score:3, Informative)
Once you've mastered C-- which takes about two days, using nothing more complex than a copy of The C Programming Language by Kernighan and Ritchie-- you can learn Objective C using Apple's language reference, which is available for free on the web at this link [apple.com]. (Warning: 1.7 MB PDF) Apple also has a number of tutorials on Cocoa programming available on developer.apple.com [apple.com] that make for a nice, gentle introduction. You'll know Currency Converter inside and out in a matter of hours.
how easy is it to connect front end cocoa stuff like drawers, services access, etc to java backend services
Trivial. There's a full Java language binding for the Cocoa API. You can, in fact, write an entire graphical application in Java with the Cocoa API (using Interface Builder for the GUI, naturally).
As for your other questions, I'll defer to people with more experience than I have.
Re:What about QT? (Score:2, Informative)
It runns just fine. porting from Linux to Mac? No, just recompile.
Re:Best Framework for Mac OS X (Score:4, Informative)
Carbon and Cocoa are merely two APIs that allow you to do the same thing. Carbon is procedural, Cocoa is object oriented.
Many things are easier to prototype and get your initial code up and running in Cocoa, but like an OO framework, you must design your object hierarchy well ahead of time.
There is also a rather serious learning curve for Cocoa, and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.
Most of the major applications for Mac OS X are written in Carbon, and will continue to be. Cocoa is a very cool OO framework, but it isn't right for every project, and the misinformation you're spreading is doing no one any good.
Re:You also have Carbon (Score:1, Informative)
Re:Cocoa / Obj-C (Score:2, Informative)
Also, O'Reilly's Building Cocoa Applications [oreilly.com] is excellent for the beginner, although I wish they would publish AppKit & Foundation in a Nutshell for a good off-line reference.
Some other good references:
Comment removed (Score:5, Informative)
Might want to read this (Score:4, Informative)
Re:Mozilla (Score:5, Informative)
If you haven't looked at it closely, don't knock it. Take a look at Creating Applications with Mozilla [mozdev.org], from O'Reilly (of course.)
Only on X11 (Score:2, Informative)
Qt is fully GPL.
Only when compiling for the X11 target, which requires Mac users to install XDarwin and Windows users to install Cygwin and XFree86.
Fink? (Score:2, Informative)
If it isn't true, explain to me why what are free utilities for Windows machines are $20-$30 extortionware for the Mac.
Which utilities that don't already have equivalents in Fink [sf.net] (i.e. d*b**n gnu/mac os x) are you talking about?
Re:The Master Of C (Score:5, Informative)
C++ adds a number of keywords to the C language but not that much. Even so it is a highly complex language with lots of special constructs and exceptions.
Greetings,
Along the lines of the myriad calls to use Qt... (Score:2, Informative)
...I'd also suggest taking a look at wxWindows [wxwindows.org]. They're open source, the results look very mac native (they have screenshots), and it seems to be very portable....having libraries for windows, most *nux (using GTK, Xt, or Motif), and macs, and maybe a few others. Oh, and it's c++ for those with an objective-c phobia, like me :)
I honestly don't know why more isn't done with this framework outside of those crazy python people. It looks good, and is completely free (both as in beer and speech), unlike Qt (not trolling, just stating a fact!)
Re:Don't use Cocoa (Score:4, Informative)
Re:Why not wxWindows? (Score:2, Informative)
I've been using wxWindows for linux and windows for about a year now, writing diagnostic tools for our manufacturing plant (some very complex). I've needed to get down and dirty with process monitoring, threads, and IPC, and I can tell you, that wxWindows is great. I was able to write once in linux (my prefered platform at work) and just compiled it on windows.
As for the mac, I would imagine it's similar, but I don't have the experiece yet (just got my mac a month ago).
And the best part is, it's free.
Re:Let the application dictate the language (Score:4, Informative)
If you are porting your java-based massive application to Mac, than ObjC is probably out.
That's not necessarily the case. Cocoa can (mostly) transparently manipulate Java objects from Objective C. See here [cocoadevcentral.com] for more info.
Re:learning objective c (Score:3, Informative)
OpenStep and Cocoa, however, are virtually the same thing. OpenStep was a big revision of the OS and the API.
But all the same, I heartily reccomend using Objective-C and Cocoa, especially above the other options presented: Java and C/Carbon.
Re:Don't use Cocoa (Score:4, Informative)
There may be exceptions, however. Perhaps, for instance, the Cocoa QuickTime classes are wrappers around the Carbon classes. Since I haven't done any QT programming at all, I'm merely speculating.
Cocoa for sure (Score:1, Informative)
As for the learning curve, its no more than hour at most, its like C/C++ cept with different syntax when working with classes and objects.
There are many more reasons, a stroll through the Apple develope pages will shouw you what I mean.
Re:learning objective c (Score:4, Informative)
Coming from Java, you may want to use "Objective-C++" simply for the ability to declare local variables anywhere in your code. Straight C and Obj-C only let you declare local variable at the beginning of a block, but Java, C++, and Obj-C++ let you declare them anywhere in your method. Obj-C++ gives you a bunch of other stuff I don't even know about, but for me, all I care about is the flexibility with local variables. Simply use the ".mm" extension instead of ".m" for your source files.
Re:The Master Of C (Score:5, Informative)
Understanding pointers is a challenge for many C newbies. It helps if you remember that a pointer is just a number, usually a variable but sometimes a constant, which represents an address in memory. It helps even more if you can remember that that address in memory is just an offset from the start of the memory (note this only works on architectures with flat addressing; it gets a bit hairier on, say, DOS).
Since C is a pass by value language, passing a pointer (or anything else) means passing a copy of a value. In the case of a pointer, that means a copy of the address, so now both the caller and the called function know that some memory exists, and can (in the abscence of const) modify it.
Since the pointer is just a number, it can be added to. Adding to a pointer actually means that the address is incremented by the amount of the addition times the size of the thing being pointed to. In other words, the compiler takes some pains to ensure one is alsays pointing to the start of what should be an object, and not within the guts of the object. So if I declare a a pointer to a 2 byte sized object, adding one to the pointer will point me to the next two byte oject in memory, and not to the second byte of the first object.
Naturally, the programmer must allocate the memory to be pointed to. The pointer is merely an address, it's not the memory being addressed. Declaring a pointer gives the programmer a place to write the address down; it does not create the mmemory: the fucntion call malloc ("memory allocate" ) "creates" the memory.
I beleieve the OP noted he came from an assembly background, which means that he's used pointers (untyped ones at that) so it may be less of a challenge.
The other C pitfalls for the unwary are the declaration structure, and (related) to this, the way arrays are handled. Several primers exist on decoding declarartion syntax; in a nutshell, declarations should be read from the inside out, left to right until a right parenthesis forces reading right to left. The declarartion:
int ( *f )( char )
is read "f is a pointer to a function taking a char argument and returning an int.
In C, arrays are not first class objects, and so when passed to functions they "decay" to pointers to the first element of the array. An array name can be treated like a pointer, and indexing into an array is defined by the language to be exactly equivalent to dereferencing an array plus the index:
Given
char array[ 4 ]
array[ 0 ] is just *( array + 0 ); and array[ 3 ] is just *( array + 3 ). array[ 4 ] is *( array + 4 ) and is an illegal (well, undefined) dereferencing of the "element" one past the end of the array.
I have said too much for a post, so I'll end now. The point is, as long as one remembers a few key ideas: pass by value, pointers are numbers for addresses, and declarations need to be read inside-out, C is rather straigtforward.
Cocoa (Score:2, Informative)
The Objective-C language has got to be the coolest language I have ever used. I love being able to add a method like -encryptWithKey: to the NSData class without subclassing it.
The automatic memory management with -retain and -autorelease is great, too. Almost never have to worry about it.
Besides all this, you can use straight ANSI C code (and C++, too, in Objective-C++) right in the same source file.
In short, give Cocoa a look. If it doesn't meet your needs, try using one of the other solutions. The only thing I can come up with where you would need to not employ Cocoa is if you desire easy portability.
C and X Windows (Score:1, Informative)
COCOA COCOA COCOA! (and here's why) (Score:2, Informative)
Don't even think about Carbon. It's 18 years of evolution from a bitty-box API that was in Pascal.
Cocoa, on the other hand, is NeXTSTEP, and as any NeXTer can tell you, NeXTSTEP was the best operating system ever (at least the best API ever). It's amazing. Ten minutes with InterfaceBuilder and you'll be hooked. Where as most tools of this sort just give you some kind of data thingy that you have to interface with programmaticly using some magic codes, you can actually put OBJECTS in a NIB file, which will be unpacked at runtime, and automagicly referenced in places where you have references to them. They have these actions and connections. It's great.
Java is my favorite language (although recently Ruby has been fighting hard for that space), but I must say, the docs for Java-Cocoa are terrible. I gave up and learned ObjC.
That, inititally took about 45 minutes (I've done C++), but actually getting through the qwerks to where I could use the language well took 2 weeks or so. In a nutshell: If you are used to garbage-collection, you will hate ObjC. Period. It stinks. In almost every other respect, however, ObjC is a great language.
The Java documentation may have improved a lot since I ws reading it.
No, in short: Cocoa, cocoa cocoa. And Java if the docs are decent by now, otherwise Objective-C.
Cocoa with Objective C. Its the only way. (Score:4, Informative)
IF you already know C then learning Objective-C will take a week or two. If you know C++ or Java, then learning Objective-C will take a day or two.
Cocoa is, bar none, the best environment to develop applications under, on any platform. Therefore, if you've already chosen the Mac platform for your App, then use Cocoa.
Carbon is there fore backwards compatibility. Some parts of the OS are still carbon, and carbon and cocoa have been "toll free bridged" in places so you can use data structures interchangably. but it is much slower to build an app with carbon than cocoa.
So here's the simple way to answer your question:
1) IF you simply must use Java, or want to eventually run on multiple platforms, use Cocoa-Java (Which is well documented. Get Cocoa Browser to get easy access to the docs.) Use any Cocoa book to learn how to write in cocoa-java, just use the Java APIS instead of the Objective-C ones. Though Java isn't perfectly supported and Objective-C is recommended if you don't HAVE to use Java.
2) IF you have a large application ( greater than 10,000 lines) then it may be better to use carbon. A huge app, like photosohop, it definately makes sense. but any small application would be better off with rewriting the UI using the Appkit and Objective-C and just bringing over the calculation and graphics stuff from the previous version as-is. After all, Objective-C and C code (and even C++ code and Java) can be intermixed.
3) You should never start a new application using Carbon. Carbon is for backwards compatibility. IF you're starting a new application, use Cocoa and you'll save so much time with the superior cocoa apis that the time it took to learn them will be more than made up for.
I had a Java application that I wanted to bring to Mac OS X. I started down the path of Cocoa-Java and quickly realized that objective-c was recommended, so I checked it out and discovered even the fact that I was learning a new language, as well as a bunch of new frameworks, I was getting a lot more work done faster using Objective-C and Cocoa than I have in the past with Java.
Carbon is there for backwards compatibility when it doesn't make sense to rewrite the app. Cocoa-Java is there when you have a JAva app you want to migrate. But Cocoa with Objective-C is the clear, definite, best way to go under Mac OS X.
And anyone who's taken the time to learn it will tell you that it is far superior to the alternatives.
I dread dealing with Carbon APIs now as they invariably turn into time sinks where it seems to tkae 4-8 times as much effort to get something done as it would if there were a cocoa api for the area in question.
Go Cocoa/Objective-C.
Re:learning objective c (Score:3, Informative)
Just get any of the good Cocoa books like "Building Cocoa Applications or the Hilgress book.
They will teach you Objective-C in the early chapters.
Apple puts out a free learning Objective-C book with their development platform.
You don't need to waste time with C becuase you already know java and Objective-C is more like Java than C in use.
Learning C means learning a lot of useless pointer crap that you don't ever use in Objective-C.
I'd say, it will take you no time learning it, and the compiler will catch all the mistakes you're likely to make. (I came from Java, though I'd used C a lot in the past.)
Java is enough like C that you should have an easy time-- just get a cocoa book.
Re:Cocoa / Obj-C (Score:3, Informative)
You can build tools in Objective-C, and GCC supports objective-C so objective-c itself should be pretty portable.
Its just the cocoa frameworks that aren't. (Though there are people creating an open source version of it.)
Re:The Master Of C (Score:5, Informative)
in obj-c memory mgmt is much better handled. when you make an object a "reserve" is put on it. when yr done with the object, you "release" it. you can add as many reserves as you want and release them when you wish. when the reserve count finally reaches zero, the object is deallocated. brilliant!
the skinny on obj-c and memory is here [macdevcenter.com]
if you find you have objects deallocating prematurely and are losing track of yr reference counting, get the object meter [omnigroup.com] from omni group (makers of omniweb). there's a free demo license that works quite well for the budget-challenged.
Re:Mozilla (Score:3, Informative)
As a matter of fact...
I have used MFC serialization in the most bizarre and difficult ways. In normal usage, adding new data into an existing set of serialized data is really, really easy. Just make sure that every object you serialize stores it's own version number when you write it it out. Increment the version number when you make a change to the serialization out, and pay attention to the version number when you're reading in the object.
If you're creating a new version of your application, say re-writting the code from scratch, it is easy to write a set of classes that can read old product files and convert them into your new object structure. In fact, I've even written code that re-writes the runtime dynamic class names in a serialized data file just so it can be read in by a new generation piece of software.
The ability to make compound documents with MFC is unbelievably sweet. I was part of a development team which created a single unified file format with a compound document architecture that was readable by 5 different pieces of software. Each piece of software had it's own slot in the compound document to write their own specific data out. I could derive my own classes off the base data classes, and they would be runtime created by the serialization when reading files. It was the sweetest little file system ever.
Could it be done with XML? Yes. Would I prefer to work with XML? In principle, yes. Did I suggest that we use XML for a world-readable data export? Yes. But management would prefer to write up contracts with other companies to share data reading specs. And sure enough, that worked, and our products sold. So MFC serialization was sweet from a programmer's point of view, and was practical from management's point of view.