Совместное использование классов между проектами в xcode / target-c - PullRequest
29 голосов
/ 24 января 2010

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

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

Любая другая информация?

Спасибо.

Ответы [ 6 ]

13 голосов
/ 19 июля 2010

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

Вкратце, основная сделка заключается в том, что для каждой цели в вашем проекте xcode, которую вы хотите построить, вы указываете, какие файлы должны использоваться для его создания: исходные файлы, art, xibs и так далее. Таким образом, например, вы можете настроить свой клиентский продукт на сборку с использованием файлов 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 больше не будет знать пути для поиска любого из ваших целевых заголовочных файлов, поэтому вы должны настроить их вручную. Для этого щелкните правой кнопкой мыши пункт Получить информацию о своей цели, выберите категорию «Построение», затем добавьте свои пути с помощью параметра «Пути поиска по заголовку». Пути ищутся в том порядке, в котором вы их вводите.

12 голосов
/ 17 мая 2010

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

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

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

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

4 голосов
/ 24 января 2010

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

См. Документ Apple о том, что такое Frameworks .

2 голосов
/ 01 августа 2014

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

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

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

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

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

2 голосов
/ 24 января 2010

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

1 голос
/ 17 мая 2010

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

...