ReactiveCocoa 简单介绍
- 观察值
你别动,你一动我就知道。
|
|
- 单边
你唱歌,我就跳舞
|
|
- 双边
你向西,他就向东,他向左,你就向右。
|
|
- 代理
你是程序员,你帮我写个app吧
|
|
|
|
- 广播
知道你的频道,我就能听到你了。
|
|
- 节流
不好意思,这里一秒钟只能通过一个人
|
|
- 连接
生活是一个故事接一个故事
|
|
- 合并
污水都应该流入污水处理厂被处理
|
|
- 映射
我可以点石成金。
|
|
- 过滤
未满十八岁,禁止进入。
|
|
- 扁平
打蛋液,煎鸡蛋,上盘。
|
|
- 重放
一次制作,多次观看。
|
|
- 重试
成功之前可能需要数百次失败
|
|
下面是 MVVM 与 ReactiveCocoa 项目实例演示
摘录翻译自ReactiveCocoa and MVVM, an Introduction
定义MVVM
Model - model 在 MVVM 中没有真正的变化. 取决于你的偏好, 你的 model 可能会或可能不会封装一些额外的业务逻辑工作. 我更倾向于把它当做一个容纳表现数据-模型对象信息的结构体, 并在一个单独的管理类中维护的创建/管理模型的统一逻辑.
View - view 包含实际 UI 本身(不论是 UIView 代码, storyboard 和 xib), 任何视图特定的逻辑, 和对用户输入的反馈. 在 iOS 中这不仅需要 UIView 代码和那些文件, 还包括很多需UIViewController 处理的工作.
View-Model - 这个术语本身会带来困惑, 因为它混搭了两个我们已知的术语, 但却是完全不同的东东. 它不是传统数据-模型结构中模型的意思(又来了, 只是我喜欢这个例子). 它的职责之一就是作为一个表现视图显示自身所需数据的静态模型;但它也有收集, 解释和转换那些数据的责任. 这留给了 view (controller) 一个更加清晰明确的任务: 呈现由 view-model 提供的数据.
View-Model 和 View Controller, 在一起,但独立
- 有一个让用户输入他们姓名的
UITextField
, 和一个写着 “Go” 的UIButton
- 有显示被查看的当前用户头像和姓名的
UIImageView
和UILabel
各一个 - 下面放着一个显示最新回复推文的
UITableView
- 允许无限滚动
View-Model 实例
我们的 view-model 头文件应该长这样:
|
|
相当直截了当的填充. 注意到这些壮丽的 readonly
属性了么?这个 view-model 暴漏了视图控制器所必需的最小量信息, 视图控制器实际上并不在乎 view-model 是如何获得这些信息的. 现在我们两者都不在乎. 仅仅假定你习惯于标准的网络服务请求, 校验, 数据操作和存储.
视图控制器从 view-model 获取的数据将用来:
- 当
usernameValid
的值发生变化时触发 “Go” 按钮的enabled
属性 - 当
usernameValid
等于NO
时调整按钮的alpha
值为0. 5(等于YES
时设为1. 0) - 更新
UILable
的text
属性为字符串userFullName
的值 - 更新
UIImageView
的image
属性为userAvatarImage
的值 - 用
tweets
数组中的对象设置表格视图中的 cell (后面会提到) - 当滑到表格视图底部时如果
allTweetsLoaded
为NO
, 提供一个 显示 “loading” 的 cell
视图控制器将对 view-model 起如下作用:
- 每当
UITextField
中的文本发生变化, 更新 view-model 上仅有的readwrite
属性username
- 当 “Go” 按钮被按下时调用 view-mode的
getTweetsForCurrentUsername
方法 - 当到达表格中的 “loading” cell 时调用 view-model 上的
loadMoreTweets
方法
视图控制器不做的事儿:
- 发起网络服务调用
- 管理
tweets
数组 - 判定
username
内容是否有效 - 将用户的姓和名格式化为全名
- 下载用户头像并转成
UIImage
(如果你习惯在UIImageView
上使用类别从网络加载图片, 你可以暴漏 URL 而不是图片. 这样就给 view-model 与 UIKit 之间一个更清晰的划分, 但我视UIImage
为数据而非数据的确切显示. 这些东西不是固定死的. )
进入 ReactiveCocoa
这看起来可能像是为我们应用流程文档中的一张老旧的计算机科学图解. 通过陈述式的编程, 我们使用了更高层次的抽象, 来让我们实际编程更靠近我们在脑海中设计流程的方式. 我们让电脑为我们做更多工作. 实际的代码更加像这幅图了.
RACSignal
RACSignal
(信号)就 RAC 来说是构造单元. 它代表我们最终将要收到的信息. 当你能将未来某时刻收到的消息具体表示出来时, 你可以开始预先(陈述性)运用逻辑并构建你的信息流,而不是必须等到事件发生(命令式).
信号会为了控制通过应用的信息流而获得所有这些异步方法(委托, 回调 block, 通知, KVO, target/action 事件观察, 等)并将它们统一到一个接口下.这只是直观理解. 不仅是这些, 因为信息会流过你的应用, 它还提供给你轻松转换/分解/合并/过滤信息的能力.
用 ReactiveCocoa 将 view-model 与视图控制器连接起来.
|
|
|
|
在这我们用 RAC 库中的方法从 UITextField
拉取一个信号. 这行代码将 view-model 上的可读写属性 username 绑定到文本框上的用户输入的任何更新.
|
|
在这我们用 RACObserve 方法在 view-model 的 usernameValid
属性上创建了一个信号 usernameIsValidSignal
. 无论何时属性发生变化, 它将会沿着管道发送一个新的 @YES 或 @NO. 我们拿到那个值并将其绑定到 goButton
的两个属性上. 首先我们将 alpha
分别对应 YES 或 NO 更新到1或0. 5(记着在这必须返回 NSNumber
). 然后我们直接将信号绑定到enabled
属性, 因为 YES 和 NO 在这无需转换就能完美地运作.
|
|
下面我们为表头的图像视图和用户标签创建绑定, 再次在 view-model 上对应的属性上用 RACObserve 宏创建信号
|
|
这货看上去有点诡异, 所以我们在这上多花点时间. 我们想在 view-model 上 tweets
数组或 allTweetsLoaded
属性发生变化时更新表格视图. (在这个例子中, 我们要用一个简单的方法来重新加载整张表. )所以我们将这两个属性被观察后创建的两个信号合并成一个更大的信号, 当两个属性中有一个发生变化, 这个信号就会发送值. (你一贯认为信号的值是同类型的, 不会像这个信号有一样混杂的值. 这很可能在 Swift 版本的 RAC 中强制要求, 但在这我们不关心发出的真实值, 我们只是用它来触发表格式图的重新加载. )
那么这儿看起来最吓人的部分可能是信号链中的bufferWithTime: onScheduler:
方法. 需要它来围绕 UIKit 中的一个问题进行变通. tweets
和 allTweetsLoaded
这两个属性我们都需要追踪, 万一 tweets
变化和 allTweetsLoaded
为否(不管怎样我们都得重新加载表格). 有时两个属性都将在同一准确的时间发生变化, 意味着合并后的大信号中的两个信号都会发送一个值, 那么 reloadData
方法将会在同一个运行循环中被调用两次. UIKit 不喜欢这样. bufferWithTime:
在给明的时间内抓取所有下一个到来的值, 当给定的时间过后将所有值合在一起发给订阅者. 通过传入0作为时间, bufferWithTime:
将会抓取那个合并信号在特定的运行循环中发出的全部值, 并将他们一起发送出去. (NSTimer
以同样的方式工作, 这不是巧合, 因为 bufferWithTime:
是用 NSTimer
构建的. )暂时不用担心 scheduler, 试把它想做指明这些值必须在主线程上被发送. 现在我们确保 reloadData
每次运行循环只被调用一次.
注意我在这用 @weakify/@strongify
宏切换 strong 和 weak. 这在创建所有这些 block 时非常重要. 在 RAC 的 block 中使用 self
时self
将会被捕获为强引用并得到保留环, 除非你尤其意识到要破除保留环
|
|
我们已经搞定了 cellForRowAtIndexPath 的第一部分, 那么我在这将只说下 loading cell:
|
|
这是另一块我们以后将利用到 RACCommand 的地方, 但目前我们只是调用 view-model 的 loadMoreTweets 方法. 我们将只是信任如果 cell 显示或隐藏多次的话 view-model 会避免多次内部调用.
|
|
这段现在应该非常直接了, 除此之外我想指出一点. 我们正在将图片和文字绑定到 UI 上对应的属性, 但注意 viewModel
出现在 RACObserve
宏中逗号右边. 这些 cell 终将被重用, 新的 view-models 将会被赋值. 如果我们不将 viewModel
放在逗号右边, 那就会监听 viewModel 属性的变化然后每次都要重新设置绑定;如果放在逗号右边, RACObserve
将会为我们负责这些事儿. 因此我们只需要设定一次绑定并让 Reactive Cocoa 做剩余的部分. 这是在绑定表格 cell 时为了性能需要记住的好东西. 我在实践中即使是有很多表格 cell 依然没有出过问题.