Совместное использование быстрого кода в нескольких проектах

Итак, у нас есть несколько проектов с общим кодом, и пока они должны оставаться совместимыми по крайней мере с iOS7.

В настоящее время мы используем локальные кокоаподы для обмена кодом между различными приложениями. Недостатком этого является то, что весь общий код помещается в одну группу. Кроме того, команда Cocoapods объяснила, почему стручки Swift не будут доступны для проектов iOS7:

CocoaPods поддерживает Swift только в OS X 10.9 и новее, а также в iOS 8 и новее.

Вот почему:

Swift поддерживается в OS X 10.9 / iOS 7 и новее, как неоднократно заявляла Apple. В Swift нет поддержки создания статических архивов. Динамические платформы поддерживаются во всех версиях OS X. Динамические платформы не поддерживаются в версиях iOS до 8:

ld: предупреждение: встроенные dylibs/frameworks работают только на iOS 8 или более поздней версии.

(Источник: http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/)

Учитывая эту информацию, мы хотим попробовать поделиться кодом, используя Cocoa Touch Framework-проект.

Я сделал следующее:

  • В рабочей области создайте новый проект -> Cocoa Touch Framework
  • Добавьте/переместите быстрый код сюда и определите необходимые функции/и т. д. как public
  • В основной цели сборки добавьте новый проект как «Встроенная платформа».
  • Если вам нужно использовать классы из определенной библиотеки, используйте оператор импорта, где имя цели сборки является именем модуля (в моем случае import Cobra)

Кажется, это работает, также на iOS7. Что странно, потому что везде в Интернете я читал это предупреждение, чтобы убедиться, что приложение не будет работать на устройствах iOS7:

embedded dylibs/frameworks only run on iOS 8 or later

Однако нам кажется, что на тестовых устройствах с iOS 7 он работает нормально. Кроме того, меня беспокоит:

введите здесь описание изображения

Путь фреймворка кажется прямой ссылкой на мою локальную папку DerivedData. Я специально не выбирал свою папку DerivedData, я просто добавил предложенный фреймворк из Xcode, и он сам решил взять его из моей папки DerivedData. Мы работаем над этим проектом с несколькими программистами.

TL;DR;

Прежде чем я пойду по этому пути и перенесу код в эту новую настройку:

  • Не вызовет ли этот способ встраивания общей библиотеки проблемы для моей команды? (другими словами: я делаю что-то не так?)
  • Не вызовет ли такой способ встраивания библиотек проблем при отправке приложения в App Store?
  • Если необходимо: есть ли альтернатива способу обмена кодом между проектами без простого копирования кода/файлов туда и обратно? Я не могу поверить, что ни у кого больше нет этой проблемы.

person Kevin R    schedule 24.02.2015    source источник
comment
Я рекомендую вам использовать GIT напрямую, избегая дополнительных головных болей, которые в любом случае доставит вам cocoapod; вам не нужно беспокоиться о том, какая версия Xcode, OSX или iOS будет поддерживаться — она правильно поддерживает все, что вам нужно, а процедура ее настройки и использования намного проще, чем тратить время на cocoapods , на мой взгляд, это не совсем для профессионалов, а для занудных выродков. (Я не хочу затевать дискуссию, спасибо, как я сказал на мой взгляд!)   -  person holex    schedule 02.03.2015
comment
У Cocoapods есть то преимущество, что он исправит конфигурацию вашего проекта, чтобы добавить новые источники для вас. При работе с чем-то вроде подмодуля GIT вам придется управлять такими вещами вручную. Лично я думаю, что желание управлять такими тривиальными вещами вручную кажется более сложной задачей;).   -  person Kevin R    schedule 02.03.2015


Ответы (2)


Обновление от 03.02.2015:

Чтобы поделиться кодом внутри, я рекомендую использовать подмодули git, которые требуют, чтобы вы зафиксировали свой код в размещенном репозитории, который может быть как общедоступным, так и частным.


Подмодули Git

Это способ распространения кода, хранящегося в репозитории, всем, у кого есть доступ. Его преимущество заключается в том, что вы можете отправлять изменения в репозиторий, которые другие потребители могут затем выбрать для обновления своих собственных репозиториев подмодулей. Для этого требуется, чтобы Git использовался в качестве системы управления версиями проекта, а также требуется, чтобы код помещался в репозиторий, к которому у потребителей есть доступ.

Чтобы использовать код в качестве подмодуля git, вы добавляете репозиторий кода в свой проект, контролируемый git, с помощью команды:

git submodule add https://github.com/user/submoduleProject

заменив https://github.com/user/submoduleProject URL-адресом собственного репозитория.

После того, как это было добавлено, вы можете использовать команды:

git submodule init

а также

git submodule update

чтобы вытащить код из репозитория в рабочую область пользователей.

Если вы хотите добавить какие-либо изменения или обновления в подмодуль, вы можете сделать это и отправить его в репозиторий. Затем пользователи могут обновить свой код с помощью git submodule update, чтобы получить последние изменения.

Дополнительную информацию о подмодулях git можно найти в официальной документации.

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


Приложение не будет принято загрузчиком приложений или Xcode при отправке в App Store, если динамическая структура используется в приложении, которое поддерживает что-либо меньшее, чем iOS 8. Это прискорбно, потому что, как вы сказали, это работает для iOS 7, когда тестирование на устройстве.

Лучший способ, который я могу придумать для вас, чтобы поделиться своим кодом с вашей командой, — это передать папку с кодом и включить ее в проект, а не включать динамическую структуру. Если вы хотите сохранить постоянный интервал между именами, чтобы в будущем вы могли использовать динамическую структуру и перейти от iOS 7, я рекомендую использовать структуру вокруг общедоступных методов и классов для получения пространства имен. Например:

public struct MyFrameworkName {
    public func doSomethingAmazing() {
         // Code...
    }

    public class DecentClass: NSObject {
         // Code..
    }

    public var terribleString: String
}

Это позволит вам вызывать методы внутри остальной части приложения так же, как с Dynamic Framework.

var myObject = MyFrameworkName.DecentClass()
myObject.doMethod()

MyFrameworkName.doSomethingAwesome()

MyFrameworkName.terribleString = "HEY";

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

В идеале вы должны скопировать фреймворк в каталог проекта, а затем связать его с этой версией. Это позволяет вам распространять исходный каталог проекта среди других людей, а фреймворк останется в правильном месте относительно исходной папки проекта.

Я надеюсь, что это поможет ответить на ваш вопрос.

person Elliott Minns    schedule 27.02.2015
comment
Отчасти это помогает, но моя самая большая проблема остается: обмен кодом. Я должен сказать, что простое копирование и вставка кода не может считаться жизнеспособным решением. Все задействованные проекты развиваются довольно быстро, так что это может стать кошмаром. Должен ли быть какой-то способ делиться кодом над проектами, не убивая поддержку Swift или убивая поддержку iOS 7? - person Kevin R; 02.03.2015
comment
Вы правы, копировать и вставлять - не лучшее решение. Я бы рекомендовал использовать либо частный репозиторий Cocopods, либо подмодули git. Я обновлю свой ответ, чтобы отразить это. - person Elliott Minns; 02.03.2015
comment
эти варианты были вроде того, на что я надеялся. Однако Cocopods не поддерживает (не может?) Swift под iOS7, поскольку они также используют динамические фреймворки? И если вы просто добавляете файлы с помощью подмодулей git, как будут обнаружены новые файлы для добавления в «Источник компиляции»? Или это будет означать добавление новых файлов вручную? - person Kevin R; 02.03.2015
comment
Правильно. В данном случае Cocoapods не подходит для Swift, поэтому я рекомендую подмодули git. Что касается того, как вы хотите обнаруживать новые файлы и т. Д., Вы можете создать скрипт, который автоматически добавляет их в исходные файлы компиляции. Я лично не пробовал этот подход, поэтому я не могу комментировать его. Наиболее надежным, но, к сожалению, несколько обременительным подходом было бы автоматическое добавление файлов в исходные коды компиляции для цели. Я понимаю, что это может показаться неприятным, но, к сожалению, поддержка iOS 7 действительно ограничивает доступные варианты. - person Elliott Minns; 02.03.2015

подмодули git будут работать. С ними может быть больно работать.

Если вы не хотите их использовать, я придумал обходной путь, в котором используется второй «фиктивный» проект с Cocoapods для извлечения кода Swift без использования Framework.

https://medium.com/@mishagray/how-to-use-swift-cocoapods-and-still-support-ios-7-0-f9dc29b3628b

person Michael Gray    schedule 25.04.2015
comment
Ваш пример репозитория git в основном пуст. - person vikingosegundo; 26.04.2015
comment
Извини за это. Репозиторий теперь актуален! - person Michael Gray; 27.04.2015