A Cocoa ( angolul - " cocoa ") egy objektum-orientált API a macOS operációs rendszerhez az Apple -től . Ez egyike a Mac OS X-ben elérhető öt fő API -nak – Cocoa, Carbon , Toolbox (régebbi Mac OS 9 alkalmazások futtatásához ), POSIX és Java . Az olyan nyelvek, mint a Perl , a Python és a Ruby nem számítanak nagyobb nyelveknek, mivel még nem sok komoly alkalmazás íródott rájuk a Mac OS X rendszerre.
A Cocoát használó alkalmazásokat általában az Apple Xcode fejlesztői környezetével (korábbi nevén Project Builder ) és az Interface Builder programozási nyelvekkel fejlesztik : C , Objective-C és Swift . A Cocoa környezet azonban akkor is elérhető, ha más nyelveken, például Ruby -n , Python -on és Perl -en fejlesztenek a linkkönyvtárak használatával ( MacRuby , PyObjC és CamelBones ). Az Objective-C Cocoa programokat normál szövegszerkesztőben is lehet írni, és manuálisan lefordítani GCC vagy GNUstep makescriptek használatával .
A végfelhasználó szempontjából a Cocoa alkalmazások a Cocoa programozási környezettel írt alkalmazások. Az ilyen alkalmazások általában jellegzetes megjelenést és hatást mutatnak, mivel ez a környezet sokkal könnyebbé teszi az Apple emberi interfész irányelveinek támogatását.
A Cocoa a NeXTSTEP és az OPENSTEP szoftverkörnyezetek folytatása, amelyeket a NeXT fejlesztett ki az 1980-as évek végén. Az Apple 1996 decemberében felvásárolta a NeXT-et, és elkezdett dolgozni a Rhapsody operációs rendszeren , amely az OPENSTEP közvetlen utódja lett volna. Azt kellett volna tartalmaznia az úgynevezett "Blue Box" ( Blue Box ), hogy emuláció Mac OS alkalmazások . Az OPENSTEP végrehajtható fájlformátum könyvtáralapját és támogatását "Yellow Box"-nak ( Yellow Box ) nevezték el. A Rhapsody Mac OS X-vé fejlődött, és a Yellow Box-ból Cocoa lett. Ennek eredményeként a Cocoa osztályok nevei NS betűkkel kezdődnek (a NeXTStep [1] esetén): NSString, NSArray stb.
Az OPENSTEP-hez írt kódok nagy része a Cocoa és a Mac OS X rendszerbe került, de vannak eltérések. Például a NeXTSTEP és az OPENSTEP a Display PostScript technológiát használta a szöveg és a grafika képernyőn való megjelenítésére , míg a Cocoa az Apple Quartz rendszerét (amely ugyanazt a képalkotási modellt használja, mint a PDF ). Ezenkívül a Cocoa támogatja az internetet, például az NSURL osztályt és a WebKit osztályokat a HTML -lel való munkához , míg az OPENSTEP csak korlátozott mértékben támogatja az NSFileHandle osztályt és a Berkeley socketeket használó hálózati kapcsolatokat.
Korábban a "Cocoa" márkanevet egy olyan alkalmazás neveként használták, amely lehetővé teszi a gyermekek számára, hogy multimédiás projekteket hozzanak létre. Az eredetileg KidSim néven ismert alkalmazás jelenleg egy harmadik fél tulajdonában van, és Stagecast Creator néven védi . A program támogatásának megszüntetése a Steve Jobs Apple-hez való visszatérését követő racionalizálással összhangban történt . A régi nevet újra felhasználták, hogy elkerüljék az új védjegy bejegyzési késedelmét, és a Stagecast beleegyezett, hogy a korábbi Cocoa-t az új néven fejleszti.
A Cocoa környezet egyik jellemzője a dinamikusan lefoglalt memória kezelésére szolgáló mechanizmus. Az NSObject osztály, amelyből a legtöbb Cocoa osztály – mind a szabványos, mind az egyedi – származik, referenciaszámláló mechanizmust valósít meg a memóriakezeléshez . Az NSObject-ből származó objektumok válaszolnak az üzenetekre retain, és releasetárolják a hivatkozási számot, amelyet az objektumnak küldött üzenettel találhatunk meg retainCount. allocA vagy metódusokkal újonnan létrehozott objektumok copyreferenciaszáma egy. Üzenet küldése egy objektumnak retainnöveli a hivatkozások számát, üzenet küldése pedig release csökkenti. Amikor a referenciaszám eléri a nullát, az objektum törlődik, és az általa elfoglalt memória felszabadul (az Objective-C objektumok memóriafelosztása ugyanaz, mint a destruktor meghívása C++ objektumoknál. A metódus deallocnagyjából ugyanazt teszi, mint a destruktor C++-ban. hívás nem garantált.). Ez a referencia-számlálási megközelítés nagyon hasonlít a Microsoft COM - jához az ismeretlen interfésszel . Az IUnknown a retainés a -hoz hasonló funkciókat biztosít . releaseAddRefRelease
A referenciaszámláláson kívül a programozók kihasználhatják az automatikus kiadási készleteket. Ha üzenetet küld autoreleaseegy objektumnak, az az objektumot az aktuális szál legközelebbi automatikus kiadási készletében regisztrálja a jövőbeni kiadáshoz. Amikor maga az automatikus kiadási készlet felszabadul, releaseminden korábban elküldött üzenetről üzenetet küld autorelease. Az automatikusan felszabadított készletek általában az üzenethurok elején és végén jönnek létre és feloldódnak, biztosítva, hogy a programvégrehajtás kilépjen abból a blokkból, amelyben az objektumokat az automatikus elosztáshoz regisztrálták. Ez azt jelenti, hogy az alkalmazás kiszámíthatóan fut, és a felhasználó számára átláthatóan szabadít fel memóriát, miközben az automatikus szemétgyűjtést alkalmazva a legtöbb esetben a program hirtelen nem reagál a felhasználói műveletekre, amikor elindul.
A Cocoa automatikus szemétgyűjtését az Objective-C 2.0 óta támogatja, amikor a Mac OS X 10.5 Leopard rendszerhez tartozó Xcode 3.0-ban fejlesztették ki. A programozónak most lehetősége van választani az automatikus és a kézi memóriakezelés között. A memóriakezelés leghatékonyabb módjáról megoszlanak a vélemények. Egyes programozók azzal érvelnek, hogy a referenciaszámlálás jobb, mert lehetővé teszi a fejlesztő számára, hogy pontosan szabályozza az objektumok felszabadítását anélkül, hogy a programban használt minden egyes objektumhoz manuálisan le kell foglalnia a memóriát, és nem okoz az automatikus működéshez kapcsolódó teljesítmény késéseket. szemétgyüjtés. Mások szerint ez az egész séma haszontalan, a Java stílusú automatikus szemétgyűjtés a legjobb megoldás, mivel nagyban csökkenti a programozói hibák valószínűségét a memóriával való munka során. A Cocoa szemétgyűjtése nem bontja meg a programok visszamenőleges kompatibilitását, csak kifejezetten vele összeállított projektekhez használják.
E két megközelítés kombinálható is. A modern szemétgyűjtők gyakran lehetővé teszik, hogy egy feladat közepén elindítsák és leállítsák magukat, így az alkalmazás szabályozhatja a rendszerhívásokra szánt időt. Úgy tűnik, hogy ennek a megközelítésnek az AppKit-készletekkel való kombinálása, amelyek automatikusan megjelennek az üzenethurok végén, kínálja a legjobb kompromisszumot. Hasonló rendszert sikeresen implementáltak a GNUstepben , a GNU OpenStep szabadon terjeszthető analógjában .
A Cocoa elsősorban két , Frameworks nevű Objective-C objektumkönyvtárból áll . A keretrendszerek nagyjából megegyeznek a dinamikus könyvtárakkal . Ezek olyan lefordított objektumok, amelyek futás közben betöltődnek a program címterébe, de ezen túlmenően a keretrendszerek erőforrásokat, fejlécfájlokat és dokumentációt tartalmaznak. A Cocoa tartalmaz egy verzióvezérlő rendszert is, amely megakadályozza a Microsoft Windows rendszerben előforduló problémákat (úgynevezett „ DLL pokol ”).
A Cocoa architektúra kulcseleme a nézetmodell. Külsőleg úgy van megszervezve, mint egy normál keretrendszer, de a Quartz által biztosított összes rajzolási művelethez PDF használatával valósítják meg . Ez lehetővé teszi a programozó számára, hogy bármit lerajzoljon egy PostScript -szerű nyelv parancsaival . Ezenkívül automatikusan lehetőséget biztosít bármilyen nézet nyomtatására. Mivel a Cocoa kezeli a vágást, görgetést, skálázást és más gyakori grafikai megjelenítési feladatokat, a programozó mentesül az alapul szolgáló infrastruktúra megvalósításától, és a fejlesztés alatt álló alkalmazás egyedi szempontjaira összpontosíthat.
A Xerox PARC Smalltalk programozóinak csapatai végül kidolgoztak egy filozófiát, amely lehetővé tette számukra, hogy leegyszerűsítsék a fejlesztést és jelentősen növeljék az újrafelhasználható kód mennyiségét. A Model-View-Behavior (MVC) paradigmaként ismert koncepció az alkalmazást három interakciós osztályra osztja. A modellosztályok adatokat, például dokumentumokat, beállítási fájlokat vagy objektumokat képviselnek a memóriában. A nézetek, ahogy a neve is sugallja, adatokat jelenít meg (gyakran vizuálisan). A viselkedésosztályok tartalmazzák azt a logikát, amely összekapcsolja a modelleket a megfelelő nézetekkel, és szinkronban tartja azokat.
A Cocoa architektúrában szigorúan betartják az MVC elveit. Az OpenStepben a legtöbb osztály vagy magas szintű reprezentáció (AppKit osztályok), vagy viszonylag alacsony szintű modellosztály (például NSString) volt. A hasonló MVC rendszerekhez képest az OpenStep nem rendelkezett erős modellbázissal. Például nem volt olyan alaposztály, amely egy dokumentumot képviselne. A Cocoa rendszerre való áttérés során a modellbázist hihetetlenül kibővítették, és több, használatra kész osztályt is tartalmaztak, amelyek a legtöbb felhasználói alkalmazásban közös funkcionalitást biztosítottak.
A Mac OS X 10.3-ban az Apple bemutatta az NSController-t, az MVC osztályok családját, amelyek szabványos viselkedési funkciókat biztosítanak. Ezeket az osztályokat a Cocoa Bindings rendszer részének tekintik, amely széles körben használja az olyan protokollokat, mint a Key-Value Coding és a Key-Value Observing . A kötés kifejezés két tárgy, gyakran egy nézet és egy viselkedés összekapcsolását jelenti. A Cocoa Bindings lehetővé teszi a fejlesztő számára, hogy a program viselkedésének részletes leírása helyett az objektumok közötti kapcsolatok leírására összpontosítson.
A Mac OS X 10.4 kiadásával az Apple tovább bővítette az alapvető osztályokat a Core Data keretrendszer bevezetésével , amely automatizálja a modellek változásainak nyomon követését és elmentését (például fájlba). Ez a keretrendszer nagymértékben leegyszerűsíti az adatokkal való munkát az alkalmazásokban azáltal, hogy automatikus támogatást nyújt a dokumentumok fájlból történő olvasásához és fájlba mentéséhez, valamint a változtatások visszavonásához és visszaállításához szükséges architektúrákat.
Az MVC mindhárom rétegét támogató keretrendszerek biztosításával az Apple célja, hogy csökkentse a fejlesztőknek megírandó „ragasztó” kód mennyiségét, és így szabadítsa fel idejüket az alkalmazás-specifikus funkciók írására.
Az objektum-orientált nyelvekben, mint például a Java vagy a C++ , a metódushívások fizikailag mutatókként jelennek meg a memóriában. Ez korlátozza az alkalmazás tervezését, mert a meghívandó metódus nevét előzetesen ismerni kell. Míg a Cocoa többnyire megtartja ezt a megközelítést, az Objective-C késői kötése nagyobb rugalmasságot tesz lehetővé.
Az Objective-C-ben a metódusokat egy szelektor jelöli , amely egy karakterlánc, amely leírja a meghívott metódust. Amikor üzenetet küldenek egy objektumnak, az Objective-C környezet megkapja a talált szelektort, majd meghívja a szükséges metódust. Mivel a szelektor egy szöveges karakterlánc, fájlba menthető, hálózaton vagy folyamatok között továbbítható, vagy más módon feldolgozható. A metódus meghívásakor végrehajtott kód keresése futási időben történik, nem a program fordítási idején. Ez csak kismértékben lassítja a teljesítményt, de továbbra is lehetővé teszi, hogy ugyanaz a választó a módszer különböző megvalósításaira mutasson.
Hasonlóképpen, a Cocoa rendelkezik egy átfogó objektumtechnológiával, amelyet Key-Value Coding- nak (KVC) neveznek. Lehetővé teszi egy objektum adatelemének vagy tulajdonságának elérését, valamint futás közbeni módosítását név szerint – a tulajdonság neve kulcsként szolgál az értékéhez. A KVC rendkívüli tervezési rugalmassághoz vezet – nem kell tudni az objektum típusát, de a KVC segítségével bármely tulajdonsága megszerezhető. Ezenkívül a Key-Value Observing (KVO) nevű Cocoa technológia automatikusan szinkronizálja az egymáshoz kapcsolódó objektumok tulajdonságait.
Az egyik leghasznosabb dolog a Cocoa-val kapcsolatban a rendszer által biztosított erőteljes "alapobjektumok". Példaként tekintse meg az Alapítványt NSStringés az osztályokat NSAttributedString, amelyek támogatják a Unicode karakterláncokat, valamint az NSTextAppKit rendszerét, amely lehetővé teszi a programozó számára, hogy karakterláncokat jelenítsen meg egy grafikus felhasználói felületen.
NSTextés a kapcsolódó osztályok a karakterláncok megjelenítésére és szerkesztésére szolgálnak. Ezekkel az objektumokkal bármit megvalósíthat az alkalmazásban, a legegyszerűbb egysoros szövegbeviteli mezőtől az oldalszámozást és több oszlopot támogató elrendezésig, valamint olyan professzionális tipográfiai funkciókig, mint a bevágás , ligatúrák , szöveg tördelése bármilyen űrlap körül, szöveg forgatások, a Unicode és a betűsimítás teljes támogatása . A bekezdés tulajdonságait mind programozottan, mind a felhasználó a vonalzó objektum segítségével vezérelheti, amely bármely szöveget megjelenítő nézethez csatolható. A helyesírás-ellenőrzés automatikusan is elvégezhető, egyetlen szótár használatával az összes alkalmazáshoz, és a Microsoft által úttörő "szaggatott aláhúzással" (a Cocoa nyelven piros pontozott vonalnak tűnik). Van beépített támogatás a korlátlan visszavonáshoz és újrakészítéshez. Csak a beépített funkcionalitást használva 13 kódsorból lehet szövegszerkesztőt írni . Az új vezérlőobjektumokkal ez a sorszám nullára csökkenthető. Ez éles ellentétben áll a Mac OS korábbi verzióiban található TextEdit API-val.
Az Objective-C nagyon egyszerűvé teszi a meglévő osztályok funkcionalitásának bővítését. Támogatja az úgynevezett kategóriákat , amelyek lehetővé teszik a meglévő osztályok "helyben" módosítását. A kategóriák segítségével a szükséges funkcionalitást anélkül adhatjuk hozzá, hogy változtatásokat végeznénk rajtuk, sőt anélkül, hogy egyáltalán hozzáférnénk a meglévő osztályok forráskódjához. Más elterjedtebb nyelveken ez megköveteli a programozótól, hogy hozzon létre egy új osztályt, amely támogatja a további funkciókat, majd gondosan lecseréli a szülőosztály összes használt objektumát erre az újra.
A Cocoa keretrendszerek Objective-C nyelven íródnak, ezért ez a nyelv a választott nyelv a Cocoa alkalmazások írásához. A Java nyelvhez csomag (Cocoa-Java Bridge) is elérhető, amely azonban nem túl népszerű a fejlesztők körében. Ezenkívül a késői kötés használata azt jelenti, hogy a Cocoa számos kulcsfontosságú funkciója nem használható a Java-ban. 2005 -ben az Apple bejelentette, hogy a Cocoa-Java megszűnik. Más szóval, a Mac OS X 10.4 utáni verzióiban a Cocoához hozzáadott funkciók nem kerülnek hozzáadásra a Cocoa-Java felülethez.
Az Xcode Tools-hoz mellékelt AppleScript Studio lehetővé teszi egyszerű Cocoa alkalmazások AppleScriptben való írását . A Cocoa számára létezik egy harmadik féltől származó szkriptnyelv, az F-Script is, amely közvetlen hozzáférést tesz lehetővé a Cocoa-objektumokhoz, és grafikus felhasználói felületet biztosít azok állapotának nyomon követéséhez.
Harmadik féltől származó csomagok más nyelveken is elérhetők: [2]
Ezenkívül a Cocoa alapvető részeinek ingyenes implementációi is rendelkezésre állnak, amelyek lehetővé teszik a többplatformos (beleértve a Windowst is ) alkalmazásfejlesztést:
Vannak olyan projektek, amelyek az Objective -C nyelven írt Cocoa alkalmazásokat JavaScript webalkalmazásokká fordítják :
| Mac operációs rendszer | |
|---|---|
| Alkalmazások | |
| segédprogramok |
|
| Technológia és felhasználói felület |
|
| GUI elemek eszközkészletei (készletei) . | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| alacsony szintű |
| ||||||||||||||||||||||||||
| magas szintű |
| ||||||||||||||||||||||||||