Objective-C è il linguaggio più comune per lo sviluppo di applicazioni iOS e OS X. Certo, è possibile utilizzare framework di terze parti che consentono di sviluppare applicazioni che utilizzano altri linguaggi come HTML e Javascript o C #, ma se si vuole scrivere applicazioni native incredibilmente veloci, super efficienti, allora avete bisogno di usare Objective-C. Foundation è uno dei core frameworks di base che si usano quando si sviluppano applicazioni Objective-C.
In qualità di sviluppatore iOS, è fondamentale per mantenersi aggiornati sugli ultimi progressi in Objective-C e foundation e in iOS 7, ci sono alcune importanti modifiche che è necessario conoscere. Si noti che questo è un articolo invece di un tutorial, si otterrà un corso accelerato su ciò che è nuovo (con alcuni frammenti di codice lungo la strada), in modo da capire e sviluppare il più rapidamente possibile.
Moduli
Ci sono buone probabilità che hai abbia scritto l’istruzione #import mille volte o più:
#import <UIKit/UIKit.h> #import <MapKit/MapKit.h> #import <iAd/iAd.h>
Questa sintassi richiama alle radici di Objective-C: vanilla C. L’ istruzione #import è una direttiva pre-processore che funziona in modo simile a #include . L’unica differenza è che #import fa intestazioni non re-importazione che sono già state importate, è un affare one-shot.
Quando il pre-processore incontra una direttiva #import, essa letteralmente sostituisce quella singola linea con l’intero contenuto del file di intestazione che viene importato. Lo fa in modo ricorsivo, attraverso un numero potenzialmente elevato di file di intestazione.
L’intestazione ad ombrello UIKit, UIKit.h , importa tutte le altre intestazioni incluse nel frameworkUIKit. Questo significa che non c’è bisogno di importare manualmente ogni file di intestazione nel framework, come UIViewController.h , UIView.h o UIButton.h .
Curioso circa le dimensioni del framework UIKit? Proviamo a contare tutte le righe negli header di UIKit, troverete che sono più di 11.000 righe di codice!
In una normale applicazione iOS, si importano UIKit nella maggior parte dei file, il che significa ogni singolo file finisce per essere 11.000 linee più lungo. Questo è proprio l’ideale, più linee di codice significa tempi più tempo ad essere compilato.
Vecchia soluzione: Pre-compiled Headers
File precompilati di intestazione o file PCH, tentano di affrontare questo problema fornendo un meccanismo di pre-calcolo e la memorizzazione nella cache di gran parte del lavoro richiesto durante la fase di pre-elaborazione di compilazione. Probabilmente hai già visto il file PCH generato dai modelli in bundle con Xcode, che appare così:
#import
#ifndef __IPHONE_5_0
#warning "This project uses features only available in iOS SDK 5.0 and later."
#endif
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#endif
Il #warning comunica allo sviluppatore se l’applicazione che si sta sviluppando si rivolge ad un SDK prima di iOS 5. Il file di intestazione Foudation e UIKit e fanno parte di questo stock PCH, poiché ogni file nella vostra applicazione utilizzerà Foundation e la maggior parte utilizzerà UIKit. Dunque questi sono generalmente buone aggiunte al file PCH in modo che il pre-calcolo e memorizzazione nella cache beneficeranno la compilazione di tutti i file nella tua applicazione.
“Allora, cosa c’è di male?” Ci si potrebbe chiedere. Non c’è niente di tecnicamente sbagliato con il PCH così com’ è se non è rotto, non aggiustarlo. Tuttavia, potrebbe essere mancante su una serie di vantaggi di prestazioni che derivano da un ben curato file PCH. Per esempio, se diverse aree della vostra applicazione utilizzano il MapKit framework, si può vedere un miglioramento nel tempo di compilazione con la semplice aggiuntadel kit nel file PCH. Siamo tutti colpevoli di essere sviluppatori pigri però, e nessuno ha tempo per sintonizzare i loro file PCH per ogni progetto a cui lavoriamo. Ecco perché i moduli sono stati sviluppati come una caratteristica di LLVM.
LLVM è una raccolta di compilatori modulare e riutilizzabile e tecnologie toolchain in bundle con Xcode. LLVM ha diversi componenti, i più importanti per gli sviluppatori Objective-C sono Clang, il C nativo, C + + e il compialtore Objective-C, e LLDB, il debugger nativo che è il miglior amico dello sviluppatore.
Nuova soluzione: Moduli
La prima apparizione pubblica dei moduli in Objective-C era in un discorso tenuto da Doug Gregor di Apple nella riunione del LLVM sviluppatori ‘2012. E ‘un discorso affascinante, ed è altamente raccomandato per chiunque sia interessato nel funzionamento dei loro compilatori. Potete trovare il video della sessione online a http://llvm.org/devmtg/2012-11/#talk6 .
I Moduli incapsulano i framework in modo più pulito che mai. Il pre-processore non ha più bisogno di sostituire una direttiva #import con l’intero contenuto del file parola per parola. Invece, un modulo avvolge un framework in un blocco autonomo, che è pre-compilato alla stessa maniera come file PCH e offre le stesse miglioramenti nella velocità di compilazione. Tuttavia, non è più necessario indicare quali strutture si sta utilizzando in un file PCH, si ottiene che la velocità aumenta semplicemente utilizzando i moduli.
Sono sicuro che vi ricordate i numerosi passaggi che si vanno a fare la prima volta che si utilizza un nuovo framework in un app, tende a qualcosa di simile a questo:
- Aggiungere una linea di #import per il file utilizzando il framework.
- Scrivi il codice che utilizza il framework.
- Compila.
- Guarda come gli errori spuntano durante il collegamento.
- Ricordarsi che si è dimenticato di collegare il framework.
- Aggiungere il collegamento del framework al progetto lbuild phase
- Compilare nuovamente.
E ‘incredibilmente comune dimenticare di collegare il framwork, ma i moduli possono risolvere questo problema in maniera pulita. (C’è qualcosa che i moduli non possono fare?)
Un modulo dice al compilatore non solo quali file header compongono il modulo, ma anche ciò che deve essere collegato. Questo evita di dover collegare manualmente il framework. È solo una piccola cosa, ma tutto ciò che rende più facile lo sviluppo di codice è una buona cosa!
Come usare i moduli
I moduli sono estremamente facili da utilizzare nei vostri progetti. Per i progetti già esistenti, la prima cosa da fare è consentire il loro uso. Potete trovare questa opzione per la ricerca di moduli nel tab Build Setting del progetto (avendo cura di selezionare All, e non solo Basic) e quindi la modifica delle opzioni in questo modo:
Tutti i nuovi progetti creati con Xcode 5 hanno tutto questo abilitato di default, ma si dovrebbe assolutamente abilitarlo su tutti i vostri progetti esistenti.
Il link Frameworks automatico è un opzione che può essere utilizzata per attivare o disattivare il collegamento automatico dei framework come descritto in precedenza. Ci sono poche ragioni per cui c’è però la necessità di disattivarlo.
Una volta che i moduli sono attivati, è possibile iniziare a utilizzarli nel codice. Per fare questo, è sufficiente una piccola modifica alla sintassi a cui siete abituati. Invece della solita sintassi #import, si utilizza semplicemente @import :
@import UIKit; @import MapKit; @import iAd;
E ‘ancora possibile importare le parti di un framework se necessario. A titolo di esempio, se si voleva importare solo UIView, dovete scrivere questo:
@import UIKit.UIView;
Esatto, è davvero così semplice! Beh, mi dispiace, non è esattamente la verità. È ancora più semplice. Tecnicamente, non c’è bisogno di convertire tutti i vostri #import in @import, visto che il compilatore implicitamente li converte per voi sotto il cofano. Tuttavia, è sempre buona norma iniziare a utilizzare la nuova sintassi il più spesso possibile.
Prima di iniziare a diventare troppo entusiasti per i moduli, c’è un avvertimento, purtroppo. In Xcode 5.0, non è possibile utilizzare i moduli con i propri framework o framework di terze parti. Questo probabilmente verrà col tempo ma per ora è solo uno sfortunato inconveniente. Niente è perfetto, nemmeno Objective-C!