Area di lavoro Xcode vs Progetti nidificati

Question

Non capisco l'utilizzo di un'area di lavoro Xcode per organizzare progetti con dipendenze l'uno sull'altro. Ad esempio, vedo molti sviluppatori creare strutture di lavoro simili a questa:

 
Workspace 
|-- App 
|-- A Common Library 
|-- Another Common Library 

Quali vantaggi offre? Se qualcuno apre direttamente il progetto "App", non sarà in grado di creare effettivamente l'app? Dovrebbero rendersi conto che esiste uno spazio di lavoro con le dipendenze necessarie.

Mi sembra come l'approccio migliore è quello di utilizzare progetti annidati in questo modo:

 
App 
|-- Libraries 
| |-- A Common Library 
| |-- Another Common Library 

Poi esiste alcun progetto che non può essere costruito. Sembra anche più in linea con l'idea di Git dei sottomoduli.

L'unico utilizzo che vedo per un'area di lavoro consiste nel raggruppare progetti comuni senza dipendenze l'uno dall'altro. Mi piacerebbe sentire le opinioni di altre persone su questo perché potrei essermi perso qualcosa.

Answer 1

Utilizzo aree di lavoro quando desidero combinare progetti mantenendo allo stesso tempo l'indipendenza del progetto.

Un esempio in cui utilizzo spazi di lavoro è una serie di progetti tutorial che passano da molto semplici a più complessi. Ogni progetto può funzionare come progetto autonomo, ma raggrupparli in uno spazio di lavoro aiuta la mia organizzazione del progetto complessivo.

In un altro caso ho un'app sviluppata per un cliente. L'app funziona come un'app standalone e un modulo nel progetto generale. Il progetto indipendente può creare l'app standalone. L'altra app utilizza uno spazio di lavoro che include due progetti. La versione del modulo dell'app è creata da uno schema speciale e questa app combinata non viene creata senza utilizzare lo spazio di lavoro.

Una torsione con le due situazioni precedenti è dove la cartella di generazione è memorizzata. Devo modificare la preferenza Xcode per mettere i prodotti di costruzione in cartelle univoche per il gruppo di progetti tutorial, utilizzare una cartella di build comune per il modulo all'interno dell'altra configurazione dell'app.

In altre circostanze, ho molti progetti con progetti incorporati. In queste situazioni i progetti della biblioteca sono stabili. Non cerco di sviluppare ulteriormente i progetti della biblioteca, quindi sono solo un'altra risorsa per il progetto. Trovo più facile lavorare dove l'organizzazione del file system delle risorse del progetto rispecchia in qualche modo l'organizzazione del mio progetto Xcode. Quindi questi progetti di libreria vengono copiati nella gerarchia dei file del progetto principale. Avrebbe senso usare gli spazi di lavoro se stavo sviluppando le librerie e usandole in più progetti. Per convenienza, spesso non mi preoccupo.

A volte combino persino spazi di lavoro con progetti contenenti progetti incorporati.

Quindi la mia opinione è che entrambi gli strumenti organizzativi, i progetti incorporati e gli spazi di lavoro, hanno i loro meriti e problemi. Ho scelto di usare l'una o l'altra (o una combinazione) a seconda delle circostanze particolari.

Answer 2

Abbiamo aggiunto progetti nidificati nei Framework del progetto principale, in modo da poterli includere nel prodotto .framework.

Main 
|-- Main 
|-- MainTests 
|-- Frameworks 
| |-- CommonLibrary.xcodeproj 
| |-- AnotherCommonLibrary.xcodeproj 
| |-- UIKit.framework 
| |-- Foundation.framework 
| |-- CoreFoundation.framework 
|-- Products 

Vedi this Great Tutorial by Jeff Verkoeyen per l'aggiunta di universali quadri a un progetto. All'inizio non è facile, ma continua a lavorarci e ne prenderai confidenza.