一 ruby 安装ios
要安装coocspod 首先须要安装ruby,能够先安装xcode,在安装macport 下载地址,最后执行命令 port install rubygit
CocoaPods是用Ruby实现的,要想使用它首先须要有Ruby的环境。幸运的是OS X系统默认的已经能够运行Ruby了,所以咱们只须要执行如下命令:github
[objc] view plaincopyxcode
$ sudo gem install cocoapods ruby
CocoaPods是以Ruby gem包的形式被安装的。在安装执行的过程当中,可能会问咱们是否是更新rake,输入y便可。这是由于rake gem包会在安装的过程当中检查更细,若是有可用的新版本就会出现刚才的选项。markdown
在安装进程结束的时候,执行命令:app
[objc] view plaincopy网站
$ pod setup ui
若是没有报错,就说明一切安装就成功了!
url
这有多是由于Ruby的默认源使用的是cocoapods.org,国内访问这个网址有时候会有问题,网上的一种解决方案是将远替换成淘宝的,替换方式以下:
[objc] view plaincopy
$ gem sources --remove https://rubygems.org/
//等有反应以后再敲入如下命令
$ gem sources -a http://ruby.taobao.org/
要想验证是否替换成功了,能够执行:
[objc] view plaincopy
$ gem sources -l
正常的输出是:
[objc] view plaincopy
*** CURRENT SOURCES ***
http://ruby.taobao.org/
gem是管理Ruby库和程序的标准包,若是它的版本太低也可能致使安装失败,解决方案天然是升级gem,执行下述命令便可:
[objc] view plaincopy
$ sudo gem update --system
[objc] view plaincopy
/Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:298:in `to_specs': Could not find 'cocoapods' (>= 0) among 6 total gem(s) (Gem::LoadError)
from /Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:309:in `to_spec'
from /Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_gem.rb:53:in `gem'
from /Users/wangzz/.rvm/rubies/ruby-1.9.3-p448/bin/pod:22:in `<main>'
这就是路径设置的问题,能够经过执行:
[objc] view plaincopy
$ rvm use ruby-1.9.3-p448
解决该问题。
升级很简单,再次执行安装命令便可:
[objc] view plaincopy
$ sudo gem install cocoapods
须要注意的是,若是安装的时候使用了sudo,升级的时候同样须要使用该关键字,否则升级完了之后又会出现路径不匹配问题。
若是以前作的一切顺利,接下来就能够体验体验CocoaPods的神奇之处了,须要通过如下几步:
为了演示这个过程,我建立了一个名为CocoaPodsTest的工程。
CocoaPods的一切都是从一个名为Podfile的文件开始的,咱们须要先建立这个文件。我的习惯使用命令行,我会这样作:
[objc] view plaincopy
$ cd /Users/wangzz/Desktop/CocoaPodsTest
$ touch Podfile
首先进入到工程的根目录下,建立空白的Podfile文件,建立完毕的目录结构以下图:
PS:Podfile文件也能够不放在工程的根目录下,只是会稍微麻烦点,在下一篇文章中会有介绍,敬请关注。)
根据须要,咱们能够在Podfile文件中写入须要用到的第三方库,以SBJson、AFNetworking、Reachability三个库为例,个人Podfile内容以下:
[objc] view plaincopy
platform :ios
pod 'Reachability', '~> 3.0.0'
pod 'SBJson', '~> 4.0.0'
platform :ios, '7.0'
pod 'AFNetworking', '~> 2.0'
准备工做都完成后,开始导入第三方库:
[objc] view plaincopy
$ cd /Users/wangzz/Desktop/CocoaPodsTest
$ pod install
首先进入工程根目录,而后执行pod install命令,CocoaPods就开始为咱们作下载源码、配置依赖关系、引入须要的framework等一些列工做,命令的执行结果打印出来以下:
[objc] view plaincopy
Analyzing dependencies
Downloading dependencies
Installing AFNetworking (2.1.0)
Installing JSONKit (1.5pre)
Installing Reachability (3.0.0)
Generating Pods project
Integrating client project
[!] From now on use `CocoaPodsTest.xcworkspace`.
这就说明pod install命令执行成功了。再来看看工程根目录发生的变化,以下图:
能够看到,工程的根目录下多了三个东西:CocoaPodsTest.xcworkspace、Podfile.lock文件和Pods目录。
(PS:篇幅有限,Podfile.lock文件会放到系列文章的下一篇介绍,敬请关注。)
再看看刚才执行完pod install命令打印出来的内容的最后一行:
[objc] view plaincopy
[!] From now on use `CocoaPodsTest.xcworkspace`.
提示咱们从如今起,咱们须要使用CocoaPodsTest.xcworkspace文件来开发。
对于工程发生的变化,有几点须要说明:
第三方库会被编译成静态库供咱们正真的工程使用
CocoaPods会将全部的第三方库以target的方式组成一个名为Pods的工程,该工程就放在刚才新生成的Pods目录下。整个第三方库工程会生成一个名称为libPods.a的静态库提供给咱们本身的CocoaPodsTest工程使用。
咱们的工程和第三方库所在的工程会由一个新生成的workspace管理
为了方便咱们直观的管理工程和第三方库,CocoaPodsTest工程和Pods工程会被以workspace的形式组织和管理,也就是咱们刚才看到的CocoaPodsTest.xcworkspace文件。
原来的工程设置已经被更改了,这时候咱们直接打开原来的工程文件去编译就会报错,只能使用新生成的workspace来进行项目管理。
打开CocoaPodsTest.xcworkspace,界面以下:
上文讲过,在开始使用CocoaPods,执行完pod install以后,会生成一个Podfile.lock文件。这个文件看起来跟咱们关系不大,实际上绝对不该该忽略它。
该文件用于保存已经安装的Pods依赖库的版本,经过CocoaPods安装了SBJson、AFNetworking、Reachability三个POds依赖库之后对应的Podfile.lock文件内容为:
[objc] view plaincopy
PODS:
- AFNetworking (2.1.0):
- AFNetworking/NSURLConnection
- AFNetworking/NSURLSession
- AFNetworking/Reachability
- AFNetworking/Security
- AFNetworking/Serialization
- AFNetworking/UIKit
- AFNetworking/NSURLConnection (2.1.0):
- AFNetworking/Reachability
- AFNetworking/Security
- AFNetworking/Serialization
- AFNetworking/NSURLSession (2.1.0):
- AFNetworking/NSURLConnection
- AFNetworking/Reachability (2.1.0)
- AFNetworking/Security (2.1.0)
- AFNetworking/Serialization (2.1.0)
- AFNetworking/UIKit (2.1.0):
- AFNetworking/NSURLConnection
- Reachability (3.0.0)
- SBJson (4.0.0)
DEPENDENCIES:
- AFNetworking (~> 2.0)
- Reachability (~> 3.0.0)
- SBJson (~> 4.0.0)
SPEC CHECKSUMS:
AFNetworking: c7d7901a83f631414c7eda1737261f696101a5cd
Reachability: 500bd76bf6cd8ff2c6fb715fc5f44ef6e4c024f2
SBJson: f3c686806e8e36ab89e020189ac582ba26ec4220
COCOAPODS: 0.29.0
Podfile.lock文件最大得用处在于多人开发。对于没有在Podfile中指定Pods依赖库版本的写法,以下:
[objc] view plaincopy
pod 'SBJson'
该句话用于获取当前SBJson这个Pods依赖库的最新版本。
当团队中的某我的执行完pod install命令后,生成的Podfile.lock文件就记录下了当时最新Pods依赖库的版本,这时团队中的其它人check下来这份包含Podfile.lock文件的工程之后,再去执行pod install命令时,获取下来的Pods依赖库的版本就和最开始用户获取到的版本一致。若是没有Podfile.lock文件,后续全部用户执行pod install命令都会获取最新版本的SBJson,这就有可能形成同一个团队使用的依赖库版本不一致,这对团队协做来讲绝对是个灾难!
在这种状况下,若是团队想使用当前最新版本的SBJson依赖库,有两种方案:
更改Podfile,使其指向最新版本的SBJson依赖库;
执行pod update命令;
鉴于Podfile.lock文件对团队协做如此重要,咱们须要将它添加到版本管理中。
对于普通用户来讲,使用CocoaPods咱们打交道最多的就是Podfile文件。CocoaPods是用ruby实现的,所以Podfile文件的语法就是ruby的语法。接着从如下几个方面来介绍Podfile:
这是在上篇文章中,遗留的一个问题。一般状况下咱们都推荐Podfile文件都放在工程根目录,以下图所示:
事实上Podfile文件能够放在任意一个目录下,须要作的是在Podfile中指定工程的路径,和原来相比,Podfile文件就在最开始的位置增长了一行,具体内容以下:
[objc] view plaincopy
xcodeproj "/Users/wangzz/Desktop/CocoaPodsTest/CocoaPodsTest.xcodeproj"
platform :ios
pod 'Reachability', '~> 3.0.0'
pod 'SBJson', '~> 4.0.0'
platform :ios, '7.0'
pod 'AFNetworking', '~> 2.0'
指定路径使用的是xcodeproj关键字。
此后,进入Podfile文件所在路径,执行pod install命令就会和以前同样下载这些Pods依赖库,并且生成的相关文件都放在了Podfile所在目录下面,以下图:
和以前同样,咱们仍然须要使用这里生成的workspace文件打开工程。
Podfile本质上是用来描述Xcode工程中的targets用的。若是咱们不显式指定Podfile对应的target,CocoaPods会建立一个名称为default的隐式target,会和咱们工程中的第一个target相对应。换句话说,若是在Podfile中没有指定target,那么只有工程里的第一个target可以使用Podfile中描述的Pods依赖库。
若是想在一个Podfile中同时描述project中的多个target,根据需求的不一样,能够有不一样的实现方式。为了说明问题,在原来的工程中再建立一个名称为Second的target,如今的project中包含的target有
①多个target中使用相同的Pods依赖库
好比,名称为CocoaPodsTest的target和Second的target都须要使用Reachability、SBJson、AFNetworking三个Pods依赖库,可使用link_with关键字来实现,将Podfile写成以下方式:
[objc] view plaincopy
link_with 'CocoaPodsTest', 'Second'
platform :ios
pod 'Reachability', '~> 3.0.0'
pod 'SBJson', '~> 4.0.0'
platform :ios, '7.0'
pod 'AFNetworking', '~> 2.0'
这种写法就实现了CocoaPodsTest和Second两个target共用相同的Pods依赖库。
②不一样的target使用彻底不一样的Pods依赖库
CocoaPodsTest这个target使用的是Reachability、SBJson、AFNetworking三个依赖库,但Second这个target只须要使用OpenUDID这一个依赖库,这时可使用target关键字,Podfile的描述方式以下:
[objc] view plaincopy
target :'CocoaPodsTest' do
platform :ios
pod 'Reachability', '~> 3.0.0'
pod 'SBJson', '~> 4.0.0'
platform :ios, '7.0'
pod 'AFNetworking', '~> 2.0'
end
target :'Second' do
pod 'OpenUDID', '~> 1.0.0'
end
其中,do/end做为开始和结束标识符。
再引入依赖库时,须要显示或隐式注明引用的依赖库版本,具体写法和表示含义以下:
[objc] view plaincopy
pod 'AFNetworking' //不显式指定依赖库版本,表示每次都获取最新版本
pod 'AFNetworking', '2.0' //只使用2.0版本
pod 'AFNetworking', '> 2.0' //使用高于2.0的版本
pod 'AFNetworking', '>= 2.0' //使用大于或等于2.0的版本
pod 'AFNetworking', '< 2.0' //使用小于2.0的版本
pod 'AFNetworking', '<= 2.0' //使用小于或等于2.0的版本
pod 'AFNetworking', '~> 0.1.2' //使用大于等于0.1.2但小于0.2的版本
pod 'AFNetworking', '~>0.1' //使用大于等于0.1但小于1.0的版本
pod 'AFNetworking', '~>0' //高于0的版本,写这个限制和什么都不写是一个效果,都表示使用最新版本
根据Podfile文件指定的内容,安装依赖库,若是有Podfile.lock文件并且对应的Podfile文件未被修改,则会根据Podfile.lock文件指定的版本安装。
每次更新了Podfile文件时,都须要从新执行该命令,以便从新安装Pods依赖库。
若果Podfile中指定的依赖库版本不是写死的,当对应的依赖库有了更新,不管有没有Podfile.lock文件都会去获取Podfile文件描述的容许获取到的最新依赖库版本。
命令格式为:
[objc] view plaincopy
$ pod search OpenUDID
后面的OpenUDID为参数。
从命令的名称不难看出,该命令是用来按名称搜索可用的Pods依赖库,执行结果以下:
[objc] view plaincopy
-> OpenUDID (1.0.0)
Open source initiative for a universal and persistent UDID solution for iOS.
pod 'OpenUDID', '~> 1.0.0'
- Homepage: http://OpenUDID.org
- Source: https://github.com/ylechelle/OpenUDID.git
- Versions: 1.0.0 [master repo]
这里咱们搜到了一条可用数据,里面描述了OpenUDID库的简要信息。其实咱们真正须要的是上述结果中的第三行:
[objc] view plaincopy
pod 'OpenUDID', '~> 1.0.0'
不难看出,这是咱们须要添加到Podfile文件中的。
有了这条命令,就能够方便、迅速地找到须要的Pods依赖库。
命令格式为:
[ruby] view plaincopy
$ pod setup
执行完了之后会打印:
[ruby] view plaincopy
Setting up CocoaPods master repo
Updating 7cd4668..f3d3ced
Fast-forward
接下来还会打印不少更新信息。
这条命令用于跟新本地电脑上的保存的Pods依赖库tree。因为天天有不少人会建立或者更新Pods依赖库,这条命令执行的时候会至关慢,还请耐心等待。咱们须要常常执行这条命令,不然有新的Pods依赖库的时候执行pod search命令是搜不出来的。
CocoaPods都托管在github上(官方连接为:https://github.com/CocoaPods),全部的Pods依赖库也都依赖github,所以第一步咱们须要建立一个属于本身的github仓库。仓库建立界面以下图:
上图中标了序号的共6处,对应的说明以下:
一、Repository name
仓库名称,这里写成WZMarqueeView,必填的;
二、Description
仓库的描述信息,可选的;
三、仓库的公开性
这里只能选Public,一个是由于Private是要money的,再一个Private别人看不到还共享个毛;
四、是否建立一个默认的README文件
一个完整地仓库,都须要README说明文档,建议选上。固然不嫌麻烦的话你也能够后面再手动建立一个;
五、是否添加.gitignore文件
.gitignore文件里面记录了若干中文件类型,凡是该文件包含的文件类型,git都不会将其归入到版本管理中。是否选择看我的须要;
六、license类型
正规的仓库都应该有一个license文件,Pods依赖库对这个文件的要求更严,是必需要有的。所以最好在这里让github建立一个,也能够本身后续再建立。我使用的license类型是MIT。
上面的各项都填写完毕后,点击Create repository按钮便可,建立成功地界面如图
到这,仓库建立过程就结束了。
为了便于向仓库中删减内容,须要先将仓库clone到本地,操做方式有多种,推荐使用命令行:
[objc] view plaincopy
$ git clone https://github.com/wangzz/WZMarqueeView.git
操做完成后,github上对应的文件都会拷贝到本地,目录结构为:
github上仓库中的.gitignore文件是以.开头的隐藏文件,所以这里只能看到两个。
后续咱们的全部文件增、删、改都在这个目录下进行。
注意:如下描述的文件都要放在步骤二clone到本地的git仓库的根目录下面。
该文件为Pods依赖库的描述文件,每一个Pods依赖库必须有且仅有那么一个描述文件。文件名称要和咱们想建立的依赖库名称保持一致,个人WZMarqueeView依赖库对应的文件名为WZMarqueeView.podspec。
1.1 podspec文件内容
WZMarqueeView.podspec的保存内容为
[ruby] view plaincopy
Pod::Spec.new do |s|
s.name = "WZMarqueeView"
s.version = "1.0.0"
s.summary = "A marquee view used on iOS."
s.description = <<-DESC
It is a marquee view used on iOS, which implement by Objective-C.
DESC
s.homepage = "https://github.com/wangzz/WZMarqueeView"
# s.screenshots = "www.example.com/screenshots_1", "www.example.com/screenshots_2"
s.license = 'MIT'
s.author = { "王中周" => "wzzvictory_tjsd@163.com" }
s.source = { :git => "https://github.com/wangzz/WZMarqueeView.git", :tag => s.version.to_s }
# s.social_media_url = 'https://twitter.com/NAME'
s.platform = :ios, '4.3'
# s.ios.deployment_target = '5.0'
# s.osx.deployment_target = '10.7'
s.requires_arc = true
s.source_files = 'WZMarqueeView/*'
# s.resources = 'Assets'
# s.ios.exclude_files = 'Classes/osx'
# s.osx.exclude_files = 'Classes/ios'
# s.public_header_files = 'Classes/**/*.h'
s.frameworks = 'Foundation', 'CoreGraphics', 'UIKit'
end
该文件是ruby文件,里面的条目都很容易知道含义。
其中须要说明的又几个参数:
①s.license
Pods依赖库使用的license类型,你们填上本身对应的选择便可。
②s.source_files
表示源文件的路径,注意这个路径是相对podspec文件而言的。
③s.frameworks
须要用到的frameworks,不须要加.frameworks后缀。
1.2 如何建立podspec文件
你们建立本身的podspec文件能够有两个途径:
①copy个人podspec文件而后修改对应的参数,推荐使用这种方式。
②执行如下建立命令:
[ruby] view plaincopy
$ pod spec create WZMarqueeView
也会建立名为WZMarqueeView.podspec的文件。可是打开建立完的文件你就会发现里面的东西太多了,不少都是咱们不须要的。
CocoaPods强制要求全部的Pods依赖库都必须有license文件,不然验证不会经过。license的类型有不少种,详情能够参考网站tl;dr Legal。在建立github仓库的时候,我已经选择了MIT类型的license。
建立Pods依赖库就是为了方便别人使用咱们的成果,好比我想共享给你们的WZMarqueeView类,是我想提供给广大用户使用的,这个类天然是必不可少的。我把这个类包含的两个文件放到一个名称为WZMarqueeView的文件夹中,对应的目录结构如图:
里面包含两个文件:WZMarqueeView.h和WZMarqueeView.m
为了快速地教会别人使用咱们的Pods依赖库,一般须要提供一个demo工程。我建立的demo工程放到了一个名为WZMarqueeViewDemo的文件夹中,该目录包含的文件以下图所示:
使用github的人应该都熟悉这个文件,它是一个成功github仓库必不可少的一部分,使用的是markdown标记语言,用于对仓库的详细说明。
以上所说的5个是建立Pods依赖库所需最基础的文件,其中一、二、3是必需的,四、5是可选但强烈推荐建立的。
添加完这些文件之后,个人github本地仓库目录就变成了下图所示的样子:
通过步骤三,向本地的git仓库中添加了很多文件,如今须要将它们提交到github仓库中去。提交过程分如下几步:
执行如下命令:
[ruby] view plaincopy
$ set the new version to 1.0.0
$ set the new tag to 1.0.0
这两条命令是为pod添加版本号并打上tag。而后执行pod验证命令:
[ruby] view plaincopy
$ pod lib lint
若是一切正常,这条命令执行完后会出现下面的输出:
[ruby] view plaincopy
-> WZMarqueeView (1.0.0)
ZMarqueeView passed validation.
到此,pod验证就结束了。
须要说明的是,在执行pod验证命令的时候,打印出了任何warning或者error信息,验证都会失败!若是验证出现异常,打印的信息会很详细,你们能够根据对应提示作出修改。
依次执行如下命令:
[ruby] view plaincopy
$ git add -A && git commit -m "Release 1.0.0."
$ git tag '1.0.0'
$ git push --tags
$ git push origin master
上述命令均属git的范畴,这里很少述。若是一切正常,github上就应该能看到本身刚添加的内容了。以下图所示:
通过前边的四步操做,你可能觉得已经结束了,不幸的是还早着呢。
要想一个Pods依赖库真正可用,还须要作最后一步操做,将咱们刚才生成的podspec文件上传到CocoaPods官方的Specs仓库中,连接为:https://github.com/CocoaPods/Specs
打开这个连接你就会发现,原来咱们能使用的,以及咱们使用pod search命令能搜索到的全部Pods依赖库都会把它们的podspec文件上传到这个仓库中,也就是说,只有将咱们的podspec文件上传到这个仓库中之后,才能成为一个真正的Pods依赖库,别人才能正常使用!
按照git的规则,要想向别人的仓库中添加文件,必须先fork一份别人的仓库,作完相应地修改后,在push给仓库的原做者,等到做者审核经过,而后合并到原来的仓库中。
流程明白了之后,天然知道该怎么干了:
进入到刚才的官方仓库连接中,点击屏幕右上角的fork按钮,以下图:
而后你们会发现本身名下会多一份仓库的分支。好比个人分支为:
执行如下命令:
[ruby] view plaincopy
$ git clone https://github.com/wangzz/Specs.git
注意,你们须要将对应的仓库地址换成本身的。
这个仓库有点大,须要有耐心啊。
Specs仓库clone到本地后,会放到一个名为Specs的文件夹中。podspec文件在Specs仓库中的保存原则是:
Pods依赖库同名文件夹--->版本号同名文件夹--->podspec文件
照此原则,我须要在Specs文件夹下创建一个名为WZMarqueeView的文件夹,而后进入到WZMarqueeView文件夹下,创建一个名称为1.0.0的文件夹,最后进入到1.0.0这个文件夹下,而且将以前建立好的WZMarqueeView.podspec文件拷贝进来。
不难理解,若是之后有对WZMarqueeView类的升级,就在WZMarqueeView文件夹下创建对应版本名称的文件夹,用于保存对应版本的podspec文件便可。
这些操做完成后,目录层次结构以下所示:
执行如下命令:
[ruby] view plaincopy
$ git add -A && git commit -m "Add WZMarqueeView podspec file"
$ git push origin master
成功之后就能在github上本身fork的Specs仓库中看到刚上传的文件了。
进入到本身fork的Specs仓库中,会看到屏幕左上角有一个绿色按钮
该按钮点进去之后会有以下图所示的界面:
点击图中的绿色Create Pull Request按钮,便可将咱们fork的Specs上作的修改pull给CocoaPods官方的Specs仓库。
到这一步后,剩下的工做就只有等了,等待CocoaPods的维护人员审核并将咱们pull上去的修改合并到官方的Specs仓库中,这个过程一般会有一天左右的等待时间。若是有任何消息,好比审核不经过,或者审核经过了,CocoaPods官方都会发邮件通知的。
等到审核经过的时候,咱们就能在官方的Specs仓库中看到本身上传的文件夹了。
固然咱们也能查看审核进度,打开这个连接:https://github.com/CocoaPods/Specs/pulls,这里能看到全部的Specs仓库pull请求,以下图:
红圈标识的就是我刚才pull上来的请求,点进去之后就能看到对应的审核进度。
若是收到了CocoaPods官方发过来的审核经过邮件之后,你可能很着急的想在本身的电脑上执行pod search命令,看看能不能搜索到本身建立的Pods依赖库。不过你确定会失望的,由于还须要执行一条命令才能在咱们的本地电脑上使用search命令搜索到咱们的依赖库:
[ruby] view plaincopy
$ pod setup
在个人CocoaPods系列教程中的第一篇:CocoaPods详解之----进阶篇中的最后部分介绍过这条命令,它会将全部的Pods依赖库tree跟新到本地。执行完这条命令,再去执行:
[ruby] view plaincopy
$ pod search WZMarqueeView
就能显示出对应的介绍信息了!