Я намагаюся зрозуміти, як працює вся екосистема iOS.
До сих пір я міг знайти відповідь на більшість мого запитання (і, повірте, їх було багато), але на це, мабуть, немає однозначної відповіді.
Чим відрізняються файли XcodeProject від XcodeWorkspace?
Відповіді:
Я думаю, що є три ключові пункти, які потрібно розуміти щодо структури проекту: Цілі , проекти та робочі простори . Цілі детально визначають, як будується продукт / двійковий файл (тобто додаток або бібліотека). Вони включають параметри збірки, такі як прапорці компілятора та посилання, і вони визначають, які файли (вихідний код та ресурси) насправді належать продукту. Під час створення / запуску ви завжди вибираєте одну конкретну ціль.
Цілком імовірно, що у вас є кілька цілей, які діляться кодом та ресурсами. Ці різні цілі можуть бути дещо різними версіями програми (iPad / iPhone, різні бренди, ...) або тестовими випадками, які, природно, потребують доступу до тих же вихідних файлів, що і додаток. Усі ці пов'язані цілі можна згрупувати в проекті . Хоча проект містить файли з усіх своїх цілей, кожна мета вибирає свій підмножину відповідних файлів. Те саме стосується налаштувань збірки: Ви можете визначити параметри для проекту за замовчуванням у проекті, але якщо одна з ваших цілей потребує інших налаштувань, ви завжди можете їх замінити:
Спільні налаштування проекту, які успадковують усі цілі, якщо тільки вони не перекриють його
Конкретні налаштування цілі: PSE iPhone має пріоритет проекту Base SDKнастройки
У Xcode ви завжди відкриваєте проекти (або робочі простори, але не цілі), і всі цілі, які він містить, можна будувати / виконувати, але немає способу / визначення побудови проекту, тому для кожного проекту потрібна хоча б одна ціль, щоб бути не просто колекцією файлів та налаштувань.
Виберіть одну з цілей проекту, яку потрібно виконати
У багатьох випадках проекти - це все, що вам потрібно. Якщо у вас є залежність, яку ви будуєте з джерела, ви можете вбудовувати її як підпроект . Підпроекти можна відкрити окремо або в рамках їх суперпроекту.
demoLib - це підпроект
Якщо додати одну з цілей підпроекту до залежностей суперпроекту, підпроект буде автоматично побудований, якщо він не залишився незмінним. Перевага тут полягає в тому, що ви можете редагувати файли як вашого проекту, так і ваших залежностей у одному вікні Xcode, і коли ви будуєте / запускаєте, ви можете вибрати з цілей проекту та його підпроектів:
Однак, якщо ваша бібліотека (підпроект) використовується в різних інших проектах (або, якщо бути точним), має сенс розмістити її на тому ж рівні ієрархії - саме для цього працюють робочі простори . Робочі простори містять та керують проектами, а всі проекти, до яких він безпосередньо входить (тобто не їх підпроекти), знаходяться на одному рівні, і їх цілі можуть залежати один від одного (цілі проектів можуть залежати від цілей підпроектів, але не навпаки).
Структура робочої області
У цьому прикладі обидва додатки ( AnotherApplication / ProjectStructureExample ) можуть посилатися на цілі проекту demoLib . Це також можливо, включивши проект demoLib до обох інших проектів як підпроект (який є лише посиланням, тому дублювання не потрібно), але якщо у вас багато перехресних залежностей, робочі простори мають більше сенсу. Якщо ви відкриєте робочу область, ви можете вибирати цілі всіх проектів під час створення / запуску.
Ви все одно можете відкривати файли проектів окремо, але, ймовірно, їх цілі не будуватимуться, оскільки Xcode не може вирішити залежності, якщо ви не відкриєте файл робочої області. Робочі простори дають ту саму перевагу, що і підпроекти: Після зміни залежності Xcode відновить її, щоб переконатися, що вона актуальна (хоча у мене виникли деякі проблеми з цим, схоже, вона не працює надійно).
Ваші питання в двох словах :
1) Проекти містять файли (код / resouces), налаштування та цілі, які створюють продукти з цих файлів та налаштувань. Робочі простори містять проекти, які можуть посилатися один на одного.
2) Обоє відповідають за структурування вашого загального проекту, але на різних рівнях.
3) Я думаю, що проектів у більшості випадків достатньо. Не використовуйте робочі простори, якщо немає конкретної причини. Крім того, ви завжди можете вбудувати свій проект у робочу область пізніше.
4) Я думаю, що саме для цього описаний текст ...
Є одне зауваження для 3): CocoaPods , який автоматично обробляє сторонні бібліотеки для вас, використовує робочі простори. Тому вам доведеться їх використовувати і тоді, коли ви користуєтесь CocoaPods(що робить багато людей).
Робоча область - це сукупність проектів. Корисно впорядковувати свої проекти, коли між ними існує кореляція (наприклад: Проект A включає бібліотеку, яка надається як сам проект як проект B. Коли ви створюєте робочу область, проект B збирається та зв'язується в проекті A).
У популярних CocoaPods прийнято використовувати робочу область . Коли ви встановлюєте свої стручки, вони розміщуються всередині робочої області, яка містить ваш проект та бібліотеки стручок.
Коротко
Коли я використовував CocoaPods для розробки проектів iOS, є .xcworkspaceфайл, вам потрібно відкрити проект із .xcworkspaceфайлом, пов’язаним із CocoaPods.
Але коли ви Show Package Contentsз .xcworkspaceфайлом, ви знайдете 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>зверніть увагу на цей рядок:
location = "group:BluetoothColorLamp24G.xcodeproj"
.xcworkspaceФайл має посилання з .xcodeprojфайлом.
Середовище розвитку:
macOS 10.14
Xcode 10.1Яка різниця між ними?
Робоча область - це набір проектів
За що вони відповідають?
Проект відповідає за вихідний код. Робоча область відповідає за залежність між проектами
З якою з них я повинен працювати, коли розробляю свої програми в команді / поодинці?
Ваш вибір повинен залежати від типу вашого проекту. Наприклад, якщо ваш проект покладається на менеджера залежності CocoaPods, він створює робочу область.
Чи є ще щось, про що я маю знати, у питанні цих двох файлів?
Конкурентом робочої області є cross-project references[About]