Je pense qu'il y a trois éléments clés que vous devez comprendre concernant la structure du projet: les cibles , les projets et les espaces de travail . Les cibles spécifient en détail comment un produit / binaire (c'est-à-dire une application ou une bibliothèque) est construit. Ils incluent les paramètres de construction, tels que les indicateurs de compilateur et de l'éditeur de liens, et ils définissent quels fichiers (code source et ressources) appartiennent réellement à un produit. Lorsque vous créez / 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 ont naturellement besoin d'accéder aux mêmes fichiers sources que l'application. Toutes ces cibles associées peuvent être regroupées dans un projet . Alors que le projet contient les fichiers de toutes ses cibles, chaque cible sélectionne son propre sous-ensemble de fichiers pertinents. Il en va de même pour les paramètres de génération: vous pouvez définir des paramètres par défaut à l'échelle du projet dans le projet, mais si l'une de vos cibles nécessite des paramètres différents, vous pouvez toujours les remplacer ici:
Paramètres de projet partagés dont toutes les cibles héritent, à moins qu'elles ne les remplacent
Paramètres cibles concrets: l' iPhone PSE remplace le Base SDKparamètre du projet
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 aucun 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.
Sélectionnez l'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 créez à partir de la source, vous pouvez l'intégrer en tant que sous - projet . Les sous-projets peuvent être ouverts séparément ou dans leur super projet.
demoLib est un sous-projet
Si vous ajoutez une des cibles du sous-projet aux dépendances du super-projet, le sous-projet sera automatiquement construit à moins qu'il ne soit resté inchangé. L'avantage ici est que vous pouvez modifier des fichiers à la fois de votre projet et de vos dépendances dans la même fenêtre Xcode, et lorsque vous créez / exécutez, vous pouvez sélectionner parmi les cibles du projet et de ses sous-projets:
Si, cependant, votre bibliothèque (le sous-projet) est utilisée par une variété d'autres projets (ou leurs cibles, pour être précis), il est logique de la mettre au même niveau de hiérarchie - c'est à cela que servent les espaces de travail . Les espaces de travail contiennent et gèrent des projets, et tous les projets qu'il inclut directement (c'est-à-dire pas leurs sous-projets) sont au même niveau et leurs cibles peuvent dépendre les unes des autres (les cibles des projets peuvent dépendre des cibles des sous-projets, mais pas l'inverse).
Structure de l'espace de travail
Dans cet exemple, les deux applications ( AnotherApplication / ProjectStructureExample ) peuvent référencer les cibles du projet demoLib . Cela serait également possible en incluant le projet 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.
Vous pouvez toujours ouvrir vos fichiers de projet séparément, mais il est probable que leurs cibles ne seront pas construites car 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 offrent les mêmes avantages que les sous-projets: une fois 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 / ressources), des paramètres et des cibles qui créent des produits à partir de ces fichiers et paramètres. Les espaces de travail contiennent des projets qui peuvent se référencer.
2) Les deux sont responsables de la structuration de votre projet global, mais à différents niveaux.
3) Je pense que les projets sont suffisants dans la plupart des cas. N'utilisez pas d'espaces de travail à moins qu'il n'y ait une raison spécifique. De plus, vous pouvez toujours intégrer votre projet dans un espace de travail ultérieurement.
4) Je pense que c'est à ça 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 CocoaPods(ce que beaucoup de gens font).
