Carbon vs Cocoa

Dopo aver fatto una breve introduzione sulla gestione della memoria nel vecchio Mac OS e aver conosciuto il padre delle API Mac, la famosa Macintosh Toolbox, passiamo ora a una delle parti fondamentali di OS X, ovvero Carbon.

INDICE:
- Introduzione
- Tecnologie complementari
- Architettura di Carbon
- Event Handling prima e dopo
- Conclusioni

INTRODUZIONE
Le API Carbon sono una raccolta (da qui quindi il termine API che sta appunto per Application Programming Interface) di funzioni procedurali (quindi scritte senza utilizzare la metodologia orientata agli oggetti) che permettono anche di avere uno strato di compatibilità nativa tra le applicazioni Mac OS 9 e Mac OS X. Carbon è una delle cinque API principali disponibili sotto Mac: le altre sono Cocoa, la Toolbox (che è riservata soltanto alle applicazioni non native e viene caricata direttamente da Classic), POSIX (utilizzata per l'ambiente BSD Unix) e Java (questa purtroppo da poco dismessa).
Altri ambienti come Perl o Python sono considerati minori poichè non utilizzati per applicazioni medio grandi.

Le API Carbon sono pubblicate e rese accessibili attraverso headers C e come libreria linkata dinamica (chiamata CarbonLib). L'implementazione delle API è differente nei due sistemi soltanto a livello di codice eseguibile permettendo l'esecuzione nativa senza modifiche del codice attraverso i due sistemi operativi.
Senza Carbon le applicazioni infatti dovrebbero girare all'interno dell'ambiente Classic di Mac OS X.
Con l'arrivo di Mac OS X Apple ha cercato di inserire quante più API possibili della Toolbox dentro Carbon, al fine di permettere un porting abbastanza indolore (il processo di porting è stato chiamato Carbonization, ovvero carbonizzazione).
Inoltre il team di ingegneri Apple ha inserito molte funzioni aggiuntive al fine di colmare alcune lacune riscontrate col vecchio set. Molte strutture dati ad esempio si sono avvicinate per quanto possibile al concetto di OOP permettendo la manipolazione delle informazioni soltanto tramite API dedicate. Questo ha permesso quindi di ottenere un codice meno incline ad errori.
Mentre molte API sono state aggiunte, altre sono state rimosse perchè troppo obsolete o perchè hanno perso di senso. A seconda del sistema operativo quindi è possibile usare e non usare particolari funzioni dedicate.

Carbon di per se è nato per fornire una transizione indolore per tutti quei grandi software per cui il costo di sviluppo da zero con i nuovi tool di sistema avrebbe avuto dei costi proibitivi (parliamo quindi di programmi il cui codebase è vecchio di diversi anni, come i prodotti Adobe). Tuttavia l'impossibilità di convertire tutto il codice verso le nuove API di sistema ha fatto si che Carbon si tramutasse da fase temporanea a vera e propria parte del sistema.
A volte si è portati a dire che se un software è scritto in Carbon allora è più lento, o più brutto o addinittura non nativo.
Questo è un mito che va assolutamente sfatato. Ad esempio lo stesso set di API Cocoa utilizza alcune funzioni a basso livello di Carbon (questo perchè già esistenti e testate o addinittura unica via visto l'impossibilità di utilizzare l'approccio Cocoa in alcuni ambiti).

TECNOLOGIE COMPLEMENTARI
Carbon e Cocoa sono per molti versi tecnologie complentari e non avversarie, in generale usate per risolvere problemi differenti. Parlando in maniera superficiale possiamo dire che Carbon è un set di API per funzioni a basso livello, mentre Cocoa permette un controllo a più alto livello.
Molte applicazioni fanno uso entrambe le tecnologie insieme quindi il loro utilizzo all'interno di un programma non è affatto esclusivo. Se si ha esigenza di lavorare con strutture dati accessibili con C,C++,Pascal o Ada Carbon è sicuramente la scelta migliore; questo perchè Cocoa utilizza esclusivamente ObjC e Java (benchè col 10.3 è possibile utilizzare anche un mix di C++ e ObjectiveC).
Nel corso degli anni si è cercato di offrire un approccio a più alto livello con Carbon; sono quindi nati framework di interfacciamento come MacApp, PowerPlant o MacZoop. Questi sono tutti tentativi (i primi due hanno avuto talmente tanto successo da essere utilizzate anche dalle più grandi aziende di software) di portare a un livello più alto Carbon senza dover sempre reinventare la ruota.

ARCHITETTURA DI CARBON
Descriviamo ora l'architettura di Carbon.
Come già detto Carbon deriva dalla Macintosh Toolbox. Esso è composto quindi da diverse categorie per ogni esigenza; ogni categoria è chiamata Manager. Un Manager definisce un set di API, strutture dati e funzioni per manipolare determinate situazioni. Molti manager sono interdipendenti tra loro o inseriti in una struttura a layer (layered).
Le ultime parti di Carbon hanno risentito dell'avvento dell'OOP quindi sono molto più orientate agli oggetti (molte delle quali basate su Core Foundation). Benchè alcune API, come HIView Manager, sono state scritte in C++, la maggior parte di Carbon rimane scritta in linguaggio C.

Esistono molti Carbon Manager: File Manager (per l'accesso al file system e ad i suoi elementi), Resource Manager (per l'accesso alle risorse come icone, immagini, template etc), Font Manager (per la gestione dei font; attualmente Font Manager è stato deprecato da Mac OS X 10.4 in favore di ATS; Font Manager era parte di QuickDraw, anch'esso deprecato), QuickDraw (per la gestione delle primitive grafiche; rimpiazzato da Quartz 2D), Quartz (solo per Mac OS X), Carbon Event Manager (permette di converitre le azioni utente e l'attività di sistema in eventi ai quali è possibile associare determinate azioni), HIObject (è probabilmente la parte più moderna di Carbon; grazie a HIObject i programmatori possono utilizzare Carbon in maniera più object oriented sfruttando anche Interface Builder e i vantaggi messi a disposizione da classi come NSObject), HITheme-HIView Manager (introdotto con Mac OS X 10.3 permette di avere uno strato di compatbilità con il vecchio Appearance Manager e consente la visualizzazione tramite Quartz degli elementi a video), Window Manager (per gestire la visualizzazione e le operazioni sulle finestre), Menu Manager (per i menu).

EVENT HANDLING PRIMA E DOPO
Parliamo ora di come Carbon cattura gli eventi della macchina.
La Toolbox originale utilizzava un meccanismo di gestione degi eventi a polling: un main loop (ciclo) separato per ogni applicazione (e quindi gestito da essa) si occupava di interrogare periodicamente l'Event Manager in attesa di eventi in coda da gestire o ignorare, a seconda delle esigenze (viene chiamato callback manager e in alcuni casi è ancora utilizzato da vecchie applicazioni).
Il meccanismo di polling, alla base del vecchio Mac OS, ha funzionato bene fintanto che una sola applicazione alla volta poteva utilizzare la CPU. In un sistema di tipo preemptive-scheduled come Mac OS X, questa tecnica risulta invece altamente inefficente alternando dei momenti di grande traffico di eventi ad altri (busy-waiting o attesa in lavoro).

Carbon in questo senso ha introdotto un nuovo sistema, il Carbon Event Manager che mette a disposizione un event loop proprio. Ogni applicazione si registra quindi gli eventi che intende ricevere e quindi gestire.
Carbon stesso mette a disposizione il concetto di timer di eventi che gira fuori dal main loop e che permette di gestire più facilmente eventi a intervalli di tempo definiti.

CONCLUSIONI
In conclusione Carbon quindi non deve essere messo in diretta contrapposizione con Cocoa, poichè sono entrambi complementari, utilizzati a volte per scopi diversi e comunque facenti parti entrambi del cuore dell'OS stesso. Molte applicazioni tra le quali Final Cut, iTunes, Mail ed altre ancora utilizzano entrambi i framework a seconda delle esigenze; definire quindi una applicazione Cocoa o Carbon può avere un senso fino ad un certo limite e comunque non dà ne l'idea della bontà ne la velocità della stessa. Il mito di Cocoa contro Carbon persiste nel tempo e agli anni; con questo primo articolo ho cercato di dare una prima introduzione a Carbon ma senza entrare nel merito della stravagante "competizione" tra framework.
Nella prossima puntata entreremo più nel merito del discorso per poi passare a descrivere Cocoa.