A co-worker recently asked me about the difference between -replay, -replayLast, and -replayLazily in the ReactiveCocoa library. I had a vague understanding of the three but was not able to confidently explain the difference, so I thought I would look into it further.
I found the header documentation to be difficult to understand if you don’t have a good understanding of RACReplaySubject and RACMulticastConnection, so I’m going to try to explain the replay methods without getting into those underlying concepts.
Subscribing to a Signal
With a “normal” RACSignal each subscription to the signal causes the subscription code to be executed again, and the subscriber only receives values that are sent after the subscription is made. I think it is easiest to show this in two different examples.
The first example shows how the subscription code gets re-executed on each subscription.
__block int num = 0;
RACSignal *signal = [RACSignal createSignal:^RACDisposable *(id subscriber) {
num++;
NSLog(@"Increment num to: %i", num);
[subscriber sendNext:@(num)];
return nil;
}];
NSLog(@"Start subscriptions");
// Subscriber 1 (S1)
[signal subscribeNext:^(id x) {
NSLog(@"S1: %@", x);
}];
// Subscriber 2 (S2)
[signal subscribeNext:^(id x) {
NSLog(@"S2: %@", x);
}];
// Subscriber 3 (S3)
[signal subscribeNext:^(id x) {
NSLog(@"S3: %@", x);
}];
Running this example will produce:
Start subscriptions
Increment num to: 1
S1: 1
Increment num to: 2
S2: 2
Increment num to: 3
S3: 3
As you can see, each subscription causes num to be incremented. Also note that num is not incremented until a subscription is made. In this way, a normal RACSignal can be thought of as lazy, as it doesn’t do any work until it has a subscriber.
Our second example shows how each subscriber only receives the values that are sent after their subscription is added.
RACSubject *letters = [RACSubject subject];
RACSignal *signal = letters;
NSLog(@"Subscribe S1");
[signal subscribeNext:^(id x) {
NSLog(@"S1: %@", x);
}];
NSLog(@"Send A");
[letters sendNext:@"A"];
NSLog(@"Send B");
[letters sendNext:@"B"];
NSLog(@"Subscribe S2");
[signal subscribeNext:^(id x) {
NSLog(@"S2: %@", x);
}];
NSLog(@"Send C");
[letters sendNext:@"C"];
NSLog(@"Send D");
[letters sendNext:@"D"];
NSLog(@"Subscribe S3");
[signal subscribeNext:^(id x) {
NSLog(@"S3: %@", x);
}];
Subscribe S1
Send A
S1: A
Send B
S1: B
Subscribe S2
Send C
S1: C
S2: C
Send D
S1: D
S2: D
Subscribe S3
In many cases this is the desired behavior. But in some cases, you don’t want the subscription code to be re-executed, e.g. a subscription makes a request to a web service and there are multiple listeners that need to be updated when the result comes in. Or maybe you want to get the history of values that have been sent on the signal prior to a subscription. This is where -replay, -replayLast, and -replayLazily can be used.
Subscribing to a -replay Signal
The -replay convenience method returns a new signal that, when subscribed to, will immediately send the subscriber the entire history of values that have come through the source signal, without re-executing the source signal’s subscription code. The subscriber will still receive all future values from the signal just as it would from a normal signal.
The first example shows how the subscription code is not re-executed upon new subscriptions:
__block int num = 0;
RACSignal *signal = [[RACSignal createSignal:^RACDisposable *(id subscriber) {
num++;
NSLog(@"Increment num to: %i", num);
[subscriber sendNext:@(num)];
return nil;
}] replay];
NSLog(@"Start subscriptions");
// Subscriber 1 (S1)
[signal subscribeNext:^(id x) {
NSLog(@"S1: %@", x);
}];
// Subscriber 2 (S2)
[signal subscribeNext:^(id x) {
NSLog(@"S2: %@", x);
}];
// Subscriber 3 (S3)
[signal subscribeNext:^(id x) {
NSLog(@"S3: %@", x);
}];
Increment num to: 1
Start subscriptions
S1: 1
S2: 1
S3: 1
This time the num integer is incremented immediately, before there are even any subscribers. And it is only incremented once, meaning that the subscription code is only been executed a single time, regardless of how many subscribers the signal has.
The second example shows how each new subscriber receives the full history of the signal:
RACSubject *letters = [RACSubject subject];
RACSignal *signal = [letters replay];
NSLog(@"Subscribe S1");
[signal subscribeNext:^(id x) {
NSLog(@"S1: %@", x);
}];
NSLog(@"Send A");
[letters sendNext:@"A"];
NSLog(@"Send B");
[letters sendNext:@"B"];
NSLog(@"Subscribe S2");
[signal subscribeNext:^(id x) {
NSLog(@"S2: %@", x);
}];
NSLog(@"Send C");
[letters sendNext:@"C"];
NSLog(@"Send D");
[letters sendNext:@"D"];
NSLog(@"Subscribe S3");
[signal subscribeNext:^(id x) {
NSLog(@"S3: %@", x);
}];
Subscribe S1
Send A
S1: A
Send B
S1: B
Subscribe S2
S2: A
S2: B
Send C
S1: C
S2: C
Send D
S1: D
S2: D
Subscribe S3
S3: A
S3: B
S3: C
S3: D
Even though S3 subscribed after all of the values had been sent, it still received all of the values.
Subscribing to a -replayLast Signal
The -replayLast convenience method returns a new signal that, when subscribed to, will immediately send the subscriber the most recent value that comes through the source signal, without re-executing the source signal’s subscription code. The subscriber will then receive all future values from the signal just as it would from a normal signal.
For the first example, there is no difference between -replayLast and -replay so I won’t bother showing it again.
The second example illustrates how only the most recent value is provided to a new subscriber.
RACSubject *letters = [RACSubject subject];
RACSignal *signal = [letters replayLast];
NSLog(@"Subscribe S1");
[signal subscribeNext:^(id x) {
NSLog(@"S1: %@", x);
}];
NSLog(@"Send A");
[letters sendNext:@"A"];
NSLog(@"Send B");
[letters sendNext:@"B"];
NSLog(@"Subscribe S2");
[signal subscribeNext:^(id x) {
NSLog(@"S2: %@", x);
}];
NSLog(@"Send C");
[letters sendNext:@"C"];
NSLog(@"Send D");
[letters sendNext:@"D"];
NSLog(@"Subscribe S3");
[signal subscribeNext:^(id x) {
NSLog(@"S3: %@", x);
}];
Subscribe S1
Send A
S1: A
Send B
S1: B
Subscribe S2
S2: B
Send C
S1: C
S2: C
Send D
S1: D
S2: D
Subscribe S3
S3: D
Subscribing to a -replayLazily Signal
The -replayLazily convenience method returns a new signal that, when subscribed to, will immediately send the subscriber the entire history of values that have come through the source signal, without re-executing the source signal’s subscription code. The difference between -replayLazily and -replay is that -replayLazily will not subscribe to the source signal until something subscribes to the newly created signal. This is opposed to the behavior of -replay and -replayLast, which subscribe to the source signal immediately upon being called.
The first example illustrates this difference. Note how the “Increment num to: 1″ message does not appear until after the first subscription. With -replay (and -replayLast) the same message appears before the first subscription.
__block int num = 0;
RACSignal *signal = [[RACSignal createSignal:^RACDisposable *(id subscriber) {
num++;
NSLog(@"Increment num to: %i", num);
[subscriber sendNext:@(num)];
return nil;
}] replayLazily];
NSLog(@"Start subscriptions");
// Subscriber 1 (S1)
[signal subscribeNext:^(id x) {
NSLog(@"S1: %@", x);
}];
// Subscriber 2 (S2)
[signal subscribeNext:^(id x) {
NSLog(@"S2: %@", x);
}];
// Subscriber 3 (S3)
[signal subscribeNext:^(id x) {
NSLog(@"S3: %@", x);
}];
Start subscriptions
Increment num to: 1
S1: 1
S2: 1
S3: 1
And the second example shows that the full history is sent to any new subscribers, just like with -replay.
RACSubject *letters = [RACSubject subject];
RACSignal *signal = [letters replayLazily];
NSLog(@"Subscribe S1");
[signal subscribeNext:^(id x) {
NSLog(@"S1: %@", x);
}];
NSLog(@"Send A");
[letters sendNext:@"A"];
NSLog(@"Send B");
[letters sendNext:@"B"];
NSLog(@"Subscribe S2");
[signal subscribeNext:^(id x) {
NSLog(@"S2: %@", x);
}];
NSLog(@"Send C");
[letters sendNext:@"C"];
NSLog(@"Send D");
[letters sendNext:@"D"];
NSLog(@"Subscribe S3");
[signal subscribeNext:^(id x) {
NSLog(@"S3: %@", x);
}];
Subscribe S1
Send A
S1: A
Send B
S1: B
Subscribe S2
S2: A
S2: B
Send C
S1: C
S2: C
Send D
S1: D
S2: D
Subscribe S3
S3: A
S3: B
S3: C
S3: D
Summary
ReactiveCocoa provides three convenience methods for allowing multiple subscribers to the same signal, without re-executing the source signal’s subscription code, and to provide some level of historical values to later subscribers. -replay and -replayLast both make the signal hot, and will provide either all values (-replay) or the most recent (-replayLast) value to subscribers. -replayLazily returns a cold signal that will provide all of the signal’s values to subscribers.
Hi. There is quite unclear from your example, what the difference between replay and replayLazily.
Because images looks the same. Is it right, that the difference is:
If we execute [letters sendNext:@”A”];
BEFORE
[signal subscribeNext:^(id x) {
NSLog(@”S1: %@”, x);
}];
Then in replay example nothing is changed in output, and replayLazily will lost A value for all subscribers?
Petr,
Sorry for the confusion. Yes, you are correct. replayLazily does not subscribe to the signal immediately – it lazily waits until there is a “real” subscriber. But replay subscribes immediately. So as you point out, with replayLazily the “A” value would not be sent to subscribers of the signal because it was sent before there was anything listening.
Great! Thanks for explanation! This is hard-to-remind things in Reactive programming!
Help me a lot! Thanks!