Один кончик, разные активы. Связки?

Question

У меня есть приложение для iPhone с различными вариантами оформления, с различными художественными активами и звуками, но с одним и тем же кодом.

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

Это немного расстраивает, потому что, если я внесу изменения в один файл пера, мне придется вручную внести те же самые изменения, те же соединения и т. Д. Во все другие файлы пера. Я также поместил все ресурсы с разными именами для разных скинов, чтобы они не сталкивались в проекте. Итак, если у меня есть цели A и B, у меня есть a_main_menu.png, b_main_menu.png ... a_FooViewController.xib, b_FooViewController.xib ... и т. Д.

Есть ли способ создать nib-файл, который указывает на ресурсы, которые имеют одинаковые имена, но в разных пакетах? это для чего комплект? Я могу себе представить исправление чего-то подобного в моем коде (возможно, поиск и замена A для B в nib перед загрузкой, это может быть даже достаточно хорошо), хотя я не пробовал, это ужасно.

Это была управляемая стратегия для моего первого набора приложений (хотя и далеко не оптимальная), но по мере того, как мои материалы усложняются, становится действительно сложно поддерживать синхронизацию файлов моего компоновщика, и это просто не СУХОЙ способ Работа. Есть ли лучший способ, кроме как бросить uibuilder и создавать мои представления в коде?

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

Лучше всего было бы, если бы я мог смешать две стратегии - например, если бы у меня была одна цель, у которой есть одно представление из нескольких, которое просто ДОЛЖНО быть изложено по-разному ... но это не обязательно.

Я задаю правильный вопрос?

Спасибо!

Answer 1

Один из способов сделать это состоит в том, чтобы переместить все ваши иллюстрации в отдельный пакет и динамически загрузить их во время выполнения (что-то вроде «медиа-плагина»).

• Создайте отдельный проект и выберите «Mac OS X / Framework & Library / Bundle». Назовите это, скажем, media.bundle.

• Переместите все свои работы в этот проект.

• Чтобы упростить жизнь, добавьте дополнительный шаг «Выполнить сценарий» к цели, скопировав встроенный вывод из каталога сборки в подпапку вашего основного проекта. Чтобы сделать это еще проще, добавьте мультимедийный комплект в качестве зависимого проекта в основной проект, чтобы он автоматически перестраивался.

В вашем основном проекте вам понадобятся эти два метода. Вы можете сделать их статическими методами в классе BundleUtils:

+ (NSString *) bundleDirectoryFor:(NSString *) bundleName
{
 NSString* basePath = [[[NSBundle mainBundle] resourcePath]
     stringByAppendingPathComponent:[NSString
                                stringWithFormat:@"%@.bundle", bundleName]];
 return [[NSBundle bundleWithPath:basePath] resourcePath];
}

+ (NSString *) resourceInBundle:(NSString *)bundleName 
                       fileName:(NSString *)fileName
{
 NSString *bundlePath = [BundleUtils bundleDirectoryFor:bundleName];
 return [bundlePath stringByAppendingPathComponent:fileName];
}

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

NSString* imageFile = [BundleUtils resourceInBundle:@"media.bundle" 
                                        fileName:@"image.jpg"];
UIImage* image = [UIImage imageNamed:imageFile];

Очевидно, что имя «media.bundle» можно заменить во время выполнения на другое, чтобы вы могли переключаться на другие пакеты в зависимости от потребностей вашего приложения. Это также удобный способ поддержки загружаемого контента (например, платных дополнений).

Одно предупреждение: предполагается, что вам необходимо динамически загружать изображения во время выполнения с помощью кода. Но у вас также есть статические файлы NIB, в которые встроен носитель. Вам нужно будет найти способ заставить статический файл NIB использовать динамические методы для разрешения имен файлов мультимедиа. Один из способов - использовать MethodSwizzling и отслеживать пути к файлам с префиксом типа, скажем, «media: image.png», и перенаправлять их для использования методов BundleUtil.

Другой способ - создать макет с IB, затем преобразовать его в код Obj-C, используя nib2objc , а затем заменить механизм связывания плагинов.

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

Answer 2

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

Git делает это очень просто.

Answer 3

Это работает для меня:

1 проект. 2 цели а, б. 2 папки с изображениями для a, b.

controller.m и его nib-файл предназначены для обеих целей.

Создание отдельных папок файловой системы для изображений целевых объектов a и b.

Импортируйте одну папку с изображениями для цели a («добавить файлы в xy» -> «добавить к цели a / b»), другую - для цели b. Убедитесь, что вы используете опцию «создать группы для добавленных папок». Не выбирайте параметр «ссылки на папки».

Когда я собираю цель a, я получаю приложение с изображениями из папки a; когда я строю для b, он использует папку b для фото.

Answer 4

Я думаю, что именно для этого предназначен viewDidLoad, чтобы настроить больше, здесь вы можете изменить путь к изображениям.

Answer 5

Я думаю, что лучший вариант - использовать что-то вроде git.

Если вы использовали git, вы можете иметь основную ветвь, которая содержит основной исходный код и логику, и иметь подветви, которые имеют разные наборы данных / изображений для каждого конкретного варианта вашего приложения. В этом решении XCode даже не узнает, что происходит.