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.
Carbon is a good API to begin with. You can use C++ or C and access all the nice GUI of OS X.
.NET == Cocoa
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;
I'd go with Cocoa. The more native, the better.
There they were, sitting in the van with all those dials, and the cat was dead. -V. Marchetti, CIA
While Apple wants you to use Cocoa, they're provided a more typical C/C++ API called Carbon. I suggest you use that- everybody else does. :)
To be honest, I'd say get over it and learn Objective C. For an experienced programmer it won't take you long to get to grasps with the basics of Objective C, and Cocoa is really easy to work with. Who knows, you might even grow to like it :) At first I thought Objective C was weird, but now I really like it.
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.
As someone who grew up around Macs, and then moved to NeXT, I'd have to say that if you know C, and understand OO principles (prefferably in the Smalltalk model, not C++), then you can pick up Objective-C in an afternoon. It's really just some extensions to C. Carbon is a great set of APIs if you've got 10 years of Toolbox experience on the Mac, but otherwise, it's much harder to learn the ins and outs.
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.
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.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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.
I have been programming for Macs for the past 7 years..
;)
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.
The above poster hit the nail on the head.
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
Definitely, learn 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, you can completely abstract your UI from the core of your code.
Since you say you want to use the BSD layer, I suggest making a command-line 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 native IPC libraries in Mach. If you don't mind your code 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?
I prayed about it, and God said, "Don't do it!" But I thought, "I know better."
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
KdenLive/PIAVE - non-linear video editing
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.
It runns just fine. porting from Linux to Mac? No, just recompile.
KdenLive/PIAVE - non-linear video editing
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.
Comment removed based on user account deletion
Check out the article Introduction To and Experiences With Mac Cocoa from Kuro5hin.
If you haven't looked at it closely, don't knock it. Take a look at Creating Applications with Mozilla, from O'Reilly (of course.)
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
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.
Will I retire or break 10K?
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 (i.e. d*b**n gnu/mac os x) are you talking about?
Will I retire or break 10K?
The difficulty of learning a language has little to do with the number of keywords it has. It is more a matter of how those keywords (and operators) are used together to enable programmers to do things. C is not that hard but in some cases it can get complex compared to other languages (even if those other languages have more keywords). Pointer arithmetic is one area in which many people struggle. Especially if you come from a programming language (like Java, ...) which doesn't have that.
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,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
...I'd also suggest taking a look at wxWindows. 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!)
You say
It's doesn't emulate at all. It actually calls the carbon api, they're just adding a portability layer on top that makes sense for all platforms.
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.
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 for more info.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Don't bother with these people that have used one and not the other. The fact of the matter is that oyu can actually do alot more in Cocoa, and its alot faster than Java apps, plus it also has many interfaces adn methods that carbon still doesn't have yet. Cocoa has free support for all of the Mac OS X services that are offred by other apps.
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 C and pointers:
;
;
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.
Opinions on the Twiddler2 hand-held keyboard?
I have to tell you, I LOVE Cocoa/Objective-C. There are a million benefits to both - Cocoa ( in combination with Interface Builder) gives you fantastically easy GUI creation and control.
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.
First off, the Swing Thing isn't a thing like Cocoa in terms of look-and-feel. It looks-and-feels awfully second-class on many levels.
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.
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.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
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
if you find you have objects deallocating prematurely and are losing track of yr reference counting, get the object meter from omni group (makers of omniweb). there's a free demo license that works quite well for the budget-challenged.
2 1337 4 u!
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.