5

I tried the following without success. The equivalent using -subscribeNext: works as expected.

// A
[[_viewModel.loginCommand.executionSignals flatten] subscribeCompleted:^{
    NSLog(@"A");
}];

My only working implementation is as follows:

// B
[_viewModel.loginCommand.executionSignals subscribeNext:^(RACSignal *loginSignal) {
    [loginSignal subscribeCompleted:^{
        NSLog(@"B");
    }];
}];

Why doesn't -flatten work in "A", and how I can I rewrite "B" to not use a nested subscription?

Paul Young
  • 1,489
  • 1
  • 15
  • 34

2 Answers2

10

The -flatten operator returns a signal that completes only when all of the inner signals have completed, which requires the outer signal to complete as well. The same is true of -concat. Because of this, once you apply either operator, the resulting signal has no representation of individual completion, only the final aggregate completion.

Alternative to nested subscriptions, you could transform the inner signals so that they send a value that signifies completion. One way of doing this is with -materialize:

[[[_viewModel.loginCommand.executionSignals
    map:^(RACSignal *loginSignal) {
        // Using -ignoreValues ensures only the completion event is sent.
        return [[loginSignal ignoreValues] materialize];
    }]
    concat]
    subscribeNext:^(RACEvent *event) {
        NSLog(@"Completed: %@", event);
    }];

Note that I used -concat instead of -flatten, since it matches the semantics of RACCommand's default serial execution. They ultimately do the same in this case, -flatten degenerates to the behavior of -concat because the command only executes signals one at a time.

Using -materialize isn't the only way to do this, it just happens to send a value that represents completion, but that could be any value that you find appropriately significant for your use case.

Dave Lee
  • 6,299
  • 1
  • 36
  • 36
  • 2
    This is pretty common operation - show the confirmation of operation's success. For example, I want to post a message, and I expect to see wether the operation failed or completed. Is there really no way to do it more clearly? I mean, this approach is still just a subscription to the nested executionSignal. What if the command has more than one execution signal, for example? – Andrew Slabko Feb 13 '15 at 19:14
  • 2
    `RACCommand`'s `executionSignals` does not expose completion events directly. If you don't want to use `materialize`, another option is to use a meaningful value that is documented to mean "successful completion". In the case of a signal that sends no values, then you can send any value to indicate completion, and just ignore it. Yes another option is to use the `doCompleted:` operator as an alternative to nested subscription. – Dave Lee Feb 14 '15 at 06:22
  • 2
    So basically RACCommand is not for tracking if operation is failed or succeeded, it is only about tracking when the operation is executing and when it is not. Do I get it right? – Andrew Slabko Feb 14 '15 at 21:13
  • 2
    Not quite. You can track errors, you can track values/results, and you can even track completion, but unfortunately only indirectly / non-idiomatically. Its typical / primary intent is to prevent concurrent actions of some kind, instead only letting something happen one at time. To make this more powerful, it exposes a signal that indicates whether the action can begin. All of which is helpful for UIs. – Dave Lee Feb 15 '15 at 06:07
0

I just thought, technically, successful completion is just a changing of the execution state to NO, after -executionSingals has sent a value at least once and no error after the execution state changed to YES the last time.

Based on such a thoughts I made a category:

#import "RACCommand+ARLCompletedSignal.h"

@implementation RACCommand (ARLCompletedSignal)

- (RACSignal *)completed
{
    RACSignal *executing = self.executing;
    RACSignal *signals = self.executionSignals;
    RACSignal *errors = self.errors;

    RACSignal *startingExecution = [RACSignal combineLatest:@[executing, [signals take:1]]
                                                     reduce:^id(NSNumber *executing, id _){ return executing; }];

    return [[startingExecution
       ignore:@NO]
       flattenMap:^RACStream *(id value) {
           RACSignal *comletedOrFailed = [[executing ignore:@YES] subscribeOn:[RACScheduler scheduler]];
           return [[[comletedOrFailed take:1] takeUntil:errors] map:^id(id value) { return nil; }];
       }];
}

@end

Header: 

@interface RACCommand (ARLCompletedSignal)

@property (nonatomic, readonly) RACSignal *completed;

@end

Here -comleted sends nil when the command successfully finishes its operation. Also at https://gist.github.com/slabko/546de430a16994a5da8e you can find the version, which sends YES if operation finishes successfully, or NO if not.

I tried it in some of my pretty simples cases and it worked. Please, let me know, if it doesn't work for yours.

However, I believe, in most cases, subscribing to the completion of the original signal, before you pass it to the command, is the best, "hackless" option.

Andrew Slabko
  • 690
  • 8
  • 15