Привет, я Саня, iOS-разработчик в серфинг , и в этой статье я поделюсь своим методом решения головной боли, возникающей при работе над проектом с несколькими целями.
Предвижу вопрос «а зачем тебе, Саня, в проекте несколько мишенейЭ» Отвечаю: на проекте, где я когда-то работал, был один таргет, привязанный к аккаунту заказчика, поэтому:
- У нас не было доступа к этой учетной записи;
- не было возможности генерировать профили предоставления и сертификаты распределения;
- Хуже всего было то, что в профили обеспечения нельзя было добавлять новые устройства.
Решение было очевидным — создать второй таргет, который будет похож на основной, но иметь другой идентификатор бандла и который будет полностью привязан к аккаунту нашей студии.
Сказано - сделано! Вторая цель позволила нам провести полноценную разработку независимо от разработчиков на стороне заказчика, что не раз спасало наш процесс разработки, например, когда разработчики заказчика удаляли все наши устройства в профиле обеспечения основной цели и мы не смогли запустить приложение на наших устройствах.
При необходимости в вашем проекте все еще могут появиться несколько целей, например:
- построить несколько приложений из одной кодовой базы, но с разными ресурсами;
- храните несколько экземпляров приложения на одном устройстве.
Это очень сложно при работе в большом многоуровневом коллективе, как с точки зрения навыков, так и с точки зрения сплочённости.
Если не придерживаться этого простого правила, то после очередного слияния вы можете обнаружить, что одна из целей перестала собираться, а Xcode жалуется, что не может найти тот или иной класс.
Но самое интересное, что если кто-то не добавил файл из Copy Bundle Resources в обе цели (например, в ячейки xib), обнаружить такую ошибку можно только во время выполнения.
После очередной проблемы с целью Debug мы решили передать контроль над согласованностью целей сценарию.
В качестве инструмента мы выбрали язык Ruby, благо для него есть отличный гем xcodeproj , который является практически стандартом написания инструментов для iOS-разработки (см.
fastlane,generamba и т.п.
).
В результате мы разработали скрипт, реализующий следующую логику работы:
- На входе — путь к файлу проекта и имена проверяемых целей;
- по пути к проекту скрипт находит сам проект;
- выбирает нужные цели, собирает из них файлы (Compile Sources, Copy Bundle Resources и Frameworks);
- поиск различий между списками файлов;
- Из-за этой разницы мы исключаем файлы из нашего белого списка.
Например, файлы с константами, которые различаются в зависимости от цели (baseUrl, если вы решили организовать проект так, чтобы приложения с разных целей обращались к разным серверам), или файлы GoogleService-Info.plist, которые будут разными для разных целей.
Это означает, что тот или иной файл/фреймворк был добавлен в одну цель, но не добавлен в другую.
Таким образом, скрипт позволяет:
- убедитесь, что все файлы из источников компиляции и ресурсов копирования пакета правильно добавлены в обе цели;
- также проверяется идентичность списков добавленных фреймворков, что очень важно, если ваш проект имеет многомодульную архитектуру;
- интеграция скрипта в этап сборки позволит выявить проблему еще до фактического этапа сборки проекта;
- и если раньше вы собирали для этой цели обе цели на CI, то теперь можно оставить сборку только одной, сократив время сборки на CI вдвое.
В случае успеха вас ждет единорог:
Подробная инструкция по добавлению в проект, настройки, а также Пример-проект в репозитории .
Полученная утилита прекрасно показывает, что даже будучи iOS-разработчиком, вы можете добавить немного творчества в свою повседневную работу и начать автоматизировать и писать скрипты, которые упростят вам жизнь! Спасибо за внимание! Теги: #разработка iOS #разработка мобильных приложений #с открытым исходным кодом #ruby #разработка мобильных устройств #xcode #surf #surfstudio
-
Инструменты Сетевого Мониторинга
19 Oct, 24 -
Джинн
19 Oct, 24 -
Регистрация Кириллических Доменов В Зоне Su
19 Oct, 24 -
Хостинг.ua - Не Ожидал Такой Наглости
19 Oct, 24 -
Разработка Silverlight На Mac
19 Oct, 24
