Projet Xcode et espace de travail Xcode - Différences
J'essaie de comprendre comment fonctionne tout l'écosystème de 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?
- Quelle est la différence entre les deux?
- De quoi sont-ils responsables?
- Avec lequel devrais-je travailler lorsque je développe mes applications en équipe/seul?
- Y at-il autre chose que je devrais savoir à propos de ces deux fichiers?
Je pense que vous devez comprendre trois éléments clés en ce qui concerne la structure du projet: Cibles , projets et 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 des paramètres de construction, tels que les indicateurs de compilateur et d'éditeur de liens, et définissent les fichiers (code source et ressources) appartenant 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 partageant du code et des ressources. Ces différentes cibles peuvent être des versions légèrement différentes d'une application (iPad/iPhone, marques différentes,…) ou des scénarios de test qui doivent naturellement accéder aux mêmes fichiers source 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 construction: vous pouvez définir des paramètres par défaut pour l'ensemble du 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'ils ne l'ignorent
Paramètres de cible concrète: PSE iPhone annule le paramètre Base SDK 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’existe aucun moyen/définition de la construction d’un projet. Par conséquent, chaque projet a besoin d’au moins une cible pour pouvoir: ê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 créez une dépendance à partir de la source, vous pouvez l'incorporer 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, sauf s’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 Xcode et, lors de la création/exécution, vous pouvez sélectionner parmi les cibles du projet et de ses sous-projets:
Toutefois, si votre bibliothèque (le sous-projet) est utilisée par plusieurs 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 les espaces de travail sont pour. Les espaces de travail contiennent et gèrent des projets. Tous les projets qu’il inclut 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).
Structure de l'espace de travail
Dans cet exemple, les deux applications ( AnotherApplication / ProjectStructureExample ) peuvent référencer le demoLib les objectifs du projet. Cela serait également possible en incluant le projet demoLib dans les deux autres projets en tant que sous-projet (qui est une référence uniquement, aucune duplication nécessaire), mais si vous avez beaucoup de les dépendances, 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 création/de l’exécution.
Vous pouvez toujours ouvrir vos fichiers de projet séparément, mais leurs cibles ne seront probablement pas générées, car Xcode ne peut résoudre les dépendances que si vous ouvrez le fichier d’espace de travail. Les espaces de travail offrent les mêmes avantages que les sous-projets: une fois qu’une dépendance a été modifiée, Xcode la reconstruira pour s’assurer qu’elle est à jour (bien que j’ai eu quelques problèmes avec cela, cela ne semble pas fonctionner de manière fiable).
Vos questions en quelques mots :
1) Les projets contiennent des fichiers (code/ressources), des paramètres et des cibles permettant de créer des produits à partir de ces fichiers et paramètres. Les espaces de travail contiennent des projets pouvant se référencer.
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 d’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 la raison pour laquelle le texte ci-dessus est…
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 font beaucoup de gens).
Un espace de travail est un ensemble de projets. Il est utile d'organiser vos projets lorsqu'il existe une corrélation entre eux (par exemple: le projet A inclut une bibliothèque, 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 le populaire CocoaPods . 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 introduit l'espace de travail, qui est une relation de parenté, 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 fichier .xcworkspace, vous devez l'ouvrir avec le fichier .xcworkspace associé à CocoaPods.
Mais lorsque vous Show Package Contents avec le fichier .xcworkspace, vous trouverez le fichier contents.xcworkspacedata.
<?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 fichier .xcworkspace est référencé avec le fichier .xcodeproj.
Environnement de développement:macOS 10.14 Xcode 10.1