CocoaPods - O gerenciador de dependências no iOS

Usar bibliotecas de terceiros certamente é uma das facilidades no desenvolvimento de software. Gerenciar isso em um projeto nem sempre é uma tarefa trivial já que temos versões diferentes de uma mesma biblioteca, outras vezes dependências transitivas que se conflitam. Para resolver esses problemas e facilitar a comunicação do time de desenvolvedores as ferramentas de gerenciamento de dependências existem. São exemplos dessas ferramentas: Ivy nos projetos Java e Bundle nos de Ruby.

No iOS uma ferramenta que vem se tornando padrão nos projetos, motivada também pela dificuldade de importar bibliotecas e disponibilizá-las no Xcode, é o CocoaPods embora ela também sirva para aplicações para OSX.

Instalação do CocoaPods

A sua distribuição se dá em forma de Gem (bibliotecas do mundo Ruby). Para instalar basta o famoso comando de instalação:

 gem install cocoapods 

Normalmente um arquivo com a definição das dependências é usado no diretório do projeto e tem o nome de Podfile. Nele a primeira definição é sobre para qual plataforma o projeto está sendo desenvolvido.

 platform :ios, '7.0' 

A partir disso é declarar as bibliotecas a serem usadas e definir a versão com a declaração pod que o projeto usa:

 platform :ios, '7.0'

pod 'AFNetworking', '~> 2.2.0' 

Os operadores que podem ser especificados junto com uma dependência são: >, >=, <, <= e ~>. No Podfile anterior, o operador ~> diz que qualquer versão que mantenha o MAJOR e o MINOR pode ser usado, ou seja, 2.2.0 e 2.2.1 (já que só muda o PATCH) seriam aceitos mas 2.3.0 ou qualquer acima dela não. Para mais detalhes sobre a semântica do versionamento acesse http://semver.org/.

Depois da definição das dependências um comando é usado para a download e instalação:

 pod install 

E sua saída é:

Note que agora devemos usar o .xcworkpace como projeto no Xcode e não mais o .xcodeproj. Sendo assim ao abrirmos o projeto na IDE, nosso Project Navigator estará dessa forma:

Além disso um arquivo chamado Podfile.lock foi gerado no diretório da aplicação. De acordo com ele a versão de fato instalada do AFNetworking foi a 2.2.1. Observe-o:

Existindo um Podfile.lock no projeto a execução do comando pod install irá baixar e instalar apenas as versões das bibliotecas especificadas no .lock . Portanto é fundamental que esse arquivo seja adicionado ao repositório do projeto para que todos os desenvolvedores tenham o mesmo .lock e por consequência usem sempre as mesmas versões. Caso uma alteração seja necessário no Podfile basta usarmos o comando pod update que atualizará o Podfile.lock .

Por ser tão prático e simples de usar o CocoaPods tem sido figurinha carimbada nos projetos iOS.

Criando nossos próprios Pods

Além da facilidade de uso, a praticidade de disponibilizar bibliotecas através desse gerenciador é mais um dos motivos de seu sucesso. Para criar o seu próprio Pod, um arquivo contendo a especificação da biblioteca é necessário. O Pod Spec pode ser gerado usando o comando pod spec create que não faz nada além de gerar um .podspec auxiliar. As configurações mínimas são as seguintes:

 Pod::Spec.new do |s| s.name         = "FPLibrary" s.version      = "1.0.0" s.summary      = "Just another library" s.homepage     = "http://www.fplibrary.com.br" s.license      = 'Apache License, Version 2.0' s.author       = { "Fábio Pimentel" => "[email protected]" } s.platform     = :ios, '7.0' s.source       = { :git => "https://github.com/fabiopimentel/fplibrary.git", :tag => "1.0.0" } s.source\_files  = "Classes/\*.{h,m}" end 

Esse arquivo deve estar disponível em um diretório a ser adicionado no repositório das especificações do CocoaPods. O repositório é chamado de Spec Repo e acessado via github.com/CocoaPods/Specs. Dessa forma teremos  uma estrutura similar a essa do Spec do AFNetworking de versão 2.2.1:

Portanto para cada  nova versão existe a necessidade de mais um subdiretório com o número e dentro dele um específico .podspec. Como a seguinte estrutura:

├── Specs(Spec Repo) └── ```SPEC_NAME

    └── ```VERSION

        └── ```SPEC\_NAME

.podspec

Para submeter nossas alterações um pull request deve ser feito, mas não antes de validar a spec  com um  pod spec lint na estrutura do Spec Repo clonada.

Adicionando um repositório privado

É bastante comum a prática de reaproveitar componentes e as vezes até mesmo bibliotecas internas em nossos projetos. Para este cenário temos a opção de criar um repositório privado. Esse repositório deve seguir a mesma convenção de diretórios do repositório principal que já vimos acima. E pode ser adicionado como fonte de Specs fazendo:

pod repo add nome-do-repositorio url-do-repositorio

Com toda essa simplicidade fica difícil não fazer tanto sucesso não é mesmo? Participe da Mobile Conf 2014 e venha ver esse e mais assuntos ligados ao dia-a-dia do desenvolvedor iOS na minha palestra. Se você já usa o Cocoa Pods, ou considera usá-lo nos próximos projetos, comente e compartilhe conosco suas experiências.