网络层回访

    Completion blocks?这是另外一个使用Signals的机会。更深入一点来说，我们可以使用NSURLConnection的ReactiveCocoa的扩展。下面我们来重写上面的方法：

    1. + (void)downloadThumbnailForPhotoModel:(FRPPhotoModel *)photoModel {
    2.     RAC(photoModel, thumbnailData) = [self download:photoModel.thumbnailURL];
    3. }
    5. + (void)downloadFullsizedImageForPhotoModel:(FRPPhotoModel *)photoModel {
    6.     RAC(photoModel,fullsizedData) = [self download:photoModel.fullsizedURL];
    7. }
    9. + (RACSignal *)download:(NSString *)urlString {
    10.     NSAssert(urlString , @"URL must not be nil");
    12.     NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString: urlString]];
    14.     return [[[NSURLConnection rac_sendAsynchronousRequest:request]
    15.                     return [value second];
    16.                 }] deliverOn:[RACScheduler mainThreadScheduler]];
    17. }

    这里有两个大的不同：

    1. 我们使用RAC来绑定downloadFullsizedImageForPhotoModel:返回的信号的最新值。
    2. 我们返回返回值的映射。

    我们来看看这里究竟发生了什么。
    看文档：rac_sendAsynchronousRequest:返回一个发送网络请求响应值的信号。RACTuple它所发送的内容分别包含响应和数据。有网络错误发生时，它会抛出错误。 最后我们改变线程的调度，将signal切换到主线程上。 (一个线程的调度者类似于一个线程。)

    看，网络信号将会把它的值返回给后台的调度者，如果我们不阻止它，它可能最终会去从事更新UI的事件，而后台线程是没有能力更新UI的。

    通常，我不推荐将一个model绑定到多个signal，然而，我们知道这个信号会在完成网络调用后立即执行完并结束订阅。只要我们仅在一个实例上绑定这个keyPath，这种就是安全的。

    我们可以用类似的方式抽象掉使用RACReplaySubject的部分,来重新审视我们的fetchPhotoDetails:方法吧。

    1. + (RACReplaySubject *)fetchPhotoDetails:(FRPPhotoModel *)photoModel {
    2.     RACReplaySubject *subject = [RACReplaySubject subject];
    4.     NSURLRequest *request = [self photoURLRequest:photoModel];
    5.     [NSURLConnection sendAsynchronousRequest:request
    6.                  queue:[NSOperationQueue mainQueue]
    7.     completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
    8.             if(data) {
    9.                 id results = [NSJSONSerialization JSONObjectWithData:data options:0 error:nil][@"photo"];
    10.                 [self downloadFullsizedImageForPhotoModel:photoModel];
    11.                 [subject sendNext:photoModel];
    12.                 [subject sendCompleted];
    13.             }
    14.             else {
    15.                 [subject sendError:connectionError];
    17.     }];
    20.     return subject;
    22. }

    有一点点凌乱，我们来整理下。

    注意： 返回值从RACReplaySubject *变成了RACSignal *.
    这里有很多地方需要梳理，所以我们提前做了下面这个示意图来说明：

    我们已经知道deliverOn:是怎样工作的，所以让我们来关注信号链条最末端的信号操作publish. publish返回一个RACMulitcastConnection,当信号连接上时，他将订阅该接收信号。autoconnect为我们做的是：当它返回的信号被订阅，连接到
    该(订阅背后的)信号（underly signal）。

    执行获取每一个订阅，在订阅的时候，我们返回的信号将会变“冷”。那是因为我们对底层信号进行多播，网络请求只会执行一次，但是它的结果被多播。这会导致：网络信号将只会被执行一次（当它被订阅时执行），是冷的(直到订阅为止，它不会被执行)，甚至可删除的(如果一次性处理订阅的生成)。

    基本上，我们能保证信号只会被订阅一次，我们不需要回滚(replay).

    注意：我们可以用下面的reduceEach:替代使用RACTuple的第一个map:，以便提供编译时检查。

    1. reduceEach:^id(NSURLResponse *response, NSData *data) {
    2. }]