|
|
Lexikon auf Ihrer Homepage |
|
Lexikon als Lesezeichen hinzufügen |
Cocoa [ˈkoʊkoʊ] (engl. für „Kakao“) ist eine objektorientierte Programmierschnittstelle zur Programmierung unter dem Betriebssystem Mac OS X von Apple.
Cocoa-Programme sind meist solche mit einer graphischen Benutzeroberfläche (GUI), wobei ebenso auch die Entwicklung von z. B. Kommandozeilen-Tools oder Daemons möglich ist. Typischerweise erfolgt die Entwicklung mit Hilfe der „Developer Tools“, die Apple nach namentlicher Registrierung bis zur Version 3.2 kostenfrei zur Verfügung gestellt hat und die im Wesentlichen aus der IDE Xcode (Vorgänger: Project Builder) und dem Interface Builder bestehen. Version 4.0 von Xcode musste für 3,99 EUR im Mac App Store geladen werden. Als kostenpflichtig registrierter Entwickler kann Xcode von der Apple Developer Homepage heruntergeladen werden, wobei keine weiteren Kosten entstehen. Seit dem Erscheinen von Mac OS 10.7 ist Xcode kostenlos über den Mac App Store zu beziehen.
Als primäre Programmiersprache dient dabei das an Smalltalk angelehnte Objective-C (eine objektorientierte Obermenge von C); C/C++ ist grundsätzlich innerhalb eines Projektes verwendbar[1]. Alternativ ist die Programmierung (mit Einschränkungen) aus Java heraus möglich. Insbesondere wird die Java-Cocoa Bridge von Apple nicht mehr unterstützt. Weiterhin existieren Schnittstellen, um Cocoa aus anderen Sprachen zu nutzen, so etwa PerlObjCBridge (für Perl) oder die Open-Source-Projekte PyObjC (für Python) sowie RubyCocoa (für Ruby) und Cocoa# (für C# bzw. Mono). In der Betriebssystem-Version 10.4 enthält Cocoa sogar eine kleine Datenbank (SQLite). Die Mac-eigene Skriptsprache Apple Script kann genutzt werden, um einfache Aktionen und Routinen zu implementieren.
Inhaltsverzeichnis |
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 von NeXTSTEP und OPENSTEP, das vom Unternehmen NeXT in den späten 1980er Jahren entwickelt wurde.
Nach Erscheinen einer Betaversion von Safari für Windows im Juni 2007 kamen Gerüchte auf[2], dass Apple (wieder) an einer Portierung von Cocoa auf die Windows-Plattform arbeitet.
Cocoa besteht aus seinerseits drei Frameworks:
Die Klassen des Cocoa-Frameworks beginnen hauptsächlich mit den Buchstaben NS, wie beispielsweise bei NSObject, NSArray oder NSString. Die Abkürzung steht dabei für das OpenStep-Framework NeXTStep, das von Apple 1996 zugekauft und als Basis für Mac OS X verwendet wurde.
Mit Mac OS X werden allerdings noch weitere Frameworks geliefert, 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 Mac OS X als kompilierte Objektdateien zur Verfügung. Die meisten der Frameworks, aus denen Cocoa besteht, wurden von Apple bislang noch nicht im Quelltext freigegeben.
Die Klassen der Foundation sorgen für eine Grundlage der Programmierung mit Objective-C. Enthalten sind vor allem:
AppKit implementiert die wichtigste Infrastruktur für Anwendungen, also Programme mit graphischer Benutzeroberfläche:
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:
Cocoa verfolgt einige Konzepte, die auf die dynamische Struktur von Objective-C zurechtgeschnitten 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.
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.
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.
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.
Cocoa-Applikationen sind strikt ereignisgesteuert. Jede Tätigkeit einer Anwendung erfolgt aufgrund eines äußeren Ereignisses. Ereignisse durchlaufen eine sogenannte "Responder-Chain", die aus unterschiedlichen Klassen besteht und ein eingetroffenes Ereignis entnehmen und verarbeiten können – oder auch nicht.
Neben der in Mac OS X enthaltenen Cocoa-API von Apple gibt es auch eine freie, plattformübergreifende Implementierungen 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,[3] was die 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.[3] 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.[4]