{"id":10841,"date":"2013-11-12T18:12:59","date_gmt":"2013-11-12T17:12:59","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=10841"},"modified":"2013-11-12T18:14:48","modified_gmt":"2013-11-12T17:14:48","slug":"xcode-tips-tricks-gestione-del-filesystem-un-progetto-piu-versioni-plugin","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/xcode-tips-tricks-gestione-del-filesystem-un-progetto-piu-versioni-plugin\/","title":{"rendered":"Xcode Tips & Tricks: Gestione del filesystem, un progetto pi\u00f9 versioni, plugin"},"content":{"rendered":"

Qualche settimana fa ho avuto modo di partecipare al meeting di #pragma mark<\/a> ed ascoltare l’interessante presentazione di Massimo Oliviero intitolata “Building iOS App Project & Architecture<\/a>” e mi \u00e8 venuta l’idea di scrivere questo articolo.<\/p>\n

Tutti noi usiamo quotidianamente Xcode, ma un po’ per prigrizia e un po’ per oggettiva complessit\u00e0 del programma, molto spesso ci limitamo ad usare le funzionalit\u00e0 principali, trascurando invece funzionalit\u00e0 che in alcuni casi posso renderci la vita pi\u00f9 semplice.<\/p>\n

Gestione del filesystem<\/h1>\n

Diciamoci la verit\u00e0, se c’\u00e8 un punto dolente su Xcode \u00e8 proprio la sua gestione del filesystem. Per quanto il progetto possa apparire ordinato, con tanto di gruppi e sottogruppi in realt\u00e0 \u00e8 solo un’illusione \ud83d\ude09 perch\u00e9 per impostazione predefinita Xcode piazza tutti i file nella stessa directory, e la nostra reazione quando lo scopriamo \u00e8 pi\u00f9 o meno questa:<\/p>\n


\n\"Xcode-tips-tricks-angry-desk-flip\"
\n<\/center><\/p>\n

Durante il talk di Massimo ho scoperto di non essere l’unico ossessivo-compulsivo sulla struttura delle cartelle e putroppo Xcode non ci rende la vita facile. Se volete ottenere una struttura ordinata sul filesystem il primo consiglio \u00e8 quello di partire fin da subito con il piede giusto, perch\u00e9 una volta che i file sono aggiunti al progetto pu\u00f2 non essere semplicissimo spostarli. Per esempio, personalmente prima di aggiungere una nuova classe al progetto creo sempre prima la cartella per ospitarla ed il modo pi\u00f9 veloce di farlo \u00e8 cliccare con il tasto destro su una cartella gi\u00e0 presente sul nostro progetto e selezionare “Add files to\u2026”<\/p>\n


\n\"Xcode-tips-tricks-add_files\"
\n<\/center><\/p>\n

Nella finestra di selezione del file cliccare sul tasto “New folder”<\/p>\n


\n\"Xcode-tips-tricks-new_folder\"
\n<\/center><\/p>\n

e infine selezionare “Add”. In questo modo avremo creato una cartella sul filesystem e un gruppo all’interno del progetto e questi saranno linkati, cosicch\u00e9 tutti i file che creeremo dentro questo gruppo saranno creati dentro questa cartella.<\/p>\n

Per quanto riguarda le immagini trovo invece molto comoda la funzionalit\u00e0 di “folder reference” anche se devo dire che non \u00e8 molto usata. Quando trascinate su Xcode la vostra catella con le immagini, invece di selezionare “Create group for any added folder” selezionate “Create folder references for any added folder”, cos\u00ec come si vede nell’immagine qui di seguito:<\/p>\n


\n\"Xcode-tips-tricks-folder_reference\"
\n<\/center><\/p>\n

In questo modo Xcode creer\u00e0 un particolare gruppo, riconoscibile dal colore azzurro, che \u00e8 in realt\u00e0 un riferimento alla cartella sul filesystem. A differenza del gruppo creato precedentemente, in questo caso ci baster\u00e0 aggiungere un file all’interno della cartella e questo verr\u00e0 automaticamente reso disponibile all’interno di Xcode.<\/p>\n


\n\"Xcode-tips-tricks-folder_reference_detail\"
\n<\/center><\/p>\n

I Folder reference sono mantenuti anche all’interno del progretto compilato, a differeza dei gruppi tradizionali che vengono poi “appiatti” durante la compilazione. Questo comporta per\u00f2 una notevolte differenza nella gestione dei file perch\u00e9 bisogner\u00e0 tenere conto della presenza di questa folder, ad esempio per caricare l’immagine bisogner\u00e0 scrivere<\/p>\n

\r\nUIImage *img = [UIImage imageNamed:@\"images\/test.png\"];\r\n<\/pre>\n
Esiste anche una terza (e ancora meno usata) tecnica che consiste nell’usare i Bundle. Un bundle non \u00e8 altro che una cartella rinominata opportunamente con estensione *.bundle<\/p>\n
La comodit\u00e0 di utilizzo di un bundle \u00e8 che possono essere trattati come dei normali file e quindi se vi capita di dover distribuire delle risorse \u00e8 pi\u00f9 comodo distribuire un unico file .bundle invece che una folder con i file, infatti \u00e8 comune trovarli insieme ai framework.<\/p>\n
Per accedere programmaticamente al contenuto di un bundle bisogna prima ottenere un riferimento al bundle e successivamente si pu\u00f2 ricavare il percorso del file<\/p>\n
\r\n    NSString *bundlePath = [[NSBundle mainBundle] pathForResource:@\"images\" ofType:@\"bundle\"];\r\n    NSBundle *bundle = [NSBundle bundleWithPath:bundlePath];\r\n    NSString *filePath = [bundle pathForResource:@\"test\" ofType:@\"png\"];\r\n<\/pre>\n
Un progetto, pi\u00f9 versioni<\/h1>\n
Questo argomento \u00e8 stato trattato spesso anche sul nostro forum, la domanda in genere \u00e8:<\/p>\n
Devo realizzare due progetti identici, uno lite e uno pro. Devo fare una copia di tutto?<\/p><\/blockquote>\n
Neanche a dirlo, la risposta \u00e8 ovviamente no! La duplicazione del codice \u00e8 da evitare a tutti i livelli, mai avere due metodi che hanno lo stesso scopo, o due classi\u2026 o perfino due progetti.<\/p>\n
Esistono due metodi per risolvere in modo elegante questo problema: il primo \u00e8 creare pi\u00f9 target, il secondo pi\u00f9 configurazioni. Vediamo in dettaglio.<\/p>\n
Ciascun progetto xcode pu\u00f2 avere pi\u00f9 target, in Xcode 5 ne vengono creati di default due, il primo \u00e8 il target legato alla nostra applicazione iOS, mentre il secondo \u00e8 legato ai test (vedi qui<\/a>)<\/p>\n
Per creare un nuovo target possiamo duplicare uno dei target esistenti<\/p>\n

\n\"Xcode-tips-tricks-clone_target\"
\n<\/center><\/p>\n
oppure crearne uno ex-novo cliccando sull’opzione “Add Target\u2026” e selezionando il tipo di target desiderato.<\/p>\n
Utilizzare pi\u00f9 target offre il maggior livello di versatilit\u00e0, ma anche di complessit\u00e0, infatti sarebbe tecnicamente possibile creare anche applicazioni totalmente differenti a partire dalla stesso progetto, ma con differenti target. L’utilizzo pi\u00f9 tipico \u00e8 per\u00f2 quello in cui bisogna generare due applicazioni diverse che condividono la gran parte del codice, come ad esempio la versione iPad e la versione iPhone della stessa applicazione. Creando un nuovo target avremo un nuovo file info.plist dove specificare le caratteristiche del progetto, avremo i nuovi scheme per la compilazione e soprattutto avremo modo di specificare ciascun file a quali target appartiene<\/p>\n

\n\"Xcode-tips-tricks-target_dest\"
\n<\/center><\/p>\n
La creazione di pi\u00f9 configurazioni \u00e8 differente rispetto alla creazione di pi\u00f9 target ed \u00e8 indicata quando si vuole compilare il progetto con alcune piccole varianti, come ad esempio la versione “pro” e la versione “lite” dello stesso progetto, oppure una versione con delle modifiche grafiche.<\/p>\n
Per creare una nuova configurazione selezionare il progetto, quindi, dalla tab “info”, cliccare sul pulsante “+” per duplicare una delle configurazioni attuali.<\/p>\n

\n\"Xcode-tips-tricks-duplicate_conf\"
\n<\/center><\/p>\n
Una volta create le configurazioni necessarie potremo andare a specificare le opzioni di compilazione per la specifica configurazione, cos\u00ec come siamo gi\u00e0 abituati a fare per “debug” e “release”<\/p>\n

\n\"Xcode-tips-tricks-name_options\"
\n<\/center><\/p>\n
La sezione di una configurazione al posto di un’altra avviene attraverso lo scheme. Cliccando su “Manage scheme” e successivamente doppio click sul nome dello scheme che vogliamo modificare, si accede alla schermata di gestione dello scheme.<\/p>\n

\n\"Xcode-tips-tricks-manage_scheme\"
\n<\/center><\/p>\n
per ciascuna delle sei tipologie di compilazione \u00e8 possibile definire quale configurazione utilizzare<\/p>\n

\n\"Xcode-tips-tricks-edit_scheme\"
\n<\/center><\/p>\n
L’opzione pi\u00f9 semplice \u00e8 quindi quella di creare un nuovo scheme e per il nuovo scheme selezionare le nuove configurazioni, cos\u00ec quando vorremo cambiare configurazione sar\u00e0 sufficiente buildare lo scheme corrispondente. Nel mio esempio ho creato dei file di configurazione per buildare una “red version” cio\u00e8 una versione che ha delle piccole varianti grafiche. Ho creato quindi uno scheme “SampleApp_redVersion” ed ho configurato lo scheme per usare i nuovi file di configurazione.<\/p>\n
Fin qui abbiamo creato le configurazioni, gli scheme, possiamo cambiare i settings ma non abbiamo visto nulla per identificare la versione in modo programmatico. Anche in questo caso gli approcci sono due, le variabili d’ambiente e le macro per il preprocessore.<\/p>\n
Per definire una variabile d’ambiente selezionare la tab “Arguments” dalla schermata di gestione degli scheme e aggiungere una variabile tramite il tasto “+”<\/p>\n

\n\"Xcode-tips-tricks-env_variables\"
\n<\/center><\/p>\n
Il valore di questa variabile sar\u00e0 accessibile via codice tramite la classe NSProcessiInfo<\/p>\n
\r\n[[[NSProcessInfo processInfo] environment] objectForKey:@\"REDV\"];\r\n<\/pre>\n
L’utilizzo delle macro di preprocessore \u00e8 un po’ diverso e permette di escludere dalla compilazione intere parti di codice e questo spesso pu\u00f2 rivelarsi molto utile.<\/p>\n
Per definire una nuova macro accedere ai settings del progetto e trovare la voce “Preprocessor macros”. Aprire il selettore e definire la nuova macro per le configurazioni desiderate, la macro \u00e8 nella forma nomemacro=valore<\/code><\/p>\n

\n\"Xcode-tips-tricks-preprocessor\"
\n<\/center><\/p>\n
Per verificare via codice il valore di questa macro bisogner\u00e0 utilizzare i comandi del preprocessore, in particolare potremo scrivere:<\/p>\n
\r\n#if REDV == 1\r\n    self.titleLbl.text = @\"Red Version\";\r\n    self.sampleView.backgroundColor = [UIColor redColor];\r\n#endif\r\n<\/pre>\n
La particolarit\u00e0 in questo caso \u00e8 che se REDV non \u00e8 dichiarata o non vale 1, le due righe di codice non vengono totalmente prese in considerazione perch\u00e9 rimosse in fase di preprocessing.<\/p>\n
Gestire il numero di versione<\/h1>\n
Spesso si vuol automatizzare l’incremento del numero di build del progetto e in rete si trovano diversi script per farlo e tutti pi\u00f9 o meno si basano sul comando PlistBuddy<\/strong> che serve per intervenire direttamente sui file plist del nostro progetto. Pochi sanno che Apple fornisce un tool apposito per fare questo lavoro che si chiama agvtool<\/strong>. Per utilizzarlo dobbiamo soltanto configurare correttamente il progetto inserendo tra le opzioni il numero attuale di versione e la volont\u00e0 di utilizzare il tool di versioning di Apple. La configurazione corretta \u00e8 visibile in questa immagine<\/p>\n

\n\"Xcode-tips-tricks-versioning\"
\n<\/center><\/p>\n
Una volta che avremo configurato il progetto per incrementare il numero di build avviare un terminale e, posizionandosi nella directory del progetto, digitare:<\/p>\n
\r\nagvtool bump -all\r\n<\/pre>\n
In questo modo verr\u00e0 incrementato il numero di build e verr\u00e0 memorizzato nel file plist del progetto.<\/p>\n
Ovviamente l’utilit\u00e0 di questo comando \u00e8 limitata soltanto a chi vuole automatizzare il processo di archiviazione e distribuzione, per esempio potrebbe essere una buona idea inserirlo in uno script hook di git o in uno script di generazione del file *.ipa per la distribuzione ad-hoc.<\/p>\n
Un pluging to bring them all<\/h1>\n
Le funzionalit\u00e0 offerte da Xcode possono essere estese tramite tutta una serie di plugin sviluppati appositamente per semplificarci il lavoro. Purtroppo non esistono API ufficiali per lo sviluppo di questi plugin quindi il loro numero \u00e8 molto pi\u00f9 esiguo di quello che potrebbe essere in realt\u00e0. Tra i plugin che trovo pi\u00f9 utili vi segnalo:<\/p>\n