Разделение классов между проектами в xcode/objective-c

Ответ 1

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

В целом, основная задача заключается в том, что для каждой цели в вашем проекте xcode, который вы хотите создать, вы указываете, какие файлы следует использовать для ее создания: исходные файлы, искусство, xib и т.д. Таким образом, например, вы можете настроить клиентский продукт, который будет создан с использованием файлов A, B, C, D, E, F и вашего сервера, которые будут созданы с использованием файлов A, F, X, Y, Z.

Мне очень нравится иметь каждый родственный продукт, живущий под одним проектом xcode "крыша", потому что вам не придется прыгать по проектам xcode, и это действительно упрощает управление SCM для общих файлов.

Здесь ссылка на Apple сообщает об этом: https://developer.apple.com/library/mac/#featuredarticles/XcodeConcepts/Concept-Targets.html

Обновление: есть немного лишних хлопот, связанных с настройкой целевых файлов заголовков в xcode (это всегда что-то... правильно?!); например, используйте "myHeaderA.h" для этой цели и "myHeaderB.h" для этой цели. Вот отличная публикация, в которой говорится, как это сделать: управление файлом заголовка проекта Xcode будет. Предостережение: после того, как вы установили этот способ, xcode больше не знает путей для поиска каких-либо целевых файлов заголовков, поэтому вы должны настроить их вручную. Для этого щелкните правой кнопкой мыши Get Info на вашей цели, выберите категорию "Построить", затем добавьте свои пути с помощью "Пути поиска заголовков". Поиск путей осуществляется в том порядке, в котором вы их вводите.

Ответ 2

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

Это имеет большие преимущества по сравнению с другими способами его выполнения:

против. frameworks. Упаковочный код в структуру довольно раздражает, а пакетные частные фреймворки занимают неоправданно долгое время для загрузки - особенно для того, чтобы получить несколько классов в вашем приложении. Wil Shipley из Omni Group (в то время) однажды обнаружил, что фреймворки, включенные компанией во все приложения, добавили несколько секунд к началу каждого приложения. Упаковка частных классов в рамках структуры также может стимулировать большее взаимодействие, чем это строго необходимо - действительно заманчиво просто сделать One True Framework, где все ваши общие классы находятся, поэтому вы начинаете считать, что этот код всегда будет жить вместе. и он становится неотделимым. В принципе, каркасы - это молоток, и эта проблема - это винт.

против. включая файлы. Надеюсь, вы каким-то образом поместите свое приложение в SCM, и просто в том числе файлы на месте создадут проблему, потому что они будут отсутствовать в SCM. Копирование файлов в каждый проект вызывает противоположную проблему: каждый проект будет включать в себя собственную версию файлов, и вам придется вручную распространять любые полезные изменения.

Ответ 3

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

См. Документ Apple о том, что представляет собой Frameworks.

Ответ 4

Самое быстрое решение - добавить только ссылки файлов .h и .m в один из проектов. Просто снимите флажок "copy" -checkbox в "добавить существующие файлы" -dialog в xcode. Имейте в виду, что вам может понадобиться скопировать файлы, на которые вы ссылаетесь, если вы перемещаете/делитесь своим проектом.

Ответ 5

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

Будет хорошо, если два проекта обмениваются данными по протоколу, например. TCP/IP, или если они не обмениваются данными. Если, однако, один проект является пакетом (например, плагином), которому необходимо получить доступ к тем же классам, что и приложение (при запуске в том же процессе), вы получите проблемы со ссылками или предупреждениями/ошибками времени выполнения о том, что классы имеют одинаковое имя. Самый простой способ решить эту проблему - использовать фреймворк. С каркасом вы можете настроить его, чтобы все три цели были в одном проекте, или вы даже можете включить структуру в отдельные проекты.

У меня был проект с приложением и плагином для пакетов, вот шаги, которые я выполнил в Xcode 6:

• Создайте фреймворк, скопируйте весь общий код.
• В главном заголовке фреймворка включаются заголовки всего общего кода.
• Создайте фреймворк для тестирования его сборки (например, выберите схему фреймворка и нажмите кнопку воспроизведения)
• Перейдите в раздел "Фазы сборки" как приложения, так и "Плагин" и добавьте новую структуру в "целевые зависимости" и "Свяжите бинарные файлы с библиотеками".
• Чтобы включить фреймворки в код в приложении и комплекте, просто используйте главный заголовок и используйте < > а не "", например, если ваша инфраструктура была вызвана Foo, используйте #import

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

Ответ 6

Я нашел хорошую статью на эту тему здесь: http://www.clintharris.net/2009/iphone-app-shared-libraries/ Это отвечает на мой вопрос, касающийся всего нескольких кодов приложений для iPhone. Он не упоминает фреймворки (выше), поэтому я не могу сказать, выгодно ли их предложение (ссылки на проект xcode) на решение фреймворка.