Каков рекомендуемый способ повторного использования служебных функций среди приложений в моих приложениях для iphone на базе Xcode?

Question

У меня есть несколько служебных функций, таких как:

void myVibratePhone() 
{
    AudioServicesPlaySystemSound (kSystemSoundID_Vibrate) ;
}

, который я хотел бы использовать во всех моих проектах.

В C я бы дал каждому проекту файл заголовка и ссылку в файле .OBJ (или, возможно, создал бы библиотеку).

Каков одобренный Apple способ обмена кодом (в первую очередь с какао и С) между моими приложениями? Нужна ли мне для этого основа? Как мне создать его?

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

В настоящее время я не планирую помещать что-либо в App Store, но я не хочу делать что-либо, что приведет к тому, что Apple не примет приложение в любом случае.

Я нашел эту запись о xcode 3.0 (я использую Xcode 3.2.1):

Как мне создать пакет многоразового кода в Xcode?

Я следил за этим, но у меня есть одна проблема:

1) проблема с поиском моего библиотечного файла .h в основном проекте: я пробовал оба жестко кодировать его в основных проектах .h файл

#import "file://localhost/Users/piesia/Documents/My Utilities/MyUtilities.h"

а также:

#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"

и

    #import "~/Documents/My Utilities/MyUtilities.h"

Я также пытался обновить пути поиска в заголовке в настройках Project Build:

"/Users/piesia/Documents/My Utilities/**"

при использовании #import

После долгих попыток (и замены% 20 пробелом) мне удалось получить только варианты

#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"

и

#import "../../My Utilities/MyUtilities.h"

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

Итак, в заключение: 1) это запись, которой я следую, рекомендованный способ создания общего кода в Xcode 2), рекомендуется хранить общие файлы в отдельном репозитории subversion из основной программы и ссылки и включите его, как я делаю сейчас, и 3) знаете ли вы, что я делаю неправильно в моих попытках загрузить файл общего заголовка? Повлияет ли что-нибудь, что я делаю или не делаю с общим кодом, на мои шансы получить одобрение, если я когда-нибудь решу отправить его в App Store?

Answer 1

Я согласен с созданием статической библиотеки для совместного использования кода.

Чтобы добавить заголовки в проект, вам необходимо установить «Путь поиска заголовка пользователя» для расположения файлов .h.

Затем вы импортируете заголовки, используя что-то похожее на:

#import "YourHeader.h"

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

Answer 2

Моя команда имеет десятки компонентов многократного использования в наших продуктах, многие из которых используются совместно для Mac и iPhone. Мой опыт показывает, что в большинстве случаев гораздо проще просто включить исходный код, чем создавать отдельную статическую библиотеку. Отдельный проект для библиотеки добавляет много сложности и редко дает большую ценность. Вот как я обычно к нему подхожу:

В Subversion у нас есть дерево каталогов, подобное этому:

/common
    /Component1
    /Component2
/Project1
/Project2
...

В Project1.xcodeproj мы просто перетаскиваем «Существующие файлы» из общего в дерево (не копировать). Делая это таким образом, вы избавляетесь от лишних затрат при управлении другим проектом. Это означает, что изменения в общем дереве могут нарушить любой из проектов. Это означает, что вам нужно перекомпилировать все перед фиксацией (мы используем скрипт сборки верхнего уровня, чтобы убедиться, что вы ничего не сломали). Преимущество статической библиотеки заключается в том, что вы можете выполнить это путем обновления библиотеки для каждого проекта, когда он будет готов. С другой стороны, это означает, что вам приходится часто проверять библиотеку и управлять ее синхронизацией. Мы обнаружили, что простой обмен кодом, как правило, гораздо эффективнее.

Answer 3

О, этот извращенец! - Я думаю, что, к сожалению, самый простой способ - это жестко закодировать.