Con questo post vogliamo iniziare una serie di articoli più astratti sulla programmazione Cocoa, quasi un tutorial.

La programmazione in ambito nativo MacOSX si fonda su due pilastri: Objective-C e Cocoa Framework. Questo documento non si prefigge lo scopo di coprire lo studio particolareggiato di queste tecnologie (non potrebbe), ma di fornire un rapido accesso allo sviluppo software MacOSX.
Per poter governare la programmazione in ambito MacOSX occorre conoscere inoltre gli strumenti XCode, ivi compresa la componente Interface Builder per lo sviluppo delle interfacce grafiche (prima di Xcode 4 era una applicazione esterna).
La programmazione Objective-C è una programmazione multi-paradigma: l’Objective-C (da adesso objc) si fonda sul linguaggio C (programmazione procedurale) e costruisce su questo una sovrastruttura per il paradigma Object-Oriented (con l’introduzione di specifiche sintassi).
Per l’implementazione del paradigma ad oggetti, l’objc introduce un runtime environment che costituisce un “motore” (utilizzato da ogni applicazione costruita in objective-c) atto a realizzare la metafora dei messaggi e la componente dinamica del modello ad oggetti del linguaggio (polimorfismo, dynamic binding, ecc).

L’adozione del modello ad oggetti viene supportata da alcuni framework: primo tra tutti Foundation (Origina da NextStep Foundation library), responsabile della costruzione organica del modello a partire dalla classe NSObject.

• Tutte le classi di questo framework hanno nomi con prefisso “NS”, che intende ricordare l’origine in NextStep.

Nel contesto grafico MacOSX il principale framework adottato è Cocoa: questo estende Foundation con l’adozione di tutto un insieme di framework tematici. Anche in questo caso le classi hanno nomi con prefisso “NS”.
Il corollario di framework che costituiscono Cocoa si posizionano su diversi livelli di una gerarchia di astrazione delle componenti del S.O. e altro: ogni framework è dato per semplificare e riutilizzare un progetto relativo a situazioni specifiche (Core Audio, Core Graphics, Core Animation, Core Data, ecc).

• Le classi appartenenti a questi framework possono essere riconosciute sempre attraverso la convenzione dei prefissi, ma non in senso rigoroso (es. quelle Core Data hanno esempio prefisso “NS”, mentre Core Graphics ha “CG”).
• La forma dei prefissi è legata a fattori storici e gerarchici.

Tutti questi framework sono da riferirsi ad uno SDK relativo alla versione software del sistema operativo: un SDK ha un numero di versione pari al numero di versione del S.O. (es. SDK per Tiger è 10.4, per Leopard è 10.5, per Snow Leopard 10.6, per Lion 10.7, Mountain Lion 10.8, Mavericks 10.9).

API Compliance
Un’applicazione può essere compilata solo per uno specifico SDK (selezione che avviene nella configurazione del “target” in XCode); si può adottare una programmazione parametrica (ovvero con direttive condizionali di preprocessing) al fine di modellare il codice per applicare modifiche atte a compilare per specifico SDK e modulare le eventuali differenze rispetto ad un altro.

#if (MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5)
// codice per Leopard e oltre
#else
// codice pre-Leopard
#endif

ABI Compliance
Un’applicazione può essere invero compilata per architetture differenti (PPC vs Intel): questo è l’adozione dei concetti di Universal Binary.

• In questo caso Lion ha creato uno spartiacque: la soppressione di Rosetta e l’impossibilità di sviluppare codice per PPC ha impedito lo sviluppo in un unico progetto per più piattaforme.

Cocoa e GNUStep
GNUStep è una versione “open” di NextStep, e per questo ha molte similitudini con Cocoa.
Un codice realizzato in Cocoa è “riutilizzabile” in contesto GNUStep. Gli strumenti di sviluppo di GNUStep sono però gli originali Project Builder e Interface Builder di NextStep e divergono dunque per alcuni aspetti dalle novità introdotte da MacOSX e da XCode.
Riutilizzare il codice è possibile ma occorre riportarlo all’interno di un progetto GNUStep.
Il vincolo maggiore è il livello di compatibilità rispetto ai vari SDK disponibili nel mondo MacOSX: attualmente GNUStep è paragonabile a Panther, ossia 10.3. Un software calibrato per 10.4 oppure adottante framework particolari come Core Data, Core Audio o Core Animation, difficilmente saranno “portabili” nel mondo GNUStep.
Lo saranno solo se soluzioni a quelle differenze vengano prodotte dal progetto GNUStep stesso oppure in modo autonomo da chi sviluppa il software.

Cocoa runtime environment
Possiamo parlare di un vero e proprio runtime environment anche nel caso del framework Cocoa.
Il concetto di “applicazione” è proprio del framework, il quale offre un suo modello e una implementazione. In particolare il progetto riguardante il concetto di applicazione è parte dello specifico framework ApplicationKit.
Possiamo così leggittimamente parlare di “applicazioni Cocoa” contro “applicazioni BSD“, benchè in entrambi i casi si possa adottare objc e Foundation.
Cocoa suddivide il concetto di “applicazione” in due possibili modelli alternativi:

• applicazione
• applicazione basate su documento

Applicazione
Una applicazione incentrata su un ciclo di eventi che pongono in relazione gli elementi grafici presenti (finestre, menu, ecc).

Applicazione basata su document
Una applicazione il cui fulcro è un “gestore di documenti”; ciascun documento ha una propria finestra di interfaccia e una propria base dati di riferimento. Ciò che viene implementato in riferimento ad un documento astratto viene replicato (nei comportamenti) per ciascun docuento “aperto”.

Entry point di un programma Cocoa
Proprio in ragione della presa in carico da parte del framework del progetto “applicazione”, non esiste un “corpo principale del programma” come in altri ambienti di sviluppi.
Per tutte le applicazioni Cocoa si ha un unico “punti di inizio del programm” che è l’esecuzione della funzione NSApplicationMain(). Questo viene precostruito dal progetto modello in XCode.

int main(int argc, char *argv[])
{
return NSApplicationMain(argc,  (const char **) argv);
}

• Ovviamente è data la possibilità di interferire con le caratteristiche base dell’applicazione (intesa come flusso principale di programma) attraverso alcune classi di ApplicationKit (utilizzando metodi e attributi di classe specifici) e implementando una versione ad-hoc della funzione NSApplicationMain().

Classi che riguardano l’applicazione sono: NSApplication, NSBundle, NSApp.
La complessità dell’intera architettura è tale che non può essere ripercorsa da questo documento introduttivo.

Continua.