Кодовая база статической библиотеки iOS для приложений с белой этикеткой
Я ищу лучший подход к настройке нашего приложения для iOS, чтобы мы могли легко создавать его версии с белым ярлыком и синхронизировать их все.
Один из подходов - поместить всю кодовую базу в статический проект библиотеки. Затем создайте отдельный проект для нашего основного приложения и каждого приложения с белой этикеткой. Каждый из этих проектов будет содержать ссылку на библиотеку кодовой базы в качестве подпроекта и свои собственные ресурсы, такие как значки, изображения загрузки и файл Info.plist.
Мой коллега успешно использовал этот подход в нашем дочернем проекте Android в Eclipse.
К сожалению, этот подход может не работать в xcode. Похоже, что xcode не позволяет некоторым ресурсам связываться со статической библиотекой, например, Settings.bundle и Localizable.strings, которые необходимы.
Есть ли способ, которым я могу использовать этот подход в xcode, или мне лучше просто ссылаться на папку codebase из каждого проекта?
Редактировать:
Первоначально я планировал просто ссылаться на папку codebase из каждого проекта, но обнаружил, что этот подход потребует повторного добавления каталога codebase в каждом проекте каждый раз, когда файл добавляется / удаляется / переименовывается в codebase.
3 ответа
Я сделал приложения с белой маркировкой. Вы должны сначала попробовать цели. Цели содержатся в проектах. Вы можете включить свои источники в тот же проект. Поместите все, что варьируется, в несколько файлов и укажите, какие из этих файлов вы включаете в каждую цель.
Вам все равно нужно будет убедиться, что файлы находятся во всех ваших целях, но вам будет предложено или вы получите ошибку компоновки, и если вы пропустите файл, включающий его, просто установите флажок.
Вы можете сохранить целевые файлы довольно ограниченными. У меня есть общий файл xcassets и один для каждой цели. У меня также есть отдельные списки и несколько других ресурсов для каждой цели. Все остальное поделено.
Рекомендации:
Как платный консалтинговый проект, я пересматриваю стратегии компании. Они создали серию файлов.sh, которые копируют всю сборку в новое имя, включая новый.plist и файл проекта.
Чего они не учли, так это версий этих приложений; поэтому я думаю, что библиотеки - это лучший подход, если вы можете создать свое приложение как таковое. Вполне возможно, что у вас может быть несколько версий одного и того же белого приложения. (Кошмар в лучшем случае!!! LOL)
Еще одна вещь, на которую вы можете захотеть взглянуть - это CocoaPods. Я не использовал его, но у меня были друзья, которым они нравятся, потому что это помогает в управлении библиотеками - особенно при переходе из одной среды разработки в другую. Мне нужно использовать его в следующем месяце из-за путаницы в пути Zxing, с которой все сталкиваются.
https://github.com/CocoaPods/CocoaPods
Последняя рекомендация - используйте Source Control, как будто завтра не наступит!!!
Вы не можете автоматически связывать ресурсы со статической библиотекой, но ничто не мешает вам включать общие ресурсы вручную. Вы можете создать рабочее пространство для настроенного проекта, вставить проект библиотеки в рабочее пространство и затем перетащить группу ресурсов из дерева проекта библиотеки в основной проект.