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.

cocoapods-banner

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 é:

saida_pod_install.png

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:

Project Navigator

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:

Arquivo Podfile.lock

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" => "fabio.pimentel@caelum.com.br" }
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:

Screen Shot 2014-04-16 at 4.35.17 AM.png

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.

3 Comentários

  1. Lucas Martins 20/05/2014 at 17:45 #

    Eu não conhecia! Vou testar e parece que vai ajudar bastante. Obrigado Fabio!

  2. Frederico Maia Arantes 28/05/2014 at 12:40 #

    Comecei a desenvolver pra iOS a pouco tempo e uma das primeiras ferramentas que comecei a utilizar foi o Cocoapods. Realmente simplifica muito a utilização de bibliotecas de terceiros. Muito bom.

  3. Alexandre Arantes 31/07/2014 at 16:37 #

    Boa Tarde!
    Tentei instalar o CocoaPods, porem ele retornou com a seguinte mensagem de erro:
    Fetching: nap-0.8.0.gem (100%)
    ERROR: While executing gem … (Gem::FilePermissionError)
    You don’t have write permissions for the /Library/Ruby/Gems/2.0.0 directory.

    Gostaria de saber qual a soluçao para o problema acima.
    Abs
    Alexandre

Deixe uma resposta