RAC处理网络请求和界面交互
前言
众所周知RAC学习曲线陡峭,作为新手的我也踩了不少坑.学习Rx的过程首先要学会基本的操作,然后再组合操作完成复杂的需求,就像习武先学基本的招式,再利用基本招式产生组合拳.网上关于RAC 组合拳的优质文章并不多,在网上所搜到的项目大部分对Rx的运用也非常粗糙单调,这里我介绍此人的一系列文章.这篇博客的目的是给自己的学习之路做做笔记,记录一下踩的坑和得到的收获,希望也能帮到有需要的人.
需求
在开发中,很多时候我们需要在N个网络请求完毕之后再进行UI界面的更新.假设现在我们有A请求和B请求,并且这两个请求是并行请求,没有顺序执行关系,在A,B请求完成之后刷新界面.
假设现在开始两个网络请求:
[self.viewModel.commandA execute:nil];
[self.viewModel.commandB execute:nil];
然后需要在网络请求命令执行的时候转菊花或者进行下拉刷新的UI动作.
由于有多个网络请求,所以可以将多个请求的执行信号合并成一个信号.
@weakify(self);
[[RACSignal
merge:@[
self.viewModel.commandA.executing,
self.viewModel.commandB.executing
]]
subscribeNext:^(NSNumber *loading) {
@strongify(self);
NSLog(@"%@",loading);
if (loading.boolValue) {
[self.tableView.header beginRefreshing];
} else {
[self.tableView.header endRefreshing];
[self.tableView reloadData];
}
}];
得到的log值为:
0
0
1
1
0
0
但是这种做法有问题,我们先看看merge操作的时序图:
可以看到,merge操作所产生的新信号能够在被订阅时得到原信号们所产生的输出值.也就是说我们subscribeNext订阅到的值是两个executing信号实时的输出的集合.但是当其中一个网络操作较另一个操作耗时时,其中一个执行信号输出0表示执行完毕,并对界面进行了刷新,然而另一个操作N秒之后才会执行完成.如log所示,当第一个请求完成输出0时,第二个请求还在进行.
这样的情况显然不是我们想要的结果.
因此,merge方法并不适合该场景,应该换成combineLatest.
combineLatest能在每个被订阅信号发生变化的时候,都会取得每个信号的最新值应用在函数上.在我们的例子中,每个executing信号发生变化,我们还要对其他信号的状态进行观察,才能判断现在所处的是否是刷新状态.我们将方法替换掉:
@weakify(self);
[[RACSignal
combineLatest:@[
self.viewModel.commandA.executing,
self.viewModel.commandB.executing
]]
subscribeNext:^(NSNumber *loading) {
@strongify(self);
NSLog(@"%@",loading);
if (loading.boolValue) {
[self.tableView.header beginRefreshing];
} else {
[self.tableView.header endRefreshing];
[self.tableView reloadData];
}
}];
此时的代码运行会出错,因为订阅得到的值loading实际上是一个RACTuple,里面包含了每个被订阅信号上最新的值.
其实我们只关心当前是不是处于网络请求状态,也就是说,我们只关心两种情况.
第一种情况,RACTuple中的值都为0,说明网络请求还没开始,或者网络请求已经结束.
第二种情况,RACTuple中有一个值为1,说明正在网络请求中.
我们拿到这个RACTuple,可以做map或reduce操作,但还有更高效的做法.
实际上,这个操作就是逻辑或操作,真值表为:
| A | B | OR |
|---|---|---|
| 1 | 1 | 1 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 0 | 0 | 0 |
RAC中提供了or操作的方法.
@weakify(self);
[[[RACSignal
combineLatest:@[
self.viewModel.commandA.executing,
self.viewModel.commandB.executing
]]
or]
subscribeNext:^(NSNumber *loading) {
@strongify(self);
NSLog(@"%@",loading);
if (loading.boolValue) {
[self.tableView.header beginRefreshing];
} else {
[self.tableView.header endRefreshing];
[self.tableView reloadData];
}
}];
此时log如下:
0
1
1
1
0
和最开始的log相比,为什么少了个刚开始的0呢?仔细看上方combineLatest的图,当两个信号都发送值时才有第一个值合并,这点又和merge有区别.
我们似乎完成了我们的目的,但代码还可以继续优化.比如刚开始得到的0,这应该是信号初始发出的,对于我们来说根本没有用,我们可以排除这个值的干扰.
@weakify(self);
[[[[RACSignal
combineLatest:@[
self.viewModel.commandA.executing,
self.viewModel.commandB.executing
]]
or]
skipWhileBlock:^BOOL(NSNumber *loading) {
return ![loading boolValue];
}]
subscribeNext:^(NSNumber *loading) {
@strongify(self);
NSLog(@"%@",loading);
if (loading.boolValue) {
[self.tableView.header beginRefreshing];
} else {
[self.tableView.header endRefreshing];
[self.tableView reloadData];
}
}];
我们增加了skipWhileBlock方法.当得到第一个返回值为yes之前,后面的subscribeNext将不会订阅到值.
在第一个值为
1之前,所有的值都丢弃.得到log:
1
1
1
0
很好,我们又进了一步.接下来还有点问题,连续三次的1也可以进行过滤,因为正在进行刷新状态,不用每次得到1又进行刷新.
@weakify(self);
[[[[[RACSignal
combineLatest:@[
self.viewModel.commandA.executing,
self.viewModel.commandB.executing
]]
or]
skipWhileBlock:^BOOL(NSNumber *loading) {
return ![loading boolValue];
}]
distinctUntilChanged]
subscribeNext:^(NSNumber *loading) {
@strongify(self);
NSLog(@"%@",loading);
if (loading.boolValue) {
[self.tableView.header beginRefreshing];
} else {
[self.tableView.header endRefreshing];
[self.tableView reloadData];
}
}];
distinctUntilChanged这个方法很好理解.
distinctUntilChanged
此时的log:
1
0
完美!
