Cocoa (API)

aus Wikipedia, der freien Enzyklopädie
Cocoa
Basisdaten

Entwickler Apple, Inc.
Betriebssystem macOS
Kategorie Framework, Programmierschnittstelle
Lizenz Proprietär
deutschsprachig nein
developer.apple.com

Cocoa [ˈkoʊkoʊ] (englisch cocoa Kakao) ist eine objektorientierte Programmierschnittstelle zur Programmierung unter dem Betriebssystem macOS von Apple.

Cocoa-Programme sind meist solche mit einer graphischen Benutzeroberfläche (GUI), es ist aber auch die Entwicklung von z. B. Kommandozeilen-Tools oder Daemons möglich. Typischerweise erfolgt die Entwicklung mit Hilfe der „

Developer Tools

“, die im Wesentlichen aus IDE Xcode (Vorgänger: Project Builder) mit dem integrierten Interface Builder bestehen. Xcode kann kostenlos aus dem Mac App Store geladen werden oder – als registrierter Entwickler – auch von der Apple Developer Homepage.

Als primäre Programmiersprachen dienen dabei Objective-C und Swift; C++ und C sind grundsätzlich innerhalb eines Projektes verwendbar.[1] Alternativ ist die Programmierung (mit Einschränkungen) aus Java heraus möglich. Apple unterstützt jedoch die Java-Cocoa Bridge nicht mehr. Weiterhin existieren Cocoa-Schnittstellen für andere Sprachen, so etwa PerlObjCBridge (für Perl) oder die Open-Source-Projekte PyObjC (für Python) sowie RubyCocoa (für Ruby), FPC PasCocoa (für Lazarus und Free Pascal) und Cocoa# (für C# bzw. Mono). Seit der Mac OS X Tiger (10.4, 2005) nutzt das Cocoa-Framework Core Data die Datenbank SQLite. Die Mac-eigene Skriptsprache AppleScript kann genutzt werden, um einfache Aktionen und Routinen zu implementieren.

Geschichte

Cocoa war zunächst der Name für eine in Sk8 geschriebene Multimedia-Entwicklungsumgebung von Apple für Kinder, welche später vom Unternehmen Stagecast unter dem Namen Stagecast Creator weitergeführt wurde.

Das heutige Cocoa ist eine Weiterentwicklung der Programmierschnittstelle von NeXTStep, das vom Unternehmen NeXT in den späten 1980er Jahren entwickelt wurde. Dieses fand zunächst Anwendung im gleichnamigen Betriebssystem, das auf den hauseigenen Computern vertrieben wurde. Anfang der 1990er Jahre verabschiedete sich NeXT jedoch notgedrungen aus dem Hardwaregeschäft und das NeXTstep-API wurde als OpenStep auch auf anderen Systemen vertrieben. Ähnlich wie Java hätte ein OpenStep-Programm nativ auf vielen unterschiedlichen Betriebssystemen laufen können und wäre auf unterschiedlichen Prozessorarchitekturensource-code-kompatibel“ gewesen. OpenStep war nicht nur die Programmierschnittstelle von OPENSTEP, es wurde auch von Sun Microsystems für das eigene Betriebssystem Solaris (OpenStep für Solaris) und von NeXT für Windows NT (OPENSTEP Enterprise) als Aufsatz für das jeweilige Betriebssystem portiert.

Da OpenStep von NeXT und Sun als eine offene Spezifikation veröffentlicht worden war, konnte die API im GNUstep-Projekt auch für weitere Betriebssysteme nachprogrammiert werden.

1996 wurde NeXT von Apple gekauft, wo OpenStep in Yellow Box umbenannt, weiterentwickelt und weiterhin auch für Windows NT angeboten wurde. Yellow Box sollte die neue Programmierschnittstelle für das unter dem Namen Rhapsody entwickelte Nachfolgebetriebssystem vom klassischen Mac OS werden, doch die Anbieter von unverzichtbarer Anwendersoftware für Mac OS reagierten nach der Präsentation von Apples Plänen auf der WWDC 1997 zurückhaltend, da sie all ihre Programme unter großem Aufwand vom Macintosh-API auf Yellow Box hätten portieren müssen.

Nach der MacWorld 1998 wurde Yellow Box als betriebssystemübergreifende Programmierschnittstelle gemeinsam mit Rhapsody aufgegeben. Stattdessen wurde Yellow Box zur API des kommenden Betriebssystems Mac OS X, wo es in Cocoa umbenannt wurde. Damit bisherige Macintosh-Applikationen auch auf dem neuen Betriebssystem Fuß fassen konnten, wurde mit Carbon ein weiteres API eingeführt, das auf der Programmierschnittstelle des 1984 eingeführten „System“ genannten Macintosh-Betriebssystems (ab 1997 in Mac OS umbenannt) und dessen Toolbox-ROM basierte. Bestehende Mac-OS-Applikationen für System 7 und Mac OS 8 konnten so mit nur minimalen Anpassungen für Carbon neu kompiliert werden. Das Resultat konnte sowohl auf Mac OS X als auch auf Mac OS 8 und 9 nativ ausgeführt werden. Carbon und Cocoa sind jedoch nicht kompatibel und nur Cocoa bietet die Vorteile eines modernen Betriebssystems mit Speicherschutz, präemptiven Multitasking und Mehrprozessorfähigkeit. Die meisten Mac-Anwenderprogramme wurden daher im Laufe der 2000er Jahre vollständig von Carbon nach Cocoa portiert.

NeXTstep, OpenStep und Yellow Box sind die geschichtlichen Vorfahren der Cocoa-Programmierschnittstelle von macOS (der Name von Mac OS X/OS X seit 2016) und iOS. Mit GNUstep existiert eine vollständige OpenStep- und eine unvollständige Cocoa-API als quelloffene Nachprogrammierung.

Frameworks

Cocoa besteht aus drei Frameworks:

  • Foundation stellt alle relevanten Basisklassen (Strings, Arrays, Speicher-Management, Iterators etc.) zur Verfügung.
  • AppKit (früher Application Kit) enthält Klassen zur Entwicklung graphischer Benutzeroberflächen, beispielsweise Fenster, Buttons oder Menüs.
  • Core Data (seit Mac OS X Tiger, 10.4, 2005) zur Erstellung von Objektgraphen.

Die Klassen des Cocoa-Frameworks beginnen hauptsächlich mit den Buchstaben „NS“, wie beispielsweise bei NSObject, NSArray oder NSString, was für NeXTStep steht aus dem die gleichnamige API NeXTstep und später die OpenStep-Spezifikation hervorging.

macOS liefert weitere Frameworks mit, die aber keine direkten Bestandteile von Cocoa sind:

Diese Frameworks entsprechen in etwa dynamisch geladenen Objektbibliotheken (DLL/DSO), beinhalten jedoch im Gegensatz zu DLLs auch die Zugriffsmechanismen in Form von „Header-Dateien“. Sie stehen unter macOS als kompilierte Objektdateien zur Verfügung.

Foundation

Die Klassen der Foundation sorgen für eine Grundlage der Programmierung mit Objective-C. Enthalten sind vor allem:

  • Das Speicherverwaltungssystem Referenzzählung
  • Das Ausnahmesystem (NSException)
  • Die Basisklassen für grundlegende Typen wie für Zeichenketten, Werte und Daten
  • Collectionklassen für Mengen, Listen und Maps
  • Filebehandlung einschließlich webbezogener Funktionalität
  • XML-Unterstützung
  • Undo-Funktion

AppKit

AppKit implementiert die wichtigste Infrastruktur für Anwendungen, also Programme mit graphischer Benutzeroberfläche:

  • Applikationsinfrastruktur einschließlich Voreinstellungssystem
  • Ereignisbetrieb
  • Elemente der graphischen Oberfläche wie Fenster, Ansichten und Menüs
  • Elemente der Controllerschicht
  • Sprachanbindungen
  • Textsystem (Zeichenfolgen mit Attributen)

Core Data

Core Data stellt eine Modellierungs- und Persistenzschicht mit automatischer Unterstützung für Undo-Funktionalität dar. Es dient dem schnellen Entwurf von Modellen im System des Model-View-Controller-Musters. Core Data enthält Unterstützung für:

  • Beschreibung der Modellstruktur
  • Ablage von Daten
  • XML und SQLite

Konzepte

Cocoa verfolgt einige Konzepte, die auf die dynamische Struktur von Objective-C zugeschnitten sind. Dies dürfte auch der Grund sein, warum Java nicht mehr unterstützt wird. Aufgrund der statischen Struktur (Static-Typing, Early-Binding) von Java lassen sich die Strukturen von Cocoa dort nur eingeschränkt oder aber mit großem Aufwand umsetzen.

Model-View-Controller

Einerseits ist das MVC-Muster in Cocoa strikt umgesetzt, so dass sich die meisten Klassen eindeutig zuordnen lassen. Andererseits wird der hieraus folgende Aufwand durch Unterstützung gelindert. So erlauben etwa Bindings die automatische Synchronisation von Modelwerten in allen relevanten Views, ohne dass der Anwendungsprogrammierer hierzu Code schreiben muss.

Class-Cluster

Einige Klassen von Cocoa stellen nur den sichtbaren Teil des Eisberges dar. Tatsächlich werden sie nie instanziert, sondern vielmehr zur Laufzeit Instanzen passender, jedoch verborgener Subklassen erzeugt. So verlangt etwa der Anwendungsprogrammierer nach einer Instanz von NSArray, erhält aber je nach Anzahl der Elemente eine Instanz einer Klasse, die er nicht kennt.

Laziness

Grundsätzlich werden das System belastende Tätigkeiten erst dann vorgenommen, wenn diese erforderlich sind. So modellieren Instanzen der Klasse „NSImage“ Bilder. Die Bilddaten werden allerdings erst dann geladen, wenn sie für eine Operation tatsächlich bekannt sein müssen; das Model wird erst dann und nur insoweit geladen, wie es für die aktuelle Operation nötig ist usw.

Ereignisbetrieb und Responder-Chain

Cocoa-Applikationen sind strikt ereignisgesteuert. Jede Tätigkeit einer Anwendung erfolgt aufgrund eines äußeren Ereignisses. Ereignisse durchlaufen eine sogenannte "Responder-Chain", deren Glieder Objekte unterschiedlicher Klassen sind. Jedes dieser Glieder kann ein eingetroffenes Ereignis entnehmen und beantworten oder aber an das nächste Glied weiterleiten.

Implementierungen außerhalb von Mac OS X/OS X/macOS

Neben der in Mac OS X/OS X/macOS enthaltenen Cocoa-API von Apple gibt es auch eine freie, plattformübergreifende Implementierung namens GNUstep. Diese Nachbildung dient dazu, Anwendungsprogramme für Mac OS X ohne großen Aufwand für andere Betriebssysteme zu portieren. Das Ausführen von für Mac OS X kompilierten Anwendungen ist, anders als bei Windows-Anwendungen unter Wine, meist nicht möglich. GNUstep enthält nicht alle Funktionen von Cocoa,[2] was eine einfache Portierung erschweren kann. Besonders wenn die Anwendungen neben Cocoa auf andere APIs von Mac OS X, wie zum Beispiel Carbon angewiesen sind, kann die Portierung trotz GNUstep sehr aufwendig werden.[2] Da Mac OS X selbst ein unixoides System ist, ist die Umsetzung von GNUstep in Linux- und Unix-Systemen einfacher und schlanker als in Windows, wo zuerst mit MinGW die nötige minimale Unix-artige Funktionalität bereitgestellt werden muss.[3]

Literatur

Weblinks

Einzelnachweise

  1. Mixing Objective-C and C++ Language Features (Memento vom 23. April 2009 im Internet Archive)
  2. a b Porting from GNUstep to Cocoa. gnustep.org, 27. Mai 2010 (englisch).
  3. Platform compatibility. gnustep.org, 27. Mai 2010 (englisch).