{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Конфигурационные файлы в Xcode

Многие из нас в своих домашних или рабочих проектах используют различные стенды для осуществления API запросов. Например для Debug сборок, мы можем общаться со своим локальным сервером, а для Release использовать настоящий сервис. Существует множество способов реализации этого разделения в приложении, а именно с помощью:

  1. Условных операторов в коде, которые проверяют флаг Debug / Release
  2. Смены значений переменных в lldb дебагера
  3. Использования конфигурационных файлов

Наиболее предпочтительным из всех вариантов - это использование конфигурационных файлов, т.к.:

  • Избавляет от необходимости вносить каждый раз правки в коде
  • Уменьшает количество потенциальных багов в приложении
  • Добавляет больше гибкости в управлении и автоматизации

Данный вариант мы и возьмем за основу в данной статье.

Наверняка уже многие встречались с файлами с расширением .xcconfig. Они содержат настройки в виде ключ-значение:

ENABLE_BITCODE = YES

Еще одно удобство заключается в том, что в конфиг файлах можно подставлять значения из других настроек:

HEADER_SEARCH_PATHS = ${PROJECT_DIR}

Давайте вернемся к нашему примеру с использованием различных API эндпоинтов и создадим xcconfig файл. Для этого используем комбинацию CMD + N или File > New > File. В секции Other выбираем Configuration Settings File.

Перед тем как задать имя конфиг файлу нужно убедиться, что конфиг не включен в какой-либо таргет

Targets не выбран при создании конфиг файла

После того как создали конфиг файл, назначаем его в нужный Target

Назначаем конфиг файл для дебаг схемы

Данный конфиг файл будет предоставлять нам данные (а именно эндпоинт) для локального / тестового сервиса, когда используется Debug схема.
Теперь нужно создать еще один конфиг файл, только теперь для Release схемы.

Итоговая настройка выглядит следующим образом:

Далее указываем наши эндпоинты в конфигах.

// // ReleaseConfig.xcconfig // ConfigurationTests // // Created by David Grigoryan // API_URL = api.production.service.com
// // DebugConfig.xcconfig // ConfigurationTests // // Created by David Grigoryan // API_URL = 192.168.1.10

Здесь стоит учесть что символы / (слеш) интерпретируются как комментарии, поэтому указывать схему эндпоинта или путь к нужному сервису необходимо в коде с помощью класса URLComponents

Теперь нам осталось задать в Info.plist файле ключ нашего эндопинта и откуда он будет загружаться.

Единственное что нам осталось, так это получить эти данные в коде. Для этих целей можно создать вспомогательную структуру и получать данные из Bundle нашего приложения.

// // Configuration.swift // ConfigurationTests // // Created by David Grigoryan // import Foundation struct Configuration { static func value(for key: String) -> String? { guard let resultObject = Bundle.main.object(forInfoDictionaryKey: key) else { return nil } if let stringObject = resultObject as? String { return stringObject } return nil } }

Осталось проверить корректность значений которые мы получаем при смене схем. Для начала оставляем ту схему которая используется по умолчанию, а в AppDelegate.swift считываем значение API_URL:

Вывод API_URL для Debug схемы

Попробуем сменить схему на Release для этого выбираем Target и выбираем Edit scheme

Во вкладке Build Configuration выбираем Release

Запускаем проект и проверяем результат

Вывод API_URL для Release схемы

В заключении стоит отметить, что не стоит использовать конфиги для хранения таких чувствительных данных как API ключи или пароли, для этого существуют другие механизмы.

Конфигурационные файлы добавляют больше гибкости в настройке приложений и избавляют нас от необходимости добавлять проверки на переменные окружения с помощью макросов и других механизмов, что делает проект более поддерживаемым.

0
Комментарии
-3 комментариев
Раскрывать всегда