Вопрос по configuration, ios, xcode, iphone – Как настроить независимые наборы параметров времени выполнения в XCode

57

Моё приложение для iPhone подключается к трем различным серверам, скажем: Производство, Постановка а также Тестирование. Существует множество значений конфигурации, которые приложение использует в зависимости от того, к какому серверу оно подключается, например, Идентификатор приложения Facebook, ключ команды TestFlight и т. Д.

Я хотел бы иметь все настройки в GIT и выбирать только ту конфигурацию, которую приложение должно использовать при компиляции или выпуске. Например, когда Тестирование выбрано,Product -> Run в XCode запускает отладочную версию приложения, подключающегося к Тестирование, а такжеProduct -> Архив создает файл IPA с версией выпуска, которая также подключается к Тестирование.

Я не хочу создавать больше конфигураций сборки, чем отладки и выпуска (потому что это будет означать 6 различных комбинаций конфигураций сборки / конфигураций во время выполнения). На мой взгляд, идеальным решением было бы то, что у меня есть три схемы: Производство, Тестирование а также Постановка, и каждая схема выбирает один из трех файлов Info.plist для использования с приложением. Это позволило бы мне не только определять различные параметры времени выполнения, но также разные версии приложений или идентификаторы пакетов в зависимости от внутреннего сервера. Но, похоже, я не могу настроить действие «Архив» другим способом, кроме выбора другой конфигурации сборки. Любые идеи, если это может быть достигнуто каким-либо образом?

Редактировать Чтобы было немного яснее, Производство / постановка / тестирование является внутренним сервером, а не версией приложения iOS. Приложение для iOS выпускается в двух версиях: Отладки / релиз. Другими словами, я могу захотеть запустить @ Отлад версия приложения, подключающегося к Производство server, например, для отладки сбоя, вызванного возвращением JSON с этого сервера. Для ясности я мог бы назвать серверы A, B и

Здравствуйте @Amiramix, я знаю, что этот вопрос задан давно, но я был бы признателен, если бы вы могли мне помочь. У меня такая же проблема. Мне нужна другая среда сборки. И он должен иметь другой идентификатор пакета, чтобы иметь отдельное приложение для каждой среды. Я просто хочу изменить какой-то URL для каждой среды. Как вы решили свою проблему? Hamid
Извините, я не смогу вам помочь, так как некоторое время не использовал более новую версию XCode. Из того, что я вспомнил, я не решил эту конкретную проблему, я просто создал несколько разных приложений, использующих один и тот же код, но с разной конфигурацией, соединяющихся с разными внутренними серверами. Amiramix

Ваш Ответ

4   ответа
10

ешно использовал эту модель раньше. В настройках вашего проекта вы можете продублировать текущую цель и изменить настройки сборки по мере необходимости. Там естьInfo.plist File свойство, которое позволит вам изменить список по умолчанию для этой цели.

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

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

Единственным недостатком этого является то, что у вас есть больше работы, когда вы хотите обновить профили обеспечения.

Targets - лучшая идея для разделения тестовых сборок, потому что вы можете иметь разные AppID и, таким образом, позволить им работать вместе с производственными сборками. Kendall Helmstetter Gelner
Если вы параметризуетеCFBundleIdentifier тыможе одновременно устанавливайте разные конфигурации вашего приложения на устройстве. Фактически, @ mike-weller показал именно это в своем ответе. Вы можете иметь разные отображаемые имена. С более новым Xcode, использующим каталог активов, вы можете иметь другой значок приложения. Все, что вы могли бы сделать с помощью нескольких целей, теперь вы можете делать с одной целью и сохранять ее более СУХО toolbear
Targets действительно следует использовать только для отдельных продуктов. Если вы создаете один и тот же концептуальный продукт с разными конфигурациями или настройками, использование целей на самом деле не лучшее решение. Mike Weller
@ MikeWeller Прошу отличаться. Как я уже сказал, я использовал эту технику раньше без каких-либо проблем. И вы, очевидно, не упомянули ни минусов, ни реальной альтернативы. Какой смысл вашего комментария? adig
Проверьте этот замечательный урок о том, как делать то, о чем говорит @adig. Appcoda.com / с использованием Xcode-целевых задач Atticus
2

если соответствующие библиотеки позволяют устанавливать ключи в коде, а это означает, что вы можете иметь производственное значение в своем файле plist, но изменить их в своем AppDelegate (или в любом другом файле, в котором они впервые используются).

Работает с Facebook, Twitter и Google SDK на данный момент.

Ex:

#ifdef DEBUG
  // Facebook
  [FBSettings setDefaultAppID:@"SandboxID"];
  // Fabric / TwitterKit - must be called above [Fabric with:@[TwitterKit]];
  [[Twitter sharedInstance] startWithConsumerKey:@"SandboxKey" consumerSecret:@"SandboxIDSecret"];
#endif

То же самое в Swift, просто используйте #if вместо # ifdef.

Заметка о фейсбуке Это работало с версией 3 их SDK, я не уверен, что это возможно с более поздними версиями.

Этот ответ неверен, потому что вам нужно добавить схему URL для входа в систему и перенаправления SDK Facebook, и вы можете добавить ее только через файл info.plist. Для этого это не может быть сделано, бросил libs. 6rod9
@ 6rod9 Вы пробовали это? Смотритедокументаци: defaultAppId "будет считан из списка приложений, если явно не установлено". Я предполагаю, что он также устанавливает схему URL, добавляя перед ней «fb», если вы установите ее вручную. Nycen
112

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

Сначала вы хотите настроить конфигурацию на уровне проекта:

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

Далее вы можете определить несколько макросов для каждой конфигурации, которые будут переданы компилятору. Затем вы можете проверить эти флаги во время компиляции. Найдите параметр сборки «Флаги препроцессора» на целевом уровне:

Если вы расширяете треугольник, вы можете определить различные значения для каждой из ваших конфигураций. Вы можете определитьKEY=VALUE или простоKEY здесь макросы.

В своем коде вы можете проверить наличие этих макросов или их значение (если оно есть). Например

#ifdef DISABLE_FEATURE_X
    featureXButton.hidden = YES;
#endif

// ...

#if FOOBAR_VISIBLE == 0
    foobarView.hidden = YES;
#elif FOOBAR_VISIBLE == 1
    foorbarView.hidden = NO;
#else
    #error Invalid value for FOOBAR_VISIBLE
#endif

Вы также можете передавать строковые значения, которые должны быть заключены в одинарные кавычки в настройке сборки, например,DEFAULT_LOCALIZATION_NAME='@"en"'.

Вы также можете настроить, какая конфигурация используется во время отладки и архивирования, используя редактор схем. Если вы выбираете «Выполнить» или «Архивировать» в редакторе схем, вы можете выбрать соответствующую конфигурацию.

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

А затем укажите соответствующее значение для ваших различных конфигураций:

Затем в файле Info.plist вы можете указать этот параметр:

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

Settings.bundle

Кроме того, в более старых версиях XCode без поддержки каталога ресурсов вы не можете изменять следующие элементы:

Icon.png Default.png

Это нельзя явно определить в файле Info.plist или где-либо еще, что означает, что для их изменения нужны разные цели.

Надеюсь это поможет

онфигурации @Build были разработаны с учетом именно этого варианта использования. У вас есть разные конфигурации вашего приложения, и вы можете изменить конкретные настройки для определенных конфигураций. Я не понимаю, как еще вы хотите достичь этого. А добавить несколько целей гораздо сложнее. В итоге вы получите дублированные настройки конфигурации и значения Info.plist. Шесть примеров, которые вы привели, также запутаны. «Производственная отладка» немного противоречи Mike Weller
Production Debug - отладочная версия приложения, подключенного к производственному серверу. Конфигурации сборки должны использоваться для создания отдельных настроек сборки, например, Отладка против выпуска. Не создавать функционально одно и то же приложение, подключенное к разным внутренним серверам. Создание отдельных целей имеет больше смысла, например, приложение, подключающееся к производству в качестве другой цели, чем приложение, подключающееся к промежуточному этапу, возможно, с другим идентификатором и версией пакета (чтобы отличать эти приложения). Amiramix
Это не очень хорошее решение, потому что, как я уже сказал, мне нужно создать 6 различных конфигураций сборки: производственная отладка, производственная версия, промежуточная отладка, промежуточная версия, тестовая отладка, тестовая версия. Тогда поддержание всех параметров конфигурации сборки становится кошмаром. Я также не покупаю ваш аргумент, что добавление новых целей неправильно. В этом случае вы предлагаете создать новые конфигурации сборки, чтобы выбрать соответствующие параметры времени выполнения. Конфигурации сборки предназначены для фазы сборки, а не для фазы выполнения. Почему это должно быть лучшее решение? Amiramix
Можно ли это сделать в Swift? Нет такой вещи, как Apple LLVM Compiler> Макросы препроцессора в Targets, только на уровне Project Christopher Francisco
Вы всегда мог менятьCFBundleIdentifier а такжеCFBundleDisplayName для конфигурации, использующей этот подход. Теперь, с помощью каталогов ресурсов, вы можете изменить значок приложения и загрузить изображение для каждой конфигурации. Больше нет причин использовать отдельные цели. Ограничение ОП на наличиеDebug а такжеRelease является произвольным и не позволяет использовать лучшее решение для решения проблемы. Избегание дополнительных конфигураций просто перемещает сложность куда-то еще; место, где вы должны дублировать настройки и повторять себя гораздо чаще, чем то, что предлагает @ mike-weller. toolbear
0

apiURL(), который возвращает URL API, который я хочу. У меня есть localhost, stage и production, и я просто раскомментирую тот, который хочу. До сих пор это работало хорошо для меня. Я только забыл переключить его обратно несколько раз. К сожалению.

Похожие вопросы