Ik probeer te begrijpen hoe het hele ecosysteem van iOSwerkt.
Tot nu toe kon ik een antwoord vinden op de meeste van mijn vragen (en geloof me, er zijn er veel geweest), maar voor deze lijkt er nog geen duidelijk antwoord te zijn.
Wat is het verschil tussen XcodeProject- en XcodeWorkspace-bestanden?
- Wat is het verschil tussen de twee?
- Waar zijn ze verantwoordelijk voor?
- Met welke moet ik werken als ik mijn apps in teamverband/alleen ontwikkel?
- Is er nog iets anders waar ik op moet letten met betrekking tot deze twee bestanden?
Antwoord 1, autoriteit 100%
Ik denk dat er drie belangrijke dingen zijn die je moet begrijpen met betrekking tot de projectstructuur: Doelen, projectenen werkruimten. Doelenspecificeren in detail hoe een product/binary (d.w.z. een applicatie of bibliotheek) is gebouwd. Ze bevatten build-instellingen, zoals compiler- en linkervlaggen, en ze definiëren welke bestanden (broncode en bronnen) daadwerkelijk bij een product horen. Wanneer je bouwt/rennen, selecteer je altijd één specifiek doel.
Het is waarschijnlijk dat u een paar doelen heeft die code en bronnen delen. Deze verschillende doelen kunnen licht verschillende versies van een app zijn (iPad/iPhone, verschillende brandings,…) of testcases die natuurlijk dezelfde bronbestanden moeten benaderen als de app. Al deze gerelateerde doelen kunnen worden gegroepeerd in een project. Terwijl het project de bestanden van al zijn doelen bevat, kiest elk doel zijn eigen subset van relevante bestanden. Hetzelfde geldt voor build-instellingen: u kunt standaard projectbrede instellingen in het project definiëren, maar als een van uw doelen andere instellingen nodig heeft, kunt u ze daar altijd overschrijven:
Gedeelde projectinstellingen die alle doelen overnemen, tenzij ze deze overschrijven
Concrete doelinstellingen: PSE iPhoneoverschrijft de Base SDK-instelling van het project
In Xcode open je altijd projecten (of werkruimten, maar geen doelen), en alle doelen die het bevat kunnen worden gebouwd/uitgevoerd, maar er is geen manier/definitie om een project te bouwen, dus elk project heeft ten minste één doel nodig om meer te zijn dan alleen een verzameling bestanden en instellingen.
Selecteer een van de doelen van het project om uit te voeren
In veel gevallen zijn projecten alles wat je nodig hebt. Als je een afhankelijkheid hebt die je bouwt vanuit de broncode, kun je deze insluiten als een subproject. Subprojecten kunnen afzonderlijk of binnen hun superproject worden geopend.
demoLibis een deelproject
Als u een van de doelen van het subproject toevoegt aan de afhankelijkheden van het superproject, wordt het subproject automatisch gebouwd, tenzij het ongewijzigd is gebleven. Het voordeel hier is dat u bestanden van zowel uw project als uw afhankelijkheden in hetzelfde Xcode-venster kunt bewerken, en wanneer u bouwt/uitvoert, kunt u kiezen uit de doelen van het project en zijn subprojecten:
Als uw bibliotheek (het subproject) echter wordt gebruikt door een verscheidenheid aan andere projecten (of hun doelen, om precies te zijn), is het logisch om deze op hetzelfde hiërarchieniveau te plaatsen – dat is wat werkruimtenzijn voor. Werkruimten bevatten en beheren projecten, en alle projecten die het direct omvat (dwz niet hun subprojecten) bevinden zich op hetzelfde niveau en hun doelen kunnen van elkaar afhangen (de doelen van projecten kunnen afhankelijk zijn van de doelen van subprojecten, maar niet omgekeerd).
Werkruimtestructuur
In dit voorbeeld kunnen beide apps (AnotherApplication/ ProjectStructureExample) verwijzen naar de doelen van het demoLib-project. Dit zou ook mogelijk zijn door het project demoLibop te nemen in beide andere projecten als een subproject (wat alleen een referentie is, dus geen duplicatie nodig), maar als je veel onderlinge afhankelijkheden hebt, maken werkruimten meer gevoel. Als je een werkruimte opent, kun je tijdens het bouwen/draaien kiezen uit de doelen van alle projecten.
U kunt uw projectbestanden nog steeds afzonderlijk openen, maar het is waarschijnlijk dat hun doelen niet worden gebouwd omdat Xcode de afhankelijkheden niet kan oplossen, tenzij u het werkruimtebestand opent. Werkruimten bieden hetzelfde voordeel als subprojecten: zodra een afhankelijkheid verandert, zal Xcode deze opnieuw opbouwen om ervoor te zorgen dat deze up-to-date is (hoewel ik daar wat problemen mee heb gehad, lijkt het niet betrouwbaar te werken).
Uw vragen in een notendop:
1) Projecten bevatten bestanden (code/bronnen), instellingen en doelen die producten bouwen op basis van die bestanden en instellingen. Werkruimten bevatten projecten die naar elkaar kunnen verwijzen.
2) Beide zijn verantwoordelijk voor het structureren van uw totale project, maar op verschillende niveaus.
3) Ik denk dat projecten in de meeste gevallen voldoende zijn. Gebruik geen werkruimten tenzij er een specifieke reden is. Bovendien kun je je project later altijd in een werkruimte insluiten.
4) Ik denk dat de bovenstaande tekst daar voor is…
Er is één opmerking voor 3): CocoaPods, dat automatisch bibliotheken van derden voor u afhandelt, gebruikt werkruimten. Daarom moet je ze ook gebruiken als je CocoaPodsgebruikt (wat veel mensen doen).
Antwoord 2, autoriteit 16%
Een werkruimte is een verzameling projecten. Het is handig om uw projecten te organiseren als er een correlatie tussen is (bijv.: Project A bevat een bibliotheek, die als project zelf wordt geleverd als project B. Wanneer u de werkruimte bouwt, wordt project B gecompileerd en gekoppeld in project A).
Het is gebruikelijk om een werkruimte te gebruiken in de populaire CocoaPods. Wanneer u uw pods installeert, worden ze in een werkruimte geplaatst, waarin uw project en de podbibliotheken zijn ondergebracht.
Antwoord 3, autoriteit 5%
In het kort
- Xcode 3 introduceerde een subproject, dat een ouder-kindrelatie is, wat betekent dat de ouder kan verwijzen naar zijn onderliggende doel, maar niet andersom
- Xcode 4 introduceerde werkruimte, wat een broer/zusrelatie is, wat betekent dat elk project kan verwijzen naar projecten in dezelfde werkruimte
Antwoord 4, autoriteit 2%
Xcode-werkruimte versus project
- Wat is het verschil tussen de twee?
Workspaceis een reeks projecten
- Waar zijn ze verantwoordelijk voor?
Workspaceis verantwoordelijk voor afhankelijkheden tussen projecten.
Projectis verantwoordelijk voor de broncode.
- Met welke moet ik werken als ik mijn apps in teamverband/alleen ontwikkel?
Uw keuze moet afhangen van het type project. Als uw project bijvoorbeeld afhankelijk is van CocoaPods-afhankelijkheidsmanager, wordt er een werkruimte gemaakt.
- Is er nog iets anders waar ik op moet letten met betrekking tot deze twee bestanden?
cross-project references[Over]