Cocoa applications are typically developed using the development tools provided by Apple, specifically Project Builder (or more recently Xcode) and Interface Builder. However the Cocoa programming environment can be accessed using other tools, such as Perl, Python and PyObjC.
For end-users, Cocoa applications are considered to be those written using the Cocoa programming environment. Such applications often have a very unique feel, since the Cocoa programming environment automates many aspects of an application to comply with Apple's Human User Interface guidelines.
| Table of contents |
|
2 Main frameworks 3 Memory management 4 Implementations 5 External links |
Cocoa is derived from the NeXTSTEP and OPENSTEP programming environments developed by NeXT in the late 1980's. Apple acquired NeXT in December, 1996, and subsequently went to work on the Rhapsody operating system that was supposed to be the direct successor of OPENSTEP and use OPENSTEP technology proper, and have an emulation base for Mac OS applications, which was termed Blue Box. The OPENSTEP base of libraries and binary support was termed Yellow Box. However, the focus on Rhapsody lessened, and Apple soon shifted to developing Mac OS X.
Much of the work that went into developing OPENSTEP was applied to the development of Mac OS X. Cocoa is the most visible part of that synergy. There are, however, some very important fundamental differences. The most visible of which is that NeXTSTEP and OPENSTEP used Display PostScript for on-screen display of text and graphics, while Cocoa depends on Apple's Quartz (which uses PDF). Cocoa also has some level of internet support (NSUrl classes, and others), while under OPENSTEP one managed network connections through NSFileHandle classes and Berkeley sockets.
Cocoa consists of two Objective-C libraries called frameworks. Frameworks are a construct unique to the NeXTSTEP/OpenStep/Cocoa family of programming environments. They are functionally very similar to shared libraries, which are often referred to by the acronym DSO, for dynamic shared object, or DLL, for dynamically linked library. A framework consists of a compiled object that can be dynamically loaded into a program's address space at run-time, along with the associated resources, header files, and documentation.
One feature of the Cocoa environment that is, if not unique, certainly unusual is its facility for managing dynamically allocated memory. Cocoa's NSObject class, from which all Cocoa classes, both vendor and user, are derived, implements a reference counting scheme for memory management. Every object has a retain method and a release method, and an instance variable accessible through the retainCount accessor method. A newly allocated object, created with alloc, has a retain count of one. Sending that object a retain message increments the retain count, while sending it a release message decrements the retain count. When an object's retain count reaches zero, it is deallocated and its memory is freed. (Deallocation is to Objective C objects as destruction is to C++ objects. The dealloc method is functionally equivalent to a C++ destructor.)
In addition to manual reference counting, application programmers may choose to make use of autorelease pools. Sending an object an autorelease message puts that object's deallocation under the control of the thread's global autorelease pool. The autorelease pool releases an object some time after program flow has passed out of the block where that object was autoreleased.
Cocoa gives the programmer the choice of whether to manually manage his objects or not. Opinions on this are divided. Some say that Cocoa's memory management is superior because it allows the programmer to have precise control over when his objects are deallocated, but does not burden him with the necessity of doing so for every object a program allocates. Others say that the whole mess is unnecessary, and that Java-style automatic garbage collection is superior, because it removes the possibility of programmer error in memory management.
Java bindings for the Cocoa frameworks are also available. However the frameworks themselves are written in Objective-C and hence Objective-C is presently the preferred language for the Cocoa applications.
An open source implementation of the OpenStep specification is available under the name GNUstep.Cocoa history
Main frameworks
The "NS" prefix, used for all framework objects, comes from Cocoa's NeXTSTEP/OpenStep heritage, as does the .nib file extension used by the Interface Builder. The .nib suffix originally stood for NeXT Interface Builder, but conventional wisdom now holds that .nib doesn't stand for anything; it is now said to refer to the word nib, meaning the sharpened point of a quill or pen.Memory management
Implementations