Abbiamo terminato nel precedente articolo di vedere la struttura delle app iOS. Passiamo ad nuovo argomento: è importante conoscere bene la differenza tra framework e librerie, sopratutto rispetto al contesto in cui siamo entrati approfondendo e analizzando i sistemi operativi. Cosa sono i framework? E le librerie?
Framework
Un componente chiave da conoscere in macOS sono i framework, cioè dei bundle, costituiti da una o più librerie condivise, con i relativi file di supporto.
Sono molto simili alle librerie (hanno lo stesso formato binario), ma sono univoci e non sono portabili. Inoltre, non sono considerati parte di Darwin: al contrario dei componenti di Darwin, che sono tutti open source, Apple mantiene la maggior parte dei framework chiusi, non disponibili al pubblico. Il motivo è semplice, essi forniscono l’interfaccia grafica di macOS congiuntamente ad altre funzioni avanzate offerte esclusivamente dal sistema operativo di casa Apple, quindi l’interesse è mantenere questa conoscenza privata.
Le librerie “tradizionali” sono ancora presenti (e di fatto, forniscono le basi su cui sono implementate le strutture) ma i framework, tuttavia, forniscono un’interfaccia runtime completa e, soprattutto in Objective-C, servono a nascondere la parte ‘complessa’ del sistema e le API della librerie.
Abbiamo detto che i framework sono dei bundle, proprio come le applicazioni: tuttavia questo tipo d i bundle è leggermente diverso rispetto a quello delle applicazioni. La differenza chiave risiede nel meccanismo di controllo delle versioni integrato; un framework contiene una o più versioni del codice, che possono vivere contemporaneamente affiancate in sottodirectory separate, come Versione/A, Versione/B e così via. Per scegliere una versione preferita di un framework basta creare un collegamento simbolico chiamato current. . Sebbene la maggior parte dei framework abbia una sola versione (di solito A, ma a volte B o C), con questo modus operandi si estende la compatibilità sia in avanti che indietro nelle varie versioni.
Sia macOS che iOS supportano lo switch delle versioni grazie al flag -framework che consente di includere versioni sia fornite da Apple sia derivanti da terze parti. L’uso di questo flag fornisce al compilatore un suggerimento su dove trovare i file di intestazione (header) mentre al linker dove trovare il file della libreria.
Dove sono i framework all’interno del sistema?
- /System/Library/Frameworks: contiene i framework forniti da Apple – sia in macOS che in iOS.
- /Library/Frameworks: contiene i framework di terze parti. (ovviamente in iOS è vuota – per ovvie ragioni)
- ~/Library/Frameworks: contiene (non necessariamente) i framework forniti dall’utente.
I framework più importanti in macOS sono Cocoa e Carbon (deprecato)!
Carbon è il nome in codice dato alle API contenute nel sistema operativo macOS che consentono ai programmi scritti per i sistemi della Apple precedenti a macOS di funzionare sul nuovo sistema operativo tramite piccole modifiche; è stato dichiarato deprecato, sebbene alcune applicazioni, continuino a fare affidamento su di esso. Cocoa invece è l’incarnazione moderna delle idee nata in ambiente NeXTSTEP, come è evidente dal prefisso di molte delle sue classi di base: NS, abbreviazione di NeXTSTEP. Il linguaggio preferito per la programmazione con Cocoa è l’Objective C, anche se è possibile accedervi anche da Java e AppleScript.
(Nota per smanettoni: adesso vi è più chiaro il motivo per il quale in XCode c’è il prefisso NS davanti le classi? – NSString, NSUserDefault, NSDictionary..)
Librerie
I framework sono un tipo speciale di librerie perchè praticamente i file binari che costituiscono i framework sono librerie. (gioco di parole!)
Apple fa ancora distinzione tra i due termini perchè i frameworks tendono ad essere una struttura più specifica sia in macOS che in iOS, al contrario delle librerie, che sono comuni a tutti i sistemi UNIX. macOS e iOS memorizzano le librerie “tradizionali” in /usr/lib (non in /lib) ed inoltre sono dotate di un’estensione .dylib, piuttosto che il consueto .so – shared object.
A parte la diversa estensione (e il diverso formato binario), le librerie .dylib e .so sono concettualmente identiche: in effetti in macOS si trovano le stesse librerie presenti su un sistema Unix, anche se con estensione .dylib – per il resto, sono identiche.
(Nota per smanettoni: la libreria standard del C nel progetto GNU, libc, in macOS è contiene un link simbolico a libSystem.dylib: potete provarci inserendo nel terminale:
ls -l /usr/lib | grep libc.dylib | grep libSystem.dylib
secondo voi per quale motivo?)
In conclusione, macOS contiene out-of-box molte altre librerie open source, che sono state incluse in Darwin (e in iOS) come: OpenSSL, OpenSSH, libZ, libXSLT e molte altre, che possono essere ottenute o direttamente dal sito open source di Apple o scaricate da altri repository e per poi essere compilate.
Anche per questo articolo è tutto! Per eventuali domande, curiosità o feedback potete lasciare un commento qui in basso, a presto!