Знайте о файлах .xcconfig и добавляйте различные конфигурации, такие как подготовка и производство, в свое приложение iOS, используя файлы .xcconfig в Swift.
Если вы хотите настроить отдельные среды/конфигурации, такие как подготовка, отладка и выпуск в своем приложении для iOS, то вы попали по адресу. Настройка различных сред/конфигураций в вашем приложении действительно важна и полезна. Прежде чем начать настройку, мы должны понять, зачем нам вообще нужны отдельные среды или конфигурации в нашей iOS или проекте.
Наличие отдельных конфигураций, таких как отладка и выпуск в вашем приложении для iOS, является необходимостью; Они помогают вам несколькими способами, включая следующие:
- Отличайте свои ключи API для продакшена
- Создайте отдельные конечные точки API для отдельных конфигураций.
- Поместите отдельные сторонние библиотеки в отладочную сборку, чтобы упростить тестирование. Например, иметь отдельные Crashlytics для отладочных сборок. Примечание. Crashlytics предоставляет способ сделать это.
- Имейте отдельные ключи или токены для своих платных библиотек. Большинство библиотек предоставляют способы бесплатного тестирования, потому что вы не хотите тестировать в продакшене и получать за это счет.
- Предоставьте инструмент отладки. Когда вы работаете в большой команде или в небольшой команде, хорошо иметь некоторые инструменты отладки, такие как Network Interceptor, сообщения об ошибках и т. д., в ваших тестовых сборках, чтобы тестирование могло проходить беспрепятственно.
- Монтаж. Вы можете одновременно установить одно и то же приложение с разными конфигурациями на одно и то же устройство.
Я надеюсь, что к настоящему моменту мы пришли к единому мнению, что нам нужны отдельные среды или конфигурации в нашем приложении для iOS. Теперь возникает вопрос, как мы должны это реализовать. Есть много способов сделать это, но, к счастью, Xcode предоставляет очень удобный способ сделать это с помощью файлов Xcconfig. Итак, давайте узнаем о них и реализуем их.
В этой статье мы рассмотрим:
- Знание файлов XCConfig
- Как использовать их для отдельных сред и целей
- Как определить и управлять различными настройками сборки с помощью xcconfig
- Как получить доступ к значениям параметров сборки из кода
Итак, что такое файлы xcconfig? xcconfig означает файлы конфигурации Xcode, и они представляют собой обычный текстовый файл, содержащий пары ключ-значение, которые помогают определять или переопределять существующие параметры сборки для любого проекта или конфигурации сборки цели.
Один определяет конфигурации сборки на уровне проекта; вот почему их также можно использовать среди различных целей в вашем проекте.
Мы можем использовать панель настроек сборки в Xcode, чтобы изменить эти настройки, но это становится затруднительно, если у вас есть несколько целей. Кроме того, он более подвержен ошибкам, тогда как файлы xcconfig — это простой способ справиться со всеми этими вещами.
Файлы Xcconfig также обеспечивают наследование и содержат условные операторы для ваших параметров сборки, что полезно при совместном использовании параметров и настройке. Если вы чувствуете себя перегруженным этим, не волнуйтесь, мы рассмотрим пример. Он действительно прост и удобен в использовании.
Достаточно теории о файлах xcconfig. Давайте сделаем демонстрационный проект и запачкаем руки.
Существующие конфигурации и создание новой для нашего проекта
Я создал новое приложение с именем ConfigTest в Xcode. Не стесняйтесь кодировать вместе. Если вам не хочется программировать, скачайте готовый код, откройте проект и следуйте дальше.
Таким образом, всякий раз, когда создается новый проект, Xcode по умолчанию создает две конфигурации: Debug и Release. Вы можете увидеть это на следующем снимке экрана. Чтобы просмотреть его в своем проекте, выберите файл проекта, щелкните проект и перейдите на вкладку информации.
Давайте создадим новую конфигурацию, нажав кнопку «плюс» в разделе «Конфигурации». Должно появиться следующее всплывающее окно. Мы можем дублировать любую из конфигураций.
Мы назовем нашу новую конфигурацию Staging. Он должен начать отображать новую конфигурацию, которую вы можете увидеть ниже. Вот и все. Вот как вы создаете новую конфигурацию в Xcode.
Создание файла настроек конфигурации
Давайте создадим файлы xcconfig, чтобы задать значения для наших трех конфигураций. Нажмите command + N или Файл -> Создать -> Файл. Вам будет предложено следующее окно. Выберите файл настроек конфигурации. Вы также можете выполнить поиск, если не можете найти этот файл.
Я называю свои файлы на основе их имен конфигурации, чтобы их было легко запомнить. Не стесняйтесь называть их как хотите.
Примечание. Убедитесь, что у вас не выбрана ни одна цель. Как упоминалось ранее, мы добавляем эти файлы на уровне проекта.
Теперь создайте еще два файла конфигурации для двух других конфигураций. Я назвал свои файлы Release.xcconfig, Debug.xcconfig и Staging.xcconfig. Пришло время поместить код в эти файлы.
Откройте файл Debug.xcconfig и введите следующий код:
PRODUCT_BUNDLE_IDENTIFIER = com.anandnigam.ConfigTest.debug BUNDLE_DISPLAY_NAME = ConfigTestDebug
Свойство BUNDLE_DISPLAY_NAME поможет вам создать разные имена приложений для отдельных конфигураций, а PRODUCT_BUNDLE_IDENTIFIER поможет запустить сборку с отдельными конфигурациями, не удаляя предыдущую с телефона или симулятора.
Затем добавьте следующий код в файл Staging.xcconfig:
PRODUCT_BUNDLE_IDENTIFIER = com.anandnigam.ConfigTest.staging BUNDLE_DISPLAY_NAME = ConfigTestStaging
Добавьте следующий код в файл Release.xcconfig:
PRODUCT_BUNDLE_IDENTIFIER = com.anandnigam.ConfigTest BUNDLE_DISPLAY_NAME = ConfigTest
Итак, теперь, когда мы добавили код в наши файлы xcconfig, нам нужно назначить нашим файлам соответствующие конфигурации перед их тестированием. Перейдите на вкладку информации вашего проекта, разверните все конфигурации и передайте имена ваших файлов в соответствующие конфигурации, как показано ниже. Убедитесь, что вы назначили все три (или больше, если у вас больше конфигураций).
Теперь option + click на названии вашего приложения рядом с симулятором; это откроет меню ниже. Или вы можете щелкнуть имя своего приложения и выбрать «Редактировать схему»; откроется такое же меню ниже. Здесь вы можете выбрать любую конфигурацию, которую хотите запустить.
Таким образом, после запуска всех конфигураций вы можете увидеть несколько приложений, подобных приведенному ниже, в симуляторе или на iPhone. Мы можем запускать приложение с разными именами и иметь их на одном устройстве одновременно.
Следует отметить, что вы также можете использовать ключ APP_NAME и указать для него другие значения в файлах конфигурации вместо BUNDLE_DISPLAY_NAME, но это может вызвать проблемы, если у вас есть тестовые цели в существующем приложении. Я столкнулся с этой проблемой, поэтому для простоты я меняю только ключ BUNDLE_DISPLAY_NAME, но не стесняйтесь экспериментировать.
Один важный совет: это применимо только в том случае, если вы используете какао-поды. В противном случае вы можете пропустить его.
Если вы собираетесь интегрировать эту штуку в существующую кодовую базу, которая использует Cocopods в качестве менеджера зависимостей, вам нужно будет выполнить следующие шаги:
- Удалите файл
.xcworkspace, каталогPodfile.lockиPods/. - Запустить установку модуля
- Откройте новый .xcworkspace
- Включите следующую строку вверху в соответствующие файлы конфигурации.
В Release.xcconfig
#include “Pods/Target Support Files/Pods-YourAppName/Pods-YourAppName.release.xcconfig”
В Staging.xcconfig
#include “Pods/Target Support Files/Pods-YourAppName/Pods-YourAppName.staging.xcconfig”
В Debug.xcconfig
#include “Pods/Target Support Files/Pods-YourAppName/Pods-YourAppName.debug.xcconfig”
Вы можете найти эти файлы xcconfig, связанные с модулями, по этим путям. Если у вас есть pod’ы по пути, отличному от пути обычной установки Cocoapods, вы можете найти эти файлы в каталоге Pods и указать их пути.
Идем дальше. Это самое простое, что мы только что сделали, используя файлы xcconfig. Теперь давайте перейдем на следующий уровень и сделаем некоторые более сложные вещи, такие как использование наследования, наличие условий в файлах конфигурации, получение значений из файлов конфигурации в вашей кодовой базе, а также как настроить, если у вас есть несколько целей, таких как расширение виджета или расширение общего доступа. для вашего приложения
Наследование и условные операторы в файлах конфигурации
Давайте начнем с наследования и добавления условий в ваши файлы конфигурации. Для этого давайте создадим новый файл конфигурации с именем Base.xcconfig, как мы делали с другими файлами ранее. Откройте файл и вставьте следующий код:
//MARK: - App Settings BASE_BUNDLE_IDENTIFIER = com.anandnigam.ConfigTest BUNDLE_DISPLAY_NAME = ConfigTest //MARK: - Conditional Checks ONLY_ACTIVE_ARCH[config=Debug][sdk=*][arch=*] = YES
Здесь мы определяем идентификатор базового пакета, чтобы мы могли наследовать его и добавлять к нему элементы для наших различных конфигураций.
Мы также определяем значение по умолчанию BUNDLE_DISPLAY_NAME.
Теперь в третьей строке мы устанавливаем флаг для сборки только активной архитектуры, когда конфигурация отлаживается для любого SDK для любой архитектуры. * означает любой, когда мы работаем с конфигурационным файлом.
Общий синтаксис для условного оператора:
BUILD_SETTINGS_NAME_KEY[condition=value] = VALUE
Теперь, чтобы увидеть наследство, откройте файл Debug.xcconfig и замените код следующим:
#include "Base.xcconfig" PRODUCT_BUNDLE_IDENTIFIER = $(BASE_BUNDLE_IDENTIFIER).debug BUNDLE_DISPLAY_NAME = $(inherited)Debug
Что тут происходит
- Мы наследуем файл
Base.xcconfigв нашем файлеDebug.xcconfig - Мы используем значение ключа
BASE_BUNDLE_IDENTIFIERиз файлаBase.xcconfigв нашем файлеDebug.xcconfig. если вы хотите использовать любое значение из вашего базового файла конфигурации, вам просто нужно определить такой ключ, как этот$(KEY_NAME). Затем вы можете получить значение и использовать его. - Во время этого процесса мы переопределяем значение того же ключа из файла
Base.xcconfig, наследуя значение и добавляя что-то свое.
Итак, это два основных способа, которыми мы можем наследовать, переопределять или использовать значения из других файлов конфигурации в нашем файле конфигурации. Они помогают свести к минимуму усилия по определению различных значений и их использованию.
Теперь, пожалуйста, сделайте следующие изменения в соответствующих файлах
В файле Staging.xcconfig
#include “Base.xcconfig” //MARK: — App Settings // to use any value defined in the inherited file PRODUCT_BUNDLE_IDENTIFIER = $(BASE_BUNDLE_IDENTIFIER).staging // to inherit the value from the included config file BUNDLE_DISPLAY_NAME = $(inherited)Staging
В файле Release.xcconfig
#include "Base.xcconfig" //MARK: - App Settings PRODUCT_BUNDLE_IDENTIFIER = $(BASE_BUNDLE_IDENTIFIER)
Примечание. В файле Release.xcconfig мы не определяем BUNDLE_DISPLAY_NAME. Вместо этого конфигурация выпуска будет использовать ключ-значение из файла Base.xcconfig при запуске. Таким образом, мы можем использовать значение из Base.xcconfig, если не хотим его настраивать.
Определение данных, связанных с конфигурацией, и их получение
Теперь есть еще одна важная вещь, которую эти файлы конфигурации могут сделать полезной. Таким образом, совершенно очевидно, что для разных конфигураций могут потребоваться разные URL-адреса или ключи API. Это гарантирует, что вы не попадете в производственные серверы или не используете ключи API, связанные с производством, во время отладки или передачи тестовых сборок в QA.
Итак, давайте определим некоторые API-ключи и URL-адреса в наших файлах конфигурации.
Вставьте следующий код в соответствующие файлы:
В Staging.xcconfig
//MARK: - API Keys FIREBASE_KEY = acnkdjkbvjfbvfibvfj //MARK: - Server URLs BASE_URL = https:/$()/anand2nigam.medium.com
В Debug.xcconfig
//MARK: - API Keys FIREBASE_KEY = acnkdjkbvjfbvfibvfj //MARK: - Server URLs BASE_URL = https:/$()/www.linkedin.com/in/anand2nigam/
В Release.xcconfig
//MARK: - API Keys FIREBASE_KEY = acnkdjkbvjfbvfibvfjscdnkjvrhb //MARK: - Server URLs BASE_URL = https:/$()/github.com/anand2nigam
Я намеренно добавил случайный ключ API и разные базовые URL-адреса, чтобы показать, как мы получим эти значения в каждом из разных файлов конфигурации.
Теперь перейдите к файлу Info.plist и добавьте все ключи, которые вам понадобятся, чтобы получить значения для использования в вашей кодовой базе. В этом примере мы собираемся добавить BUNDLE_DISPLAY_NAME и BASE_URL.
Убедитесь, что вы добавили правильное имя ключа из файла конфигурации в столбец значений в файле Info.plist. Ключевой столбец Info.plist может быть заполнен в зависимости от имени, которое нужно получить для ключа. Я сохраняю это же, чтобы избежать путаницы. Вот скриншот в помощь:
Выполнив вышеуказанные действия, мы разместили все значения, которые хотим получить. Теперь давайте посмотрим, как мы можем получить эти значения. Таким образом, простым ответом было бы получить ключ из Info.plist и получить значение, определенное в файле конфигурации.
Мы собираемся сделать то же самое. Создадим новый файл; Я называю его Config.swift и добавляю следующий код:
Этот файл создает уровень абстракции, который поможет нам извлекать значения (с правильным именем ключа) из файла Info.plist и использовать их в кодовой базе. Пришло время протестировать наш код и посмотреть, работает ли он вообще. Вставьте следующий код в файл ViewController.swift, созданный Xcode для нас:
Это покажет базовое значение URL-адреса в предупреждающем сообщении для нас. Теперь запустите приложение в разных конфигурациях, и вы заметите, что мы можем использовать соответствующие базовые URL-адреса, определенные в файлах конфигурации.
Есть еще один способ увидеть и проверить эти свойства в пользовательском интерфейсе. Перейдите к своей цели и выберите «Настройки сборки». Прокрутите вниз. Вы можете увидеть все свои свойства в разделе «Определено пользователем», как показано на снимке экрана:
Использование файлов xcconfig для нескольких целей
Теперь давайте рассмотрим случай, когда у вас есть несколько целей. В этом случае лучше иметь для них отдельные конфиги, чтобы не было путаницы. Но можно также использовать один и тот же файл конфигурации, определив разные ключи и используя их в разных целях. В этой статье мы объявим отдельные файлы конфигурации, что является лучшим способом справиться с этим случаем.
Итак, давайте добавим расширение виджета для нашего небольшого приложения ConfigTest. Перейдите в «Цели» и нажмите кнопку «плюс» внизу. Вам будет предложено следующее окно. Идите вперед и назовите расширение вашего виджета. Я назвал свой ConfigTestWidget.
Теперь давайте создадим три новых файла конфигурации. Я назвал их WidgetStaging, WidgetRelease и WidgetDebug. Теперь перейдите на вкладку «Информация о проекте», разверните все конфигурации и назначьте соответствующие файлы конфигурации их целям, как показано на следующем снимке экрана:
Этот процесс аналогичен тому, что мы делали ранее. Я также разместил различные файлы конфигурации в своих папках, как показано на скриншоте выше. Не стесняйтесь делать то же самое.
Теперь вставьте в их файлы следующий код:
В WidgetStaging.config
#include "ConfigFiles/ConfigTestTarget/Staging.xcconfig" PRODUCT_BUNDLE_IDENTIFIER = $(inherited).ConfigTestWidget
В WidgetDebug.config
#include "ConfigFiles/ConfigTestTarget/Debug.xcconfig" PRODUCT_BUNDLE_IDENTIFIER = $(inherited).ConfigTestWidget
В WidgetRelease.config
#include "ConfigFiles/ConfigTestTarget/Release.xcconfig" PRODUCT_BUNDLE_IDENTIFIER = $(inherited).ConfigTestWidget
Как вы, должно быть, заметили, мы наследуем значение PRODUCT_BUNDLE_IDENTIFIER и добавляем имя нашего виджета. Это снова пример наследования в файлах xcconfig, а также за идентификаторами пакетов расширений должен следовать идентификатор пакета их приложения. Таким образом, мы избавляем себя от необходимости повторять идентификатор пакета приложения.
Теперь вы можете запустить приложение и использовать виджет для различных конфигураций. Я добавил код в виджет, чтобы сэкономить время. Не стесняйтесь брать его с GitHub. Это должно выглядеть примерно так, как показано на следующем снимке экрана:
Теперь вы сможете запускать три конфигурации с разными именами приложений и другими свойствами, не удаляя ни одно приложение с устройства. Мы также можем назначить отдельные значки приложений для разных конфигураций. Просто добавьте еще один значок приложения, установленный в Assets.xcassets, с именем вроде AppIcon-Debug и определите следующий ключ в ваших файлах конфигурации:
В Debug.xcconfig и в Staging.xcconfig
ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon-Debug
В Release.xcconfig
ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon
Если ваши изменения не отразятся, перейдите к настройкам сборки Target и найдите этот ключевой значок основного набора приложений. Дважды нажмите и отредактируйте поле с помощью $(inherited). Это начнет принимать значения из ваших файлов xcconfig, и это будет выглядеть примерно так, как показано на следующем снимке экрана:
Вот и все. Это охватывает большую часть информации о файлах xcconfig, которые потребуются для реализации в новом или существующем проекте. В этом уроке мы рассмотрели следующее:
- Как настроить приложение для нескольких сред/конфигураций, таких как подготовка, отладка и выпуск
- Как использовать файлы xcconfig для этого
- Как разделить значения между разными файлами конфигурации
- Как получить значения из значений конфигурации
Со всеми этими вещами, связанными с конфигурационными файлами, вы можете идти и настраивать свои проекты. Не стесняйтесь искать весь приведенный выше код на GitHub и использовать его для справки.
Рекомендации
https://help.apple.com/xcode/mac/8.3/#/dev745c5c974
https://help.apple.com/xcode/mac/8.3/#/itcaec37c2a6
Эти ссылки помогут вам больше узнать о других свойствах и вещах в файлах xcconfig. Спасибо за прочтение.
Want to Connect? You can find me on LinkedIn.
