A comparison between the cocoa and .net frameworks

Here's a beginning list. This answer is community wiki, so if you want to add new things or comment about old ones, you can just edit it.

I primarily talk about how Cocoa is different from C# (not the other way around). This is by no means a prerequisite, but if you know some third technology like java or C++, they are more similar to C# and .net than they are to Cocoa and Objective-C.

Visual Studio --- XCode

XCode has Autocomplete, but its not nearly as sophisticated as Visual Studio's intellisense.

C# --- Objective-C

Objective-C code will look extremely different from C# code just because it uses a messaging syntax instead of C#'s dot-notation for calling functions. It isn't really a huge deal once you get used to it.
- Sort of as a consequence of this, Objective-C lets you send messages to nil (aka, null) objects without error. The return value from a message send to a nil object is just nil. So there's a lot fewer checks for nil before sending a message to an object. This really trims down the amount of boiler-plate code.

The Frameworks

Cocoa is very callback driven. Many operations are performed by asking a random object to do something and call back a function (specifically, an Objective-C selector) when it's done. This can often tie in to the delegate pattern where you ask an object to do something and it calls its delegate when it's done to let the delegate know. I almost never use callbacks (or Delegates) in .Net so it took me some time to wrap my head around the control flow when managing tons of callbacks in a Cocoa app.

Miscellany

Cocoa's GUI's are made in InterfaceBuilder and saved directly. They aren't compiled into any sort of imperative code like in .net
Cocoa has garbage collection with Mac OS X 10.5, but if you're developing for previous releases or for the iPhone you have to implement reference counting in your classes, which can be annoying for a .net developer used to garbage collection.
Different event-handling paradigms. There are no event-handlers in Cocoa, you have to use controller classes for hooking up your user-interfaces.

Also, if you're writing a plug-in (such as a color picker) or a public framework, you'll need to write dual-mode code: code that can run either garbage-collected or reference-counted. (This is not *strictly* necessary for frameworks, but if you write your framework for only one memory-management system, you'll annoy users of the other.)

Peter Hosey 2009-11-30 01:27:57

You don't *have* to use controllers in Cocoa. You can handle events directly, if you want, but it is the hard way and not often done. More commonly, people will handle events within individual views or at the window, though.

bbum 2009-11-30 02:18:02

ansaurus

tags:

views:

answers: