Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Xcode: руководим зависимостями собственных библиотек в планах. Cocoapods advanced

Anna | 2.07.2014 | нет комментариев

Cocoapods – это администратор зависимостей библиотек в Xcode планах. Я не буду рассказывать, как с его поддержкой подключить в план теснее существующую библиотеку, информации довольно, в том числе и эта статья на Прогре. Я расскажу что делать, если вы не обнаружили необходимую вам библиотеку в списке, либо, что ещё дрянней, вы хотите сделать свою библиотеку и, как вариант, не делать её доступной.

Часть I: подключаем библиотеки через podfile

Для начала стоит посмотреть, какие вероятности даёт нам Cocoapods, для подключения библиотеки в план (через podfile):

  1. Подключить библиотеку из списка поддерживаемых:
    pod 'Reachability'
    pod 'AFNetworking/Reachability'
    pod 'JSONKit',       '~> 1.4'
    

    Самый примитивный метод (он же стержневой), при этом дозволено указать привязку к определенной версии и подключить не всю библиотеку, а только её часть (через subspec)

  2. Подключить библиотеку, но при этом указать путь к спецификации
    pod 'ZipKit', :podspec => 'ZipKit.podspec'
    

    Дозволено применять тогда, когда присутствующая Cocoapods спецификация вас каким-то образом не устраивает (скажем, в спецификации к библиотеке стоит iOS 6.1, а у вас в плане Deployment target выставлен в 6.0). Сберегаем себе спецификацию, редактируем её под свои нужды, сберегаем в корень плана – в итоге у вас всё работает, и при этом нет необходимости добавлять допустимо пагубные метаморфозы в публичную спецификацию.

  3. Подключить библиотеку по локальному пути (совместно со спецификацией):
    pod 'SuperLibrary', :path => 'Submodules/SuperLibrary'
    

    Данный вариант теснее увлекательнее, так как дозволено указать путь к совместному коду (subversion external, git submodule…). При таком методе файлы библиотеки включаются в план со ссылками на данный путь, что разрешает нам редактировать библиотеку и сберегать измения в системе контроля версий. Больше детально вернёмся к этому позднее

  4. Подключить библиотеку (совместно со спецификацией), расположенную в системе контроля версий, либо легко по ссылке на архив:
    pod 'SuperLibrary', :git => 'git@bitbucket.org:bestcompany/SuperLibrary.git', :branch => 'development'
    

    Основное различие от предыдущего пункта в том, что редактировать начальный код библиотеки теснее невозможно (технически дозволено, впрочем при установке зависимостей в план будут легко добавлены копии файлов, которые никак не будут ссылаться на оригинал и будут переписаны на подлинные файлы при дальнейшем обновлении зависимостей)

Часть II: пишем спецификацию к собственной библиотеке – «как 2 байта переслать»

Сделать спецификацию легко:

pod spec create SuperLibrary

Открываем сгенерированный файл, заполняем сгенерированные разделы, читая комментарии, при затруднениях обращаемся к документации.
И тут стоит припомнить про такой механизм, как модули библиотеки (subspec). В кратце, разбиваем нашу библиотеку на некоторые логические модули (в том числе связанные между собой), описываем источники, начальные коды, зависимости по-отдельности, скажем:

s.subspec 'Data' do |ds|
    ds.source_files = 'Data/*.{h,m}', 'Data/Categories/*.{h,m}', 'Data/Objects/*.{h,m}'
    ds.resources = 'Data/SuperLibrary.xcdatamodeld'
    ds.dependency 'MagicalRecord'
    ds.dependency 'SuperLibrary/Resources'
  end

Доступ к модулю осуществляется через MasterSpec/Subspec, одни модули внутри могут зависеть от других внутри одной спецификации, допускается многоуровневая вложенность. Осталось указать модуль, тот, что будет подключен по умолчанию, скажем

s.default_subspec = 'Controllers'

И всё, библиотеку дозволено подключать по частям, скажем только сетевое ядро, не затрагивая источники и Unit-тесты.
Несколько советов:
Схема базы данных (*.xcdatamodeld и иже с ними) это источник а не начальный код, с недавней версии cocoapods подключается типично, в том числе совместно с версиями схемы.
Зависимости своей библиотеки от других желанно прописывать без привязки к конкректной версии (за исключением, скажем, Facebook-iOS-SDK, API которой меняется слишком Зачастую).

Часть III: свой репозиторий спецификаций «с шахматами и поэтессами»

Библиотеки подключать знаем как, создавать спецификацию умеем, идея версий библиотек нам нравится, но делиться библиотеками не будем. Крайне частая обстановка в маленьких и крупных компаниях, есть много планов, на них применяется объединенный код, отлично бы их оформить как библиотеки и трудиться с версиями так же легко, как и с обыкновенными cocoapods библиотеками. И здесь на поддержка приходит приватные репозитории. Что нам для этого понадобится:

  1. Создаём новейший репозиторий для спецификаций, тот, что будет доступен вашей команде. Плохая новость, для репозитория спецификаций поддерживается только git. (Отличная новость, на git должен быть только репозиторий спецификаций, сами библиотеки по-бывшему будут доступны по git/svn либо даже по традиционной ссылке на архив). Добавляем его в cocoapods легкой командой из консоли:
    pod repo add Private-Cocoapods git@bitbucket.org:bestcompany/cocoapods-specs.git
    

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

    Всё, осталось отправить эти метаморфозы на репозиторий и дальнейшие команды pod install (либо pod update) будут трудиться с нашей библиотекой так же, как и с официальной, то есть подключать pod дозволено будет легко по имени библиотеки.

Часть IV: Подключаем всё совместно, либо как можо возвести процесс разработки

И один из сценариев, как с этим дозволено удачно трудиться. Предпосылка: ведётся разработка нескольких продуктов (единовременно либо нет, не значимо), в приложениях есть коллективно применяемый код (библиотеки), разработка всякой библиотеки ведётся в собственной ветке репозитория.
Выходит, нам нужно, Дабы в корне всякой библиотеки лежал востребованный podspec файл, версия в podspec файле идёт с постфиксом dev, параметр source ссылается на нынешнюю ветку, скажем:

Pod::Spec.new do |s|
  s.name         = "SuperLibrary"
  s.version      = "1.0.5-dev"
  s.source       = { :git => "ssh://git@bitbucket.org:bestcompany/my-super-library.git"}

Таким образом, при подключении этой версии непринужденно из репозитория, мы будем иметь пометку dev, говорящую о том, что версия не готова. Позже тестирования данный библиотеки создаём tag с именем версии (проверить версию, и, если нужно, поднять минорную/мажорную версию), копируем podspec файл в наш личный репозиторий спецификаций, убирая приставку dev из версии и указав определенный таг в репозитории, тот, что мы только что сотворили:

Pod::Spec.new do |s|
  s.name         = "SuperLibrary"
  s.version      = "1.1.0"
  s.source       = { :git => "ssh://git@bitbucket.org:bestcompany/my-super-library.git", :tag => "SuperLibrary_v1.1.0" }

Всё, осталось в репозитории библиотеки выставить версию на один огромнее не убирая постфикс dev (1.1.1-dev в нашем случае) и отправить все метаморфозы в репозиторий.
Разработка, обыкновенно, это процесс безмерный, и надобность править библиотеки появляется дюже Зачастую. Для таких случаев дозволено неизменно беречь ссылку на нынешнюю версию библиотеки в репозитории через сабмодуль в Git (external в Subversion). При этом в podfile определенного продукта неизменно указана стабильная версия (podspec хранится на нашем репозитории спецификаций), но рядом закоментированная строчка на нынешнюю версию:

	#pod 'SuperLibrary', :path => 'Submodules/SuperLibrary'
	pod 'SuperLibrary'

В случае необходимости внести метаморфозы в библиотеку, убираем комментарий со строчки, обновляем библиотеку до последней версии в репозитории, делаем pod update в консоли и всё, дозволено отважно изменять и тестировать. Перед подготовкой приложения в публикацию стоит зафиксировать все версии библиотек (то есть сделать новые версии для всех изменённых библиотек и подключить их из нашего репозитория спецификаций). Неизменно проверяйте podfile.lock на то, какие версии библиотек применяются, наш постфикс -dev дюже помогает определить, что версия библиотеки может быть не протестирована.
И да, делать pod update как часть процесса сборки приложения очевидно не стоит (по-крайней мере на стадии подготовки версии к релизу, так как из-за обновления библиотеки непременно что-то перестанет трудиться в конечный момент).

P.S. Cocoapods обновляется непрерывно, исправляются ошибки, добавляются новые вероятности (и новые ошибки). Если у вас что-то перестало трудиться (а такое случается), не поленитесь, пожалуйста, обнаружить причину, и, если дело именно в cocoapods, дайте знать разработчикам.

 

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB