Progetto Xcode vs. area di lavoro Xcode - Differenze

Sto cercando di capire come funziona l'intero ecosistema iOS.
Fino ad ora, ho potuto trovare una risposta per la maggior parte della mia domanda (e credetemi, ce ne sono stati molti), ma per questo sembra che non ci sia ancora una risposta chiara.

Qual è la differenza tra i file XcodeProject e XcodeWorkspace?

1. Qual è la differenza tra i due?
2. Di cosa sono responsabili?
3. Con quale dovrei lavorare quando sto sviluppando le mie app in team / da solo?
4. C'è qualcos'altro che dovrei essere a conoscenza di questi due file?

Penso che ci siano tre elementi chiave che devi capire per quanto riguarda la struttura del progetto: obiettivi , progetti e aree di lavoro . I target specificano in dettaglio come viene costruito un prodotto / binario (ovvero un'applicazione o una libreria). Includono impostazioni di compilazione, come flag di compilatore e linker, e definiscono quali file (codice sorgente e risorse) appartengono effettivamente a un prodotto. Quando costruisci / esegui, selezioni sempre un obiettivo specifico.

È probabile che tu abbia alcuni target che condividono codice e risorse. Questi diversi target possono essere versioni leggermente diverse di un'app (iPad / iPhone, marchi diversi, ...) o casi di test che devono naturalmente accedere agli stessi file di origine dell'app. Tutti questi obiettivi correlati possono essere raggruppati in un progetto . Mentre il progetto contiene i file da tutti i suoi target, ogni target seleziona il proprio sottoinsieme di file rilevanti. Lo stesso vale per le impostazioni di compilazione: puoi definire impostazioni predefinite a livello di progetto nel progetto, ma se uno dei tuoi target richiede impostazioni diverse, puoi sempre sovrascriverli lì:

Impostazioni di progetto condivise ereditate da tutte le destinazioni, a meno che non vengano ignorate

Impostazioni target concrete: PSE iPhone ha la precedenza sulle Base SDKimpostazioni del progetto

In Xcode, si aprono sempre progetti (o aree di lavoro, ma non target) e tutte le destinazioni in esso contenute possono essere costruite / eseguite, ma non esiste alcun modo / definizione di costruzione di un progetto, quindi ogni progetto ha bisogno di almeno una destinazione per essere più di una semplice raccolta di file e impostazioni.

Seleziona uno degli obiettivi del progetto da eseguire

In molti casi, i progetti sono tutto ciò che serve. Se si dispone di una dipendenza creata dall'origine, è possibile incorporarla come sottoprogetto . I sottoprogetti possono essere aperti separatamente o all'interno del loro super progetto.

demoLib è un sottoprogetto

Se aggiungi uno dei target del sottoprogetto alle dipendenze del superprogetto, il sottoprogetto verrà creato automaticamente a meno che non sia rimasto invariato. Il vantaggio qui è che puoi modificare i file sia dal tuo progetto che dalle tue dipendenze nella stessa finestra Xcode, e quando costruisci / esegui, puoi selezionare tra le destinazioni del progetto e dei suoi sottoprogetti:

Se, tuttavia, la tua libreria (il sottoprogetto) viene utilizzata da una varietà di altri progetti (o dai loro obiettivi, per essere precisi), ha senso metterlo allo stesso livello gerarchico: ecco a cosa servono gli spazi di lavoro . Le aree di lavoro contengono e gestiscono i progetti e tutti i progetti che include direttamente (ovvero, non i loro sottoprogetti) sono allo stesso livello e i loro obiettivi possono dipendere l'uno dall'altro (gli obiettivi dei progetti possono dipendere dagli obiettivi dei sottoprogetti, ma non viceversa).

Struttura dell'area di lavoro

In questo esempio, entrambe le app ( AnotherApplication / ProjectStructureExample ) possono fare riferimento alle destinazioni del progetto demoLib . Ciò sarebbe anche possibile includendo il progetto demoLib in entrambi gli altri progetti come sottoprogetto (che è solo un riferimento, quindi non è necessaria alcuna duplicazione), ma se si hanno molte dipendenze incrociate, le aree di lavoro hanno più senso. Se apri un'area di lavoro, puoi scegliere tra le destinazioni di tutti i progetti durante la costruzione / esecuzione.

È ancora possibile aprire i file di progetto separatamente, ma è probabile che i loro obiettivi non vengano creati perché Xcode non è in grado di risolvere le dipendenze se non si apre il file dell'area di lavoro. Le aree di lavoro offrono gli stessi vantaggi dei sottoprogetti: una volta modificata una dipendenza, Xcode la ricostruirà per assicurarsi che sia aggiornata (anche se ho avuto alcuni problemi con ciò, non sembra funzionare in modo affidabile).

Le tue domande in breve :

1) I progetti contengono file (codice / risorse), impostazioni e destinazioni che creano prodotti da tali file e impostazioni. Le aree di lavoro contengono progetti che possono fare riferimento a vicenda.

2) Entrambi sono responsabili della strutturazione del progetto complessivo, ma a diversi livelli.

3) Penso che i progetti siano sufficienti nella maggior parte dei casi. Non utilizzare aree di lavoro a meno che non ci sia un motivo specifico. Inoltre, puoi sempre incorporare il tuo progetto in un'area di lavoro in un secondo momento.

4) Penso che sia per questo che il testo sopra è per ...

C'è un'osservazione per 3): CocoaPods , che gestisce automaticamente le librerie di terze parti, utilizza gli spazi di lavoro. Pertanto, devi usarli anche quando usi CocoaPods(cosa che fanno molte persone).

Un'area di lavoro è una raccolta di progetti. È utile organizzare i tuoi progetti quando esiste una correlazione tra loro (ad esempio: il progetto A include una libreria, che viene fornita come progetto stesso come progetto B. Quando si crea lo spazio di lavoro, il progetto B viene compilato e collegato nel progetto A).
È comune utilizzare uno spazio di lavoro nei popolari CocoaPods . Quando si installano i pod, questi vengono collocati all'interno di un'area di lavoro che contiene il progetto e le librerie di pod.

In breve

• Xcode 3 ha introdotto il sottoprogetto, che è una relazione genitore-figlio, il che significa che il genitore può fare riferimento al suo obiettivo figlio, ma non viceversa
• Xcode 4 ha introdotto lo spazio di lavoro, che è una relazione tra fratelli, il che significa che qualsiasi progetto può fare riferimento a progetti nello stesso spazio di lavoro

Quando ho usato CocoaPods per sviluppare progetti iOS, c'è un .xcworkspacefile, è necessario aprire il progetto con il .xcworkspacefile relativo a CocoaPods.

Ma quando Show Package Contentscon .xcworkspaceil file, si trova il contents.xcworkspacedatafile.

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "group:BluetoothColorLamp24G.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:Pods/Pods.xcodeproj">
   </FileRef>
</Workspace>

presta attenzione a questa linea:

location = "group:BluetoothColorLamp24G.xcodeproj"

Il .xcworkspacefile ha riferimento al .xcodeprojfile.

Sviluppo dell'ambiente:

macOS 10.14
Xcode 10.1

1. Qual è la differenza tra i due?
   Workspace è un insieme di progetti

2. Di cosa sono responsabili?
   Il progetto è responsabile del codice sorgente. L'area di lavoro è responsabile delle dipendenze tra i progetti

3. Con quale dovrei lavorare quando sto sviluppando le mie app in team / da solo?
   La tua scelta dovrebbe dipendere da un tipo di progetto. Ad esempio, se il progetto si basa sul gestore delle dipendenze CocoaPods, crea un'area di lavoro.

4. C'è qualcos'altro di cui dovrei essere a conoscenza in merito a questi due file?
   Un concorrente dell'area di lavoro è cross-project references^{[Informazioni]}

[Componenti Xcode]