Xcode Project vs Xcode espace de travail - les Différences

Je pense qu'il y a trois éléments clés que vous devez comprendre au sujet de la structure de projet: Cibles, projets, et espaces de travail. Cibles préciser dans le détail la façon dont un produit/binaire (c'est à dire, une application ou une bibliothèque) est construit. Ils comprennent des paramètres de construction, tels que le compilateur et l'éditeur de liens drapeaux, et ils définissent les fichiers (code source et ressources) appartiennent en fait à un produit. Lorsque vous build/run, vous pouvez toujours sélectionner une cible spécifique.

Il est probable que vous avez un peu de cibles que le partage de code et des ressources. Ces différents objectifs peuvent être légèrement différentes versions d'une application (iPad/iPhone, les différentes labellisations,...) ou de cas de test qui ont naturellement besoin d'accéder aux mêmes fichiers source de l'application. Tous ces objectifs peuvent être regroupés dans un projet. Alors que le projet contient les fichiers à partir de l'ensemble de ses objectifs, chaque cible reprend à son propre sous-ensemble de fichiers pertinents. Il en va de même pour les paramètres de construction: Vous pouvez définir le projet, les paramètres de l'ensemble du projet, mais si l'un de vos cibles à des besoins différents paramètres, vous pouvez toujours les remplacer il y a:

Projet partagé paramètres que toutes les cibles hériter, à moins de le remplacer

Béton les paramètres de la cible: PSE iPhone remplace le projet de Base SDK réglage

Dans Xcode, vous pouvez toujours ouvrir un projet (ou d'espaces de travail, mais pas les objectifs), et tous les objectifs qu'il contient peut être construit/exécuter, mais il n'y a aucun moyen de/la définition de la construction d'un projet, de sorte que chaque projet a besoin d'au moins une cible dans le but d'être plus que juste une collection de fichiers et de paramètres.

Sélectionnez l'une des cibles du projet à exécuter

Dans beaucoup de cas, les projets sont tous vous avez besoin. Si vous avez une dépendance que vous créer à partir de la source, vous pouvez l'intégrer comme un sous-projet. Les sous-projets peuvent être ouverts séparément ou dans leur super projet.

demoLib est un sous-projet

Si vous ajoutez l'un des objectifs du sous-projet pour le super projet de dépendances, le sous-projet sera construit automatiquement à moins qu'il est resté inchangé. L'avantage ici est que vous pouvez modifier les fichiers de votre projet et de vos dépendances, dans la même fenêtre de Xcode, et quand vous build/run, vous pouvez le sélectionner à partir du projet et de ses sous-projets objectifs:

Si, toutefois, votre bibliothèque (sous-projet) est utilisée par une variété d'autres projets (ou de leurs objectifs, pour être précis), il est logique de le mettre sur le même niveau de hiérarchie – c'est ce que espaces de travail sont pour. Les espaces de travail de contenir et de gérer des projets, et tous les projets qu'il comprend directement (c'est à dire, pas de leurs sous-projets) sont sur le même niveau et leurs objectifs dépendent les uns des autres (projets cibles peut dépendre de la sous-projets, les objectifs, mais pas vice-versa).

De l'espace de travail de la structure

Dans cet exemple, les deux applications (AnotherApplication /ProjectStructureExample) peut faire référence à la demoLib cibles du projet. Ce serait aussi possible en incluant les demoLib projet dans les deux autres projets comme un sous-projet (qui est une référence seulement, donc pas de doublon), mais si vous avez beaucoup de croix-des dépendances, des espaces de travail plus de sens. Si vous ouvrez un espace de travail, vous pouvez choisir parmi tous les projets cibles lors de la construction/running.

Vous pouvez toujours ouvrir les fichiers de votre projet séparément, mais il est probable que leurs objectifs ne vais pas développer, car Xcode ne peut pas résoudre les dépendances, sauf si vous ouvrez le fichier d'espace de travail. Les espaces de travail vous donner les mêmes avantages que les sous-projets: une Fois que la dépendance des changements, Xcode va reconstruire pour s'assurer qu'il est à jour (même si j'ai eu quelques problèmes avec cela, il ne semble pas fonctionner de façon fiable).

À vos questions en un mot:

1) les Projets contiennent des fichiers (code/ressources), les paramètres et les objectifs que construire des produits à partir de ces fichiers et de paramètres. Espaces de travail contiennent des projets qui font référence les uns aux autres.

2), les Deux sont responsables de la structuration de votre projet dans son ensemble, mais à des niveaux différents.

3) je pense que les projets sont suffisants dans la plupart des cas. Ne pas utiliser les espaces de travail, sauf si il y a une raison spécifique. De Plus, vous pouvez intégrer votre projet dans un espace de travail plus tard.

4) je pense que ce que le texte ci-dessus est pour...

Il y a une remarque pour 3): CocoaPods, qui gère automatiquement la 3e partie des bibliothèques pour toi, utilise les espaces de travail. Par conséquent, vous devez les utiliser, aussi, lorsque vous utilisez CocoaPods (dont beaucoup de gens le font).

En bref

• Xcode 3 introduit sous-projet, qui est en relation parent-enfant, ce qui signifie que le parent peut faire référence à son enfant cible, mais pas vice versa
• Xcode 4 introduit l'espace de travail, qui est la relation de fratrie, ce qui signifie que tout projet peut faire référence à des projets dans le même espace de travail