4 minutos de leitura
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
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.
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.
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.
É 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.
Avalie este artigo
