2019 年 8 月 5 日
关注 @dnkoutsoCocoaPods 1.8 将 CDN 切换为默认规范仓库源,并带来了一些增强功能!
CDN 作为默认
CDN 支持最初在 1.7 版本 中引入,并在 1.7.2 中最终确定。其目的是大幅加快初始设置和依赖项分析。使用 1.8,CocoaPods 不再 需要克隆现在庞大的 主规范仓库 才能运行,用户几乎可以立即将他们的项目与 CocoaPods 集成。
以下是在不到一分钟内使用 CocoaPods 1.8 新安装集成和构建 iOS 项目的视频演示
你可以使用以下步骤安全地删除 主规范仓库
首先,编辑你的 Podfile
以将 CDN 设置为主要源
- source 'https://github.com/CocoaPods/Specs.git'
+ source 'https://cdn.cocoapods.org/'
然后,运行以下命令以从你的托管仓库列表中将其移除
pod repo remove master
注意:如果你希望继续使用基于 git
的源,则必须确保通过 Podfile
中的 source
DSL 明确 指定它,否则 CocoaPods 将自动使用 CDN 进行依赖项解析。
就是这样!有关 CDN 的更多信息,请阅读我们之前的博客文章 此处!
info_plist
Podspec DSL
当需要时,CocoaPods 会自动为 pod、应用规范和测试规范生成 Info.plist
文件,例如当 Podfile
通过指定 use_frameworks!
选项需要动态框架时。
Podspec 现在支持通过 info_plist
DSL 修改其生成的 Info.plist
文件的内容。虽然我们预计这将最常用于修改框架的 bundle 标识符,但可以包含任何键值对。指定的这些值将覆盖 CocoaPods 包含的任何默认值。
以下是一个示例
Pod::Spec.new do |s|
s.name = 'NetworkingLib'
s.version = '1.0.0'
# ...rest of attributes here
s.info_plist = {
'CFBundleIdentifier' => 'com.awesomecompany.networking',
'SERVER_URL' => 'https://example.com/api'
}
end
在 1.7 中引入应用规范后,pod 作者能够为其 pod 描述一个应用,例如一个演示应用。新的 info_plist
DSL 进一步增强了应用规范的功能,允许 pod 规范自定义生成的 Info.plist
,其中包含重要的设置,例如 bundle 标识符、iOS 安全和隐私设置、设备方向支持等。
Pod::Spec.new do |s|
s.name = 'ToastLib'
s.version = '1.0.0'
# ...rest of attributes here
s.app_spec 'ToastCatalog' do |app_spec|
app_spec.info_plist = {
'CFBundleIdentifier' => 'com.bakery.ToastCatalog',
'UISupportedInterfaceOrientations' => [
'UIInterfaceOrientationPortrait',
'UIInterfaceOrientationLandscapeLeft',
'UIInterfaceOrientationLandscapeRight',
],
'UILaunchStoryboardName' => 'LaunchScreen',
'UIMainStoryboardFile' => 'AppStoryboard',
'NSLocationWhenInUseUsageDescription' => 'ToastCatalog uses your location to find nearby Toast!'
}
end
end
请注意,在未生成 Info.plist
文件的情况下,info_plist
属性将不起作用,例如当 pod 集成作为静态库时。如果你的库需要始终存在 Info.plist
中包含的数据,我们建议将其作为资源包含在内。
有关此工作原理和背后的原理的更多详细信息,请查看 此处 的 RFC。
project_name
Podfile DSL
CocoaPods 1.7 引入了 generate_multiple_pod_projects
选项,该选项将每个 pod 安装到其自己的 Xcode 项目中。CocoaPods 1.8 通过引入 project_name
DSL 进一步扩展,允许 pod 消费者指定项目名称以集成给定的 pod。
这为消费者提供了许多新的可能性,可以将某些 pod 按逻辑分组在一起。考虑以下示例
install! 'cocoapods', :generate_multiple_pod_projects => true
target 'MyApp' do
use_frameworks!
pod 'Moya', :project_name => 'Networking'
pod 'Alamofire', :project_name => 'Networking'
pod 'Result', :project_name => 'Networking'
target 'MyAppTests' do
inherit! :search_paths
pod 'OCMock', :project_name => 'Testing'
end
end
将产生以下结果
消费者可以自行选择分组,并在其 Podfile
中提供辅助方法,自动应用要使用的项目名称。例如,另一个分组思路是按平台(例如 iOS
或 macOS
)对 pod 进行分组。
注意:project_name
选项当前要求同时启用 generate_multiple_pod_projects
安装选项才能发挥作用。增量安装也已更新,以考虑为每个 pod 使用的项目名称,并且将继续按预期工作。
测试规范增强
测试规范已成为 CocoaPods 的一个组成部分,并且添加了一些新功能。
UI 测试包支持
现在可以支持“UI 测试包”,您现在可以指定 test_type
以用于给定的 test_spec
。默认值为 :unit
,它将创建一个单元测试包。考虑我们最喜欢的 pod CannonPodder
的以下示例
Pod::Spec.new do |s|
s.name = 'CannonPodder'
s.version = '1.0.0'
# ...rest of attributes here
s.test_spec 'UITests' do |test_spec|
test_spec.requires_app_host = true
test_spec.test_type = :ui
test_spec.source_files = 'UITests/**/*.swift'
end
end
这将在安装时成功集成 CannonPodder-UI-UITests
UI 测试包,并将自动创建一个应用主机以供其使用。
注意:UI 测试包需要一个应用主机才能运行,因此如果您选择将测试规范集成到 UI 测试包中,则必须始终指定 requires_app_host
。
可自定义应用主机
在大多数情况下,为您的测试规范生成一个应用主机就足以在其中执行您的测试。但是,在某些情况下,pod 作者可能希望进一步自定义用于 test_spec
的应用主机。
例如,pod 作者可能希望为其应用主机或在测试期间使用的资源包指定其他依赖项。应用规范是此项工作的理想选择,因为它们提供了大部分脚手架,并且在 1.8 中,现在可以通过 app_host_name
DSL 将 app_spec
设置为 test_spec
的应用主机。
以下是一个示例
Pod::Spec.new do |s|
s.name = 'CannonPodder'
s.version = '1.0.0'
# ...rest of attributes here
s.app_spec 'DemoApp' do |app_spec|
app_spec.source_files = 'DemoApp/**/*.swift'
# Dependency used only by this app spec.
app_spec.dependency 'Alamofire'
end
s.test_spec 'Tests' do |test_spec|
test_spec.requires_app_host = true
# Use 'DemoApp' as the app host.
test_spec.app_host_name = 'CannonPodder/DemoApp'
# ...rest of attributes here
# This is required since 'DemoApp' is specified as the app host.
test_spec.dependency 'CannonPodder/DemoApp'
end
end
将产生以下结果
这个强大的新功能为希望对其测试规范使用的应用主机进行更精细控制的 pod 作者开辟了新的可能性。
下一步是什么?
CocoaPods 1.8 是一个非常令人兴奋的版本,我们非常高兴您能试用它,并建议您升级
$ gem install cocoapods --pre
对于未来版本,我们将继续探索允许 pod 作者和 pod 使用者将集成 pod 配置到其项目中的新方法,例如通过指定单个包或链接设置。我们已发布 提案,我们目前正在探索,欢迎您发表评论!
一如既往,我们要感谢所有贡献者让此次发布成为现实!
查看 变更日志 以获取完整更改列表。
🚀