Xcode Project vs. Xcode Workspace - Différences

J'essaie de comprendre comment fonctionne tout l'écosystème iOS.
Jusqu'à présent, je pouvais trouver une réponse à la plupart de mes questions (et croyez-moi, il y en a eu beaucoup), mais pour celle-ci, il ne semble pas encore y avoir de réponse claire.

Quelle est la différence entre les fichiers XcodeProject et XcodeWorkspace?

1. Quelle est la différence entre les deux?
2. De quoi sont-ils responsables?
3. Avec laquelle dois-je travailler lorsque je développe mes applications en équipe / seul?
4. Y a-t-il autre chose que je devrais être au courant de ces deux fichiers?

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).

Un espace de travail est une collection de projets. Il est utile d'organiser vos projets lorsqu'il y a une corrélation entre eux (par exemple: le projet A comprend une bibliothèque, qui est fournie en tant que projet lui-même en tant que projet B. Lorsque vous créez l'espace de travail, le projet B est compilé et lié dans le projet A).
Il est courant d'utiliser un espace de travail dans les CocoaPods populaires . Lorsque vous installez vos pods, ils sont placés dans un espace de travail, qui contient votre projet et les bibliothèques de pods.

En bref

• Xcode 3 a introduit le sous-projet, qui est une relation parent-enfant, ce qui signifie que le parent peut référencer sa cible enfant, mais pas l'inverse
• Xcode 4 a introduit l'espace de travail, qui est une relation fraternelle, ce qui signifie que tout projet peut référencer des projets dans le même espace de travail

Lorsque j'ai utilisé CocoaPods pour développer des projets iOS, il y a un .xcworkspacefichier, vous devez ouvrir le projet avec un .xcworkspacefichier lié à CocoaPods.

Mais lorsque vous avez Show Package Contentsun .xcworkspacefichier, vous trouverez le contents.xcworkspacedatafichier.

<?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>

faites attention à cette ligne:

location = "group:BluetoothColorLamp24G.xcodeproj"

Le .xcworkspacefichier fait référence au .xcodeprojfichier.

Environnement de développement:

macOS 10.14
Xcode 10.1

1. Quelle est la différence entre les deux?
   Workspace est un ensemble de projets

2. De quoi sont-ils responsables?
   Le projet est responsable du code source. Workspace est responsable des dépendances entre les projets

3. Avec laquelle dois-je travailler lorsque je développe mes applications en équipe / seul?
   Votre choix doit dépendre du type de votre projet. Par exemple, si votre projet s'appuie sur le gestionnaire de dépendances CocoaPods, il crée un espace de travail.

4. Y a-t-il autre chose que je devrais être au courant de ces deux fichiers?
   Un concurrent de workspace est cross-project references^[About]

[Composants Xcode]