Ответ 1
Я думаю, что есть три ключевых элемента, которые вам нужно понять относительно структуры проекта: Цели, проекты и рабочие пространства. Цели подробно определяют, как создается продукт/двоичный файл (т.е. приложение или библиотека). Они включают в себя настройки сборки, такие как флаги компилятора и компоновщика, и определяют, какие файлы (исходный код и ресурсы) действительно принадлежат продукту. Когда вы создаете/выполняете, вы всегда выбираете одну конкретную цель.
Вероятно, у вас есть несколько целей, которые разделяют код и ресурсы. Этими целями могут быть несколько разные версии приложения (iPad/iPhone, разные брендинги,...) или тестовые примеры, которые, естественно, должны иметь доступ к тем же исходным файлам, что и приложение. Все эти связанные задачи можно сгруппировать в проект. Хотя проект содержит файлы со всех своих целей, каждая цель выбирает свой собственный подмножество соответствующих файлов. То же самое можно сказать и о настройках сборки. Вы можете определить параметры проекта по умолчанию в проекте, но если одна из ваших целей нуждается в разных настройках, вы всегда можете их переопределить:
Общие параметры проекта, которые наследуют все целевые объекты, если они не переопределяют его
Конкретные целевые настройки: PSE iPhone переопределяет настройки проектов Base SDK
В Xcode вы всегда открываете проекты (или рабочие пространства, но не цели), и все цели, которые он содержит, могут быть созданы/запущены, но нет способа/определения построения проекта, поэтому для каждого проекта требуется хотя бы одна цель чтобы быть не просто набором файлов и настроек.
Выберите одну из целей проекта для запуска
Во многих случаях проекты - это все, что вам нужно. Если у вас есть зависимость, которую вы создаете из исходного кода, вы можете встроить ее в подпроект. Подпроекты могут быть открыты отдельно или в рамках своего суперпроекта.
demoLib - это подпроект
Если вы добавите одну из целевых подпроектов к зависимостям суперпроектов, подпроект будет автоматически построен, если он не останется без изменений. Преимущество здесь в том, что вы можете редактировать файлы как из своего проекта, так и из ваших зависимостей в одном окне Xcode, а когда вы создаете/запускаете, вы можете выбрать из проектов и целей его подпроектов:
Если, однако, ваша библиотека (подпроект) используется множеством других проектов (или их целей, если быть точным), имеет смысл поставить ее на один и тот же уровень иерархии - вот что workspaces для. Рабочие пространства содержат и управляют проектами, и все проекты, которые он включает напрямую (т.е. Не их подпроекты), находятся на одном уровне, и их цели могут зависеть друг от друга (цели проектов могут зависеть от целей подпроектов, но не наоборот).
Структура рабочего пространства
В этом примере оба приложения (AnotherApplication/ProjectStructureExample) могут ссылаться на цели проектов demoLib. Это также было бы возможно, включив проект demoLib в оба других проекта в качестве подпроекта (который является только ссылкой, поэтому не требуется дублирования), но если у вас много перекрестных зависимостей, рабочие пространства имеют больше смысла. Если вы откроете рабочее пространство, вы можете выбрать из всех целей проекта при построении/запуске.
Вы все равно можете открывать файлы проекта отдельно, но, скорее всего, их цели не будут созданы, потому что Xcode не может разрешить зависимости, если вы не откроете файл рабочей области. Рабочие пространства дают вам такое же преимущество, как и подпроекты: после изменения зависимости Xcode перестраивает его, чтобы убедиться в его обновлении (хотя у меня были некоторые проблемы с этим, он, похоже, не работает надежно).
Ваши вопросы в двух словах:
1) Проекты содержат файлы (код/resouces), настройки и целевые объекты, которые создают продукты из этих файлов и настроек. Рабочие области содержат проекты, которые могут ссылаться друг на друга.
2) Оба отвечают за структурирование вашего общего проекта, но на разных уровнях.
3) Я думаю, что проектов достаточно в большинстве случаев. Не используйте рабочие пространства, если только не существует конкретной причины. Кроме того, вы можете вставлять свой проект в рабочее пространство позже.
4) Я думаю, что это текст выше...
Это одно замечание для 3): CocoaPods, которое автоматически обрабатывает сторонние библиотеки для вас, использует рабочие области. Поэтому вы также должны использовать их, когда используете CocoaPods (что много людей).
