CocoaPods теперь является отраслевым стандартом для управления сторонними фреймворками и зависимостями для iOS. Существует такое требование, чтобы библиотеки работали с CocoaPods, что даже в самом начале я получил 5 запросов на добавление Podfile и тега еще до того, как узнал, что такое CocoaPods! В настоящее время мне это нравится, и я бы даже не подумал начать проект без него!
Давайте кратко рассмотрим, как работает CocoaPods.
Единовременная установка
CocoaPods фактически реализован как гем Ruby, поэтому, если у вас уже установлен Ruby, установите гем с помощью:
gem install cocoapods
Если вы не знакомы с Ruby, вам может потребоваться доступ sudo, чтобы эта команда работала.
Настройка вашего проекта
Настройка CocoaPods для вашего проекта не намного сложнее. Во-первых, убедитесь, что вы создали свой проект XCode, если вы еще этого не сделали. (Я подожду.) Отлично! Теперь вам нужно создать исходный Podfile. В верхней части иерархии проекта, в том же каталоге, что и файл .xcodeproj вашего проекта , запустите:
pod init
Это создает Podfile для вас. Теперь откройте его и добавьте следующее:
pod 'RaptureXML'
Затем установите CocoaPods и фреймворк и вашу новую зависимость с помощью:
pod install
Волшебство будет сделано! Теперь взгляните на содержимое вашего каталога. CocoaPods создал дополнительный файл .xcworkspace, который вы должны использовать для открытия своего проекта. Когда вы это сделаете, вы обнаружите, что ваш проект теперь совместно использует рабочее пространство с CocoaPods, и все ваши зависимости управляются для вас!
Выбор и спецификация стручка
Если вы указали Podfile, как указано выше, в вашем проекте будет самая последняя версия RaptureXML. Очень легко добавлять другие библиотеки и даже более точно определить, какую версию вы хотите. Допустим, вы хотите добавить AFNetworking в свой проект … что вы делаете? Я всегда начинаю с поиска:
pod search AFNetworking
Появляется несколько пунктов, но сразу видно, что это то, что вы ищете:
-> AFNetworking (2.0.0) A delightful iOS and OS X networking framework. pod 'AFNetworking', '~> 2.0.0' ...
Более того, третья строка — это CocoaPods, которая говорит вам, что именно вам нужно добавить в ваш Podfile для установки AFNetworking! Но что это за синтаксис? Это немного странно, поэтому вот несколько примеров, чтобы дать вам идею:
pod 'AFNetworking', '~> 2.0.0' <-- Installs latest version up to, but not including, 2.1 pod 'AFNetworking', '~> 2.0' <-- Installs latest version up to, but not including, 2.9 pod 'RaptureXML', '1.0.1' <-- Installs version 1.0.1 pod 'iRate' <-- Installs most recent version
Есть и другие варианты с точки зрения управления версиями, но я не нахожу ничего более полезного. Большую часть времени я просто беру последнюю версию. Существует некоторый риск в случае, если в зависимость введена ошибка, поэтому, если для тестирования важно, чтобы все оставалось без изменений, вы можете заблокировать версии в версии ветки вашего подфайла. Тем не менее, используйте последние версии в своей основной ветке, потому что вы не хотите зависеть от старой версии чего-либо.
Местные стручки
Это моя любимая особенность CocoaPods. Ранее мы устанавливали модули из центрального репозитория CocoaPods, но требования к ним не предъявляются. В качестве альтернативы мы можем загрузить наши модули напрямую из любого Git-репозитория:
pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git'
И, мой любимый, вы можете указывать путь прямо на своей машине!
pod 'AFNetworking', :path => '~/Rapture/Tilikum'
Это просто замечательно, потому что в обоих вышеперечисленных случаях вы можете управлять своими собственными модулями в частном порядке, не открывая их центральному хранилищу, предоставляющему доступ любому. Это замечательно, когда у вас или у вашей компании есть внутренние библиотеки, которыми вы хотите управлять с помощью CocoaPods, но не хотите, чтобы кто-то другой использовал. Я использую это бесконечно, чтобы захватить повторно используемый код, который я часто использую во многих моих собственных проектах.
Создание стручка
Итак, как стручки знают, как настроить себя для вашего приложения? Это займет немного больше работы, но это не так уж плохо. Во-первых, вам, вероятно, потребуется немного переконфигурировать иерархию папок вашей библиотеки или фреймворка. Вот пара советов:
- Централизуйте повторно используемый код в вашей библиотеке в рамках одной иерархии каталогов (т.е. Classes / или Tilikum /).
- Отдельные делегаты приложения, Info.plist и любые другие файлы, которые не должны быть включены в хост-приложение. (Так что они не под классами /)
Теперь в вашей библиотеке создайте свой подспек на верхнем уровне вашего проекта. Давайте представим, что мы создаем библиотеку масок аватаров. Мы бегаем:
cd ~/Projects/AvatarMasker pod spec create AvatarMasker
Это создаст AvatarMasker.podspec в этом каталоге. В этом файле много комментариев, которые помогут вам настроить его . Мой лучший совет — просматривать реальные спецификации podspecs, чтобы увидеть, что они делают. Вот podspecs для RaptureXML , разгневанный и ZipZap .
Одна вещь, которую вы можете заметить во время просмотра, заключается в том, что некоторые проекты не имеют подспецификаций, но доступны для поиска в CocoaPods. Это потому, что не требуется , чтобы подспек был в самом хранилище. В этих случаях podspec находится только в центральном хранилище CocoaPods. Это, например, случай для InnerBand . Если вы хотите добавить свою библиотеку в центральный репозиторий , вам просто нужно загрузить свой podspec в другое место.
Также обратите внимание, что если в проекте нет собственной спецификации podspec, вы не можете загрузить его напрямую, как мы это делали выше. Вы должны загрузить его из центрального хранилища.
Вывод
CocoaPods — явно лучший вариант по сравнению с добавлением каждой зависимости в ваш проект вручную. Кажется, что каждая библиотека предъявляет уникальные требования к ее интеграции, и вы часто будете включать в нее больше, чем нужно, когда вы делаете это таким образом. Вы видели, что можете интегрировать такую большую библиотеку, как AFNetworking, в считанные секунды, так почему бы вы захотели сделать это самостоятельно? Кроме того, вы получаете возможность указать любую версию, которую хотите, без необходимости перенастраивать каждый раз — по желанию.
Иногда разработчики используют подмодули Git, чтобы избежать копирования исходного кода библиотеки в приложение. Это нормально, но лично я презираю подмодули. Git просто не реализует их очень элегантно, и неизбежно вы столкнетесь с ошибками, когда разработчик не обновит указатель субмодуля должным образом или забудет нажать или вытащить коммиты субмодуля. Вдобавок ко всему этому, вам все равно придется выполнять интеграцию библиотек самостоятельно.
Если вы никогда не использовали CocoaPods, надеюсь, я вдохновил вас попробовать один из самых ценных инструментов в наборе инструментов iOS!