| Cocoa | |
|---|---|
| Developer | Apple Inc. |
| Written in | C,C++,Objective-C,Swift |
| Operating system | macOS |
| Type | Software framework |
| License | Proprietary with some open source components[citation needed] |
| Website | Apple Developer |
Cocoa isApple's nativeobject-orientedapplication programming interface (API) for itsdesktopoperating systemmacOS.
Cocoa consists of theFoundation Kit,Application Kit, andCore Data frameworks, as included by theCocoa.h header file, and the libraries and frameworks included by those, such as the C standard library and the Objective-C runtime.[1]
Cocoa applications are typically developed using the development tools provided by Apple, specificallyXcode (formerlyProject Builder) andInterface Builder (now part of Xcode), using theprogramming languagesObjective-C orSwift. However, the Cocoa programming environment can be accessed using other tools. It is also possible to write Objective-C Cocoa programs in a simpletext editor and build it manually withGNU Compiler Collection (GCC) orClang from the command line or from amakefile.
Forend users, Cocoaapplications are those written using the Cocoa programming environment. Such applications usually have a familiar look and feel, since the Cocoa programming environment provides a lot of commonUI elements (such as buttons, scroll bars, etc.), and automates many aspects of an application to comply with Apple'shuman interface guidelines.
ForiOS,iPadOS,tvOS, andwatchOS, APIs similar to Application Kit, namedUIKit and WatchKit, are available; they includegesture recognition,animation, and a different set ofgraphical control elements that are designed to accommodate the specific platforms they target. Foundation Kit and Core Data are also available in those operating systems. It is used inapplications for Apple devices such as theiPhone, theiPod Touch, theiPad, theApple TV, and theApple Watch.
Cocoa continues the lineage of severalsoftware frameworks (mainly theApp Kit andFoundation Kit) from theNeXTSTEP andOpenStep programming environments developed byNeXT in the 1980s and 1990s. Apple acquired NeXT in December 1996, and subsequently went to work on theRhapsody operating system that was to be the direct successor ofOPENSTEP. It was to have had an emulation base forclassic Mac OS applications, namedBlue Box. The OpenStep base of libraries and binary support was termedYellow Box. Rhapsody evolved into Mac OS X, and the Yellow Box became Cocoa. Thus, Cocoa classes begin with the lettersNS, such as NSString or NSArray. These stand for the original proprietary term for the OpenStep framework, NeXTSTEP.[2]
Much of the work that went into developing OpenStep was applied to developing Mac OS X, Cocoa being the most visible part. However, differences exist. For example, NeXTSTEP and OpenStep usedDisplay PostScript for on-screen display of text and graphics, while Cocoa depends on Apple'sQuartz (which uses thePortable Document Format (PDF) imaging model, but not its underlying technology). Cocoa also has a level of World Wide Web support, including the NSURL andWebKitHTML classes, and others, while OpenStep had only rudimentary support for managed network connections via NSFileHandle classes andBerkeley sockets.
The API toolbox was originally called “Yellow Box” and was renamed to Cocoa - a name that had been already trademarked by Apple. Apple'sCocoa trademark had originated as the name of a multimedia project design application for children. The name was intended to evoke "Java for kids", as it ran embedded in web pages.[3] The original "Cocoa" program was discontinued following the return ofSteve Jobs to Apple. At the time, Java was a big focus area for the company, so “Cocoa” was used as the new name for “Yellow Box” because, in addition to the native Objective-C usage, it could also be accessed from Java via a bridging layer.[4] Even though Apple discontinued support for the Cocoa Java bridge, the name continued and was even used for theCocoa Touch API.
One feature of the Cocoa environment is its facility for managing dynamically allocated memory.Foundation Kit's NSObject class, from which most classes, both vendor and user, are derived, implements areference counting scheme for memory management. Objects that derive from the NSObject root class respond to aretain and arelease message, and keep a retain count. A method titledretainCount exists, but contrary to its name, will usually not return the exact retain count of an object. It is mainly used for system-level purposes. Invoking it manually is not recommended by Apple.
A newly allocated object created withalloc orcopy has a retain count of one. Sending that object aretain message increments the retain count, while sending it arelease message decrements the retain count. When an object's retain count reaches zero, it is deallocated by a procedure similar to a C++destructor.dealloc is not guaranteed to be invoked.
Starting with Objective-C 2.0, the Objective-C runtime implemented an optionalgarbage collector, which is now obsolete and deprecated in favor ofAutomatic Reference Counting (ARC). In this model, the runtime turned Cocoareference counting operations such as "retain" and "release" intono-ops. The garbage collector does not exist on theiOS implementation of Objective-C 2.0. Garbage collection in Objective-C ran on a low-priority background thread, and can halt on Cocoa's user events, with the intention of keeping the user experience responsive. The legacy garbage collector is still available on Mac OS X version 10.13, but no Apple-provided applications use it.
In 2011, theLLVM compiler introducedAutomatic Reference Counting (ARC), which replaces the conventional garbage collector by performing static analysis of Objective-C source code and inserting retain and release messages as necessary.
Cocoa consists of threeObjective-C object libraries calledframeworks. Frameworks are functionally similar toshared 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 ofbundle, containing the aforementioned items in standard locations.
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 thePortable Document Format (PDF) drawing model provided byQuartz. This allows creating custom drawing content usingPostScript-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 on the unique aspects of an application's content.
TheSmalltalk teams atXerox PARC eventually settled on a design philosophy that led to easy development and high code reuse. Namedmodel–view–controller (MVC), the concept breaks an application into three sets of interacting object classes:
Cocoa's design is a fairly, but not absolutely 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. No stock class 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 theCocoa Bindings system, which also makes extensive use of protocols such asKey-Value Observing andKey-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 theCore 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 when necessary, saving data to disk, and reading it back in.
In providing framework support for all three MVC domains, 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.
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 specificcommand handling classes are needed, usually organized according to thechain-of-responsibility pattern. While Cocoa retains this approach for the most part, Objective-C'slate binding opens up more flexibility.
Under Objective-C, methods are represented by aselector, a string describing the method to call. When a message is sent, the selector is sent into the Objective-C runtime, matched against a list of available methods, and the method'simplementation is called. Since the selector is text data, this lets it 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,[6] but late binding allows the same selector to reference different implementations.
By a similar token, Cocoa provides a pervasive data manipulation method calledkey-value coding (KVC).[7] This allows 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. In traditional languages, this late binding is impossible. KVC leads to great design flexibility. An object's type need not be known, yet any property of that object can be discovered using KVC. Also, by extending this system using something Cocoa termskey-value observing (KVO), automatic support forundo-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 orvirtual).
One of the most useful features of Cocoa is the powerfulbase objects the system supplies. As an example, consider the Foundation classesNSString andNSAttributedString, which provideUnicodestrings, and theNSText 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 professionaltypography features such askerning,ligatures, running text around arbitraryshapes,rotation, full Unicode support, andanti-aliasedglyph 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 system-wide set of language dictionaries. 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 towards zero.When extensions are needed, Cocoa's use of Objective-C makes this a straightforward task. Objective-C includes the concept of "categories," which allows modifying 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. In other common languages, this same task requires deriving a new subclass supporting the added features, and then replacing all instances of the original class with instances of the new subclass.
The Cocoa frameworks are written inObjective-C. Javabindings for the Cocoa frameworks (termed theJava bridge) were also made available with the aim of replacing Objective-C with a more popular language[8] but these bindings were unpopular among Cocoa developers and Cocoa's message passing semantics did not translate well to a statically-typed language such as Java.[9] Cocoa's 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 macOS versions later than 10.4 would not be added to the Cocoa-Java programming interface.
AtApple Worldwide Developers Conference (WWDC) 2014, Apple introduced a new programming language namedSwift, which is intended to replace Objective-C.[10]
Originally, AppleScript Studio could be used to develop simpler Cocoa applications.[11] However, as of Snow Leopard, it has been deprecated. It was replaced with AppleScriptObjC, which allows programming inAppleScript, while using Cocoa frameworks.[12]
The Cocoa programming environment can be accessed using other tools with the aid ofbridge mechanisms such asPasCocoa,PyObjC,CamelBones,RubyCocoa, and aD/Objective-C Bridge.
Third-party bindings available for other languages includeAppleScript,Clozure CL,Monobjc andNObjective (C#),Cocoa# (CLI), Cocodao andD/Objective-C Bridge,[13][14]LispWorks,Object Pascal,CamelBones (Perl),PyObjC (Python),FPC PasCocoa (Lazarus andFree Pascal),RubyCocoa (Ruby).[15]
A Ruby language implementation namedMacRuby, which removes the need for a bridge mechanism, was formerly developed by Apple, whileNu is aLisp-like language that uses theObjective-C object model directly, and thus can use the Cocoa frameworks without needing a binding.
There are also open source implementations of major parts of the Cocoa framework, such asGNUstep and Cocotron,[16] which allowcross-platform Cocoa application development to target other operating systems, such asMicrosoft Windows andLinux.
Cocoa is an important inheritance from NeXT, as indicated by .. the "NS" prefix
Because Java is a strongly typed language, it requires more information about the classes and interfaces it manipulates at compile time. Therefore, before using Objective-C classes as Java ones, a description of them has to be written and compiled.
