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

Question

У меня есть клиент < => серверное приложение Я создаю для Mac OS X, используя Objective-c/Cocoa и xCode. Я создал другой проект для обоих приложений, которые у меня есть, и мне интересно, как лучше разделить классы между ними. Есть несколько классов, которые я сделал, что было бы полезно для обоих. Пока я копировал их, но я чувствую, что это не лучшее решение.

Как эффективно делить классы? Должен ли я повторить его как 1 проект и просто иметь две цели сборки? Как мне это сделать?

Любые другие вопросы?

Спасибо.

Answer 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

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

Answer 2

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

См. Apple's doc on what are Frameworks.

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

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