Cocoa (API)

Cocoa

Developer(s)	Apple
Written in	Objective-C
Operating system	Mac OS X
Type	Software framework
License	Proprietary
Website	Apple Developer — Cocoa

Cocoa is Apple's native object-oriented application programming interface (API) for the Mac OS X operating system and—along with the Cocoa Touch extension for gesture recognition and animation—for applications for the iOS operating system, used on Apple devices such as the iPhone, the iPod Touch, and the iPad.

Cocoa applications are typically developed using the development tools provided by Apple, specifically Xcode (formerly Project Builder) and Interface Builder, using the Objective-C language. However, the Cocoa programming environment can be accessed using other tools, such as Clozure CL, LispWorks, Object Pascal, Python, Perl, Ruby, and AppleScript with the aid of bridging mechanisms such as PasCocoa, PyObjC, CamelBones and RubyCocoa. An implementation of the Ruby language, called MacRuby, which does away with the requirement for a bridging mechanism, is under development by Apple, while Nu is a Lisp-like language which can be used with Cocoa without a bridge. It is also possible to write Objective-C Cocoa programs in a simple text editor and build it manually with GCC or clang from the command line or from a makefile.

For end-users, Cocoa applications are considered to be those written using the Cocoa programming environment. Such applications usually have a distinctive feel, since the Cocoa programming environment automates many aspects of an application to comply with Apple's human interface guidelines.

Cocoa history

Further information: History of Mac OS X

Cocoa continues the lineage of several frameworks (primarily the App Kit and Foundation Kit) from the NeXTSTEP and OpenStep programming environments developed by NeXT in the 1980s and 1990s. 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. It was to have had an emulation base for Mac OS applications, called Blue Box. The OpenStep base of libraries and binary support was termed Yellow Box. Rhapsody evolved into Mac OS X, and the Yellow Box became Cocoa. As a result, Cocoa classes begin with the acronym "NS" (standing either for the NeXT-Sun creation of OpenStep, or for the original proprietary term for the OpenStep framework, NeXTSTEP): NSString, NSArray, etc.^[1]

Much of the work that went into developing OpenStep was applied to the development of Mac OS X, Cocoa being the most visible part. There are, however, some differences. For example, NeXTSTEP and OpenStep used Display PostScript for on-screen display of text and graphics, while Cocoa depends on Apple's Quartz (which uses the PDF imaging model, but not its underlying technology). Cocoa also has a level of Internet support, including the NSURL and WebKit HTML classes, and others. While under OpenStep there was only rudimentary support for managed network connections through NSFileHandle classes and Berkeley sockets.

Before its current use, the "Cocoa" trademark was the name of an application that helped children create multimedia projects. Originally known as KidSim, as of 2011^[update] it is licensed to a third party and marketed as Stagecast Creator. The program was discontinued in one of the rationalizations that followed Steve Jobs' return to Apple. The name was re-used to avoid the delay while registering a new trademark, with Stagecast agreeing to market the older Cocoa under a new name.

Memory management

One feature of the Cocoa environment is its facility for managing dynamically allocated memory. Cocoa's NSObject class, from which most classes, both vendor and user, are derived, implements a reference counting scheme for memory management. Objects derived from the NSObject root class respond to a retain and a release message and keep a retain count which can be queried by sending a retainCount message. A newly allocated object created with alloc or copy 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 similar to a C++ destructor. dealloc is not guaranteed to be invoked.

Starting with Objective-C 2.0, the Objective-C runtime implements an optional garbage collector. In this model, the runtime turns Cocoa reference counting operations such as "retain" and "release" into no-ops. The garbage collector does not exist on the iOS implementation of Objective-C 2.0. Garbage Collection in Objective-C runs on a low-priority background thread, and can halt on Cocoa's user events, with the intention of keeping the user experience responsive.

In 2011, the LLVM compiler introduced ARC (automated reference counting), which replaces the conventional garbage collector by performing static analysis of Objective-C source code and inserting retain and release messages as necessary.

Main frameworks

Cocoa consists primarily of two Objective-C object libraries called frameworks. Frameworks are functionally similar to shared libraries, a compiled object that can be dynamically loaded into a program's address space at runtime, but frameworks add associated resources, header files, and documentation. The Cocoa frameworks are implemented as a type of application bundle, containing the aforementioned items in standard locations.

• Foundation Kit, or more commonly simply Foundation, first appeared in OpenStep. On Mac OS X, it is based on Core Foundation. Foundation is a generic object-oriented library providing string and value manipulation, containers and iteration, distributed computing, run loops, and other functions that are not directly tied to the graphical user interface. The "NS" prefix, used for all classes and constants in the framework, comes from Cocoa's OPENSTEP heritage, which was jointly developed by NeXT and Sun.
• Application Kit or AppKit is directly descended from the original NeXTSTEP Application Kit. It contains code with which programs can create and interact with graphical user interfaces. AppKit is built on top of Foundation, and uses the same "NS" prefix.

A key part of the Cocoa architecture is its comprehensive views model. This is organized along conventional lines for an application framework, but is based on the PDF drawing model provided by Quartz. This allows creation of custom drawing content using PostScript-like drawing commands, which also allows automatic printer support and so forth. Since the Cocoa framework manages all the clipping, scrolling, scaling and other chores of drawing graphics, the programmer is freed from implementing basic infrastructure and can concentrate only on the unique aspects of an application's content.

Model-view-controller

The Smalltalk teams at Xerox PARC eventually settled on a design philosophy that led to easy development and high code reuse. Known as "model-view-controller" (MVC), the concept breaks an application into three sets of interacting object classes.

• Model classes represent raw data, such as documents, settings, files, or objects in memory.
• Views are, as the name implies, visual representations of the data in the model.
• Controller classes contain logic which links the models to their views, and maintains state to keep them synchronized.

Cocoa's design is a strict application of MVC principles. Under OpenStep, most of the classes provided were either high-level View classes (in AppKit) or one of a number of relatively low-level model classes like NSString. Compared to similar MVC systems, OpenStep lacked a strong model layer. There was no stock class which represented a "document," for instance. During the transition to Cocoa, the model layer was expanded greatly, introducing a number of pre-rolled classes to provide functionality common to desktop applications.

In Mac OS X 10.3, Apple introduced the NSController family of classes, which provide predefined behavior for the controller layer. These classes are considered part of the Cocoa Bindings system, which also makes extensive use of protocols such as Key-Value Observing and Key-Value Binding. The term 'binding' refers to a relationship between two objects, often between a view and a controller. Bindings allow the developer to focus more on declarative relationships rather than orchestrating fine-grained behavior.

With the arrival of Mac OS X 10.4, Apple extended this foundation further by introducing the Core Data framework, which standardizes change tracking and persistence in the model layer. In effect, the framework greatly simplifies the process of making changes to application data, undoing changes (if necessary), saving data to disk, and reading it back in.

By providing framework support for all three MVC layers, Apple's goal is to reduce the amount of boilerplate or "glue" code that developers have to write, freeing up resources to spend time on application-specific features.

Late binding

In most object-oriented languages, calls to methods are represented physically by a pointer to the code in memory. This restricts the design of an application since specific "command handling" classes are required, usually organized according to the chain-of-responsibility design pattern. While Cocoa retains this approach for the most part, Objective-C's late binding opens up more flexibility.

Under Objective-C, methods are represented by a selector, a string describing the method to be called. When a message is sent, the selector is sent into the ObjC runtime, matched against a list of available methods, and the method's implementation is called. Since the selector is text data, this allows it to be saved to a file, transmitted over a network or between processes, or manipulated in other ways. The implementation of the method is looked up at runtime, not compile time. There is a small performance penalty for this,^[2] but late binding allows the same selector to reference different implementations.

By a similar token, Cocoa provides a pervasive data manipulation method called key-value coding (KVC).^[3] This permits a piece of data or property of an object to be looked up or changed at runtime by name — the property name acts as a key to the value itself. In traditional languages, this late binding is not possible. KVC leads to great design flexibility — an object's type does not need to be known, yet any property of that object can be discovered using KVC. In addition, by extending this system using something Cocoa calls Key-Value Observing (KVO), automatic support for Undo/Redo is provided.

Late static binding is a variant of binding somewhere between static and dynamic binding. The binding of names before the program is run is called static ("early"); bindings performed as the program runs are dynamic ("late" or "virtual").

Rich objects

One of the most useful features of Cocoa is the powerful "base objects" the system supplies. As an example, consider the Foundation classes NSString and NSAttributedString, which provide Unicode strings, and the NSText system in AppKit, which allows the programmer to place string objects in the GUI.

NSText and its related classes are used to display and edit strings. The collection of objects involved permit an application to implement anything from a simple single-line text entry field to a complete multi-page, multi-column text layout schema, with full professional typography features such as kerning, ligatures, running text around arbitrary shapes, rotation, full Unicode support and anti-aliased glyph rendering. Paragraph layout can be controlled automatically or by the user, using a built-in "ruler" object that can be attached to any text view. Spell checking is automatic, using a single dictionary used by all applications that uses the "squiggly underlining" convention introduced by Microsoft (actually a dashed red underline in Cocoa). Unlimited Undo/Redo support is built in. Using only the built-in features, one can write a text editor application in as few as 10 lines of code. With new controller objects, this may fall to zero. This is in contrast to the TextEdit APIs found in the earlier Mac OS.

When extensions are needed, Cocoa's use of Objective-C makes this a straightforward task. Objective-C includes the concept of "categories" which allows for modifications to an existing class "in-place". Functionality can be accomplished in a category without any changes to the original classes in the framework, or even access to its source. Under more common frameworks this same task would require the programmer to make a new subclass supporting the additional features, and then change all instances of the classes to this new class.

Implementations

The Cocoa frameworks are written in Objective-C, and hence Objective-C is the preferred language for development of Cocoa applications. Java bindings for the Cocoa frameworks (known as the "Java bridge") are also available but have not proven popular amongst Cocoa developers. Further, the need for runtime binding means many of Cocoa's key features are not available with Java. In 2005, Apple announced that the Java bridge was to be deprecated, meaning that features added to Cocoa in Mac OS X versions later than 10.4 would not be added to the Cocoa-Java programming interface.

Originally, Applescript Studio could be used to develop less complex Cocoa applications.^[4] However, as of Snow Leopard, it has been deprecated. It was replaced with ApplescriptObjC, which allows you to program in Applescript, while using Cocoa frameworks. ^[5]

Third-party bindings available for other languages include Clozure CL, LispWorks, PyObjC (Python), RubyCocoa (Ruby), CamelBones (Perl), Cocoa#, Monobjc (C#) and NObjective(C#).^[6] Nu uses the Objective-C object model directly, and therefore can use the Cocoa frameworks without requiring a binding.

There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, and Cocotron.

Notes

1. ^ [1] "Cocoa is an important inheritance from NeXT, as indicated by .. the "NS" prefix" - Mac OS X internals: a systems approach By Amit Singh, ISBN 0-321-27854-2
2. ^ Wikibooks - Some Objective-C advantages
3. ^ Key-Value Coding Programming Guide: Introduction
4. ^ "Applescript Studio Programming Guide (Legacy): About Applescript Studio". Apple, Inc.. http://developer.apple.com/legacy/mac/library/#documentation/AppleScript/Conceptual/StudioBuildingApps/chapter02/studio_about_book.html%23//apple_ref/doc/uid/20001249-TPXREF101. Retrieved 5 March 2011. 
5. ^ "ApplescriptObjC Release Notes". Apple, Inc.. http://developer.apple.com/library/mac/#releasenotes/ScriptingAutomation/RN-AppleScriptObjC/. Retrieved 5 March 2011. 
6. ^ more extensive list of implementations

References

• Aaron Hillegass: Cocoa Programming for Mac OS X, Addison-Wesley, 3rd Edition 2008, Paperback, ISBN 0-321-50361-9.
• Stephen Kochan: Programming in Objective-C, Sams, 1st Edition 2003, Paperback, ISBN 0-672-32586-1.
• Michael Beam, James Duncan Davidson: Cocoa in a Nutshell, O'Reilly, 1st Edition 2003, Paperback, ISBN 0-596-00462-1.
• Erick Tejkowski: Cocoa Programming for Dummies, 1st Edition 2003, Paperback, ISBN 0-7645-2613-8.
• Simson Garfinkel, Michael K. Mahoney: Building Cocoa Applications: A Step by Step Guide, O'Reilly, 1st Edition 2002, Paperback, ISBN 0-596-00235-1.
• James Duncan Davidson: Learning Cocoa with Objective-C, O'Reilly, 2nd Edition 2002, Paperback, ISBN 0-596-00301-3.
• Scott Anguish, Erik M. Buck, Donald A. Yacktman: Cocoa Programming, Sams, 1st Edition 2002, Paperback, ISBN 0-672-32230-7.
• Bill Cheeseman: Cocoa Recipes for Mac OS X, Peachpit Press, 1st Edition 2002, Paperback, ISBN 0-201-87801-1.
• Andrew Duncan: Objective-C Pocket Reference, O'Reilly, 1st Edition 2002, Paperback, ISBN 0-596-00423-0.
• Apple Inc.: Learning Cocoa, O'Reilly, 1st Edition 2001, Paperback, ISBN 0-596-00160-6.

External links

• Apple's Cocoa documentation
• iDevApps - Cocoa Programming Forum
• Cocoa Dev Central
• Cocoa Dev
• Cocodao - D/Cocoa bridge for creating Cocoa applications in D language