Je pense qu'il y a trois éléments clés que vous devez comprendre concernant la structure du projet : Cibles , projets et espaces de travail . Cibles spécifient en détail comment un produit/binaire (c'est-à-dire une application ou une bibliothèque) est construit. Ils comprennent les paramètres de construction, tels que les drapeaux du compilateur et de l'éditeur de liens, et ils définissent les fichiers (code source et ressources) qui appartiennent réellement à un produit. Lorsque vous construisez/exécutez, vous sélectionnez toujours une cible spécifique.
Il est probable que vous ayez quelques cibles qui partagent du code et des ressources. Ces différentes cibles peuvent être des versions légèrement différentes d'une application (iPad/iPhone, différentes marques, ) ou des cas de test qui doivent naturellement accéder aux mêmes fichiers sources que l'application. Toutes ces cibles apparentées peuvent être regroupées dans un projet . Alors que le projet contient les fichiers de toutes ses cibles, chaque cible choisit son propre sous-ensemble de fichiers pertinents. Il en va de même pour les paramètres de construction : Vous pouvez définir des paramètres par défaut pour l'ensemble du projet dans le projet, mais si l'une de vos cibles a besoin de paramètres différents, vous pouvez toujours les remplacer à cet endroit :
![Shared project settings that all targets inherit, unless they overwrite it]()
Paramètres partagés du projet dont toutes les cibles héritent, à moins qu'elles ne les remplacent.
![Concrete target settings: PSE iPhone overwrites the project’s Base SDK setting]()
Des objectifs concrets : PSE iPhone remplace l'option Base SDK réglage
Dans Xcode, vous ouvrez toujours des projets (ou des espaces de travail, mais pas des cibles), et toutes les cibles qu'il contient peuvent être construites/exécutées, mais il n'y a pas de moyen/définition de construire un projet, donc chaque projet a besoin d'au moins une cible pour être plus qu'une simple collection de fichiers et de paramètres.
![Select one of the project’s targets to run]()
Sélectionner une des cibles du projet à exécuter
Dans de nombreux cas, les projets sont tout ce dont vous avez besoin. Si vous avez une dépendance que vous construisez à partir de la source, vous pouvez l'intégrer en tant que projet sous-projet . Les sous-projets peuvent être ouverts séparément ou au sein de leur super-projet.
![demoLib is a subprojec]()
demoLib est un sous-projet
Si vous ajoutez l'une des cibles du sous-projet aux dépendances du super-projet, le sous-projet sera automatiquement construit, sauf s'il est resté inchangé. L'avantage ici est que vous pouvez éditer les fichiers de votre projet et de vos dépendances dans la même fenêtre Xcode, et lorsque vous construisez/exécutez, vous pouvez choisir parmi les cibles du projet et de ses sous-projets :
![Running targets from a subproject]()
Si, toutefois, votre bibliothèque (le sous-projet) est utilisée par divers autres projets (ou leurs cibles, pour être précis), il est logique de la placer au même niveau hiérarchique - c'est ce que font les espaces de travail sont pour. Les espaces de travail contiennent et gèrent des projets, et tous les projets qu'ils incluent directement (c'est-à-dire pas leurs sous-projets) sont au même niveau et leurs objectifs peuvent dépendre les uns des autres (les objectifs des projets peuvent dépendre des objectifs des sous-projets, mais pas l'inverse).
![Workspace structure]()
Structure de l'espace de travail
Dans cet exemple, les deux applications ( Une autre application / Exemple de structure de projet ) peut faire référence à la demoLib les objectifs du projet. Cela serait également possible en incluant le demoLib dans les deux autres projets en tant que sous-projet (qui n'est qu'une référence, donc pas de duplication nécessaire), mais si vous avez beaucoup de dépendances croisées, les espaces de travail ont plus de sens. Si vous ouvrez un espace de travail, vous pouvez choisir parmi les cibles de tous les projets lors de la construction/exécution.
![Running targets from a workspace]()
Vous pouvez toujours ouvrir vos fichiers de projet séparément, mais il est probable que leurs cibles ne seront pas construites parce que Xcode ne peut pas résoudre les dépendances à moins que vous n'ouvriez le fichier de l'espace de travail. Les espaces de travail vous donnent le même avantage que les sous-projets : Dès qu'une dépendance change, Xcode la reconstruit pour s'assurer qu'elle est à jour (bien que j'aie eu quelques problèmes avec cela, cela ne semble pas fonctionner de manière fiable).
Vos questions en bref :
1) Les projets contiennent des fichiers (code/réseaux), des paramètres et des cibles qui construisent des produits à partir de ces fichiers et paramètres. Les espaces de travail contiennent des projets qui peuvent se référer les uns aux autres.
2) Les deux sont responsables de la structuration de votre projet global, mais à des niveaux différents.
3) Je pense que les projets sont suffisants dans la plupart des cas. N'utilisez pas d'espaces de travail à moins qu'il y ait une raison spécifique. De plus, vous pouvez toujours intégrer votre projet dans un espace de travail plus tard.
4) Je pense que c'est à cela que sert le texte ci-dessus
Il y a une remarque pour 3) : CocoaPods qui gère automatiquement les bibliothèques tierces pour vous, utilise des espaces de travail. Par conséquent, vous devez également les utiliser lorsque vous utilisez la fonction CocoaPods (ce que beaucoup de gens font).
