-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repeated signal with variable interval #1871
Comments
If the timer is never really meant to terminate, you could create a recursive method which runs In other words, insert delays of N seconds between an infinite series of your own signal. |
The timer can be terminated on user's command. And regarding the recursion - my CS might be rusty, but wouldn't that eventually create the stack frame overflow? |
@eimantas No, because the delay won't be synchronous. RAC will leave the frame and return to the code later after the delay has elapsed. |
I'm sorry, but I still don't get your idea .( specifically - on what should I call |
- (RACSignal *)doStuffRepeatedly {
return [[[RACSignal
defer:^{
// Do some stuff here
return [RACSignal empty];
}]
// Wait 5 seconds
concat:[RACSignal delay:5]]
then:^{
// Do more stuff
return [self doStuffRepeatedly];
}];
} |
Closing this due to inactivity. |
I have a PoC of a class using repeated signal with variable interval:
The usage would be following:
This allows me to keep the subscription and change only the interval of the delivery of signal values. I'm worried about the part that consumer must actually subscribe to the subject rather than to the signal. I understand this is not a common scenario and guidelines actually encourages avoiding subjects if possible. I tried exposing
dataSignal
in public interface and replacing the part marked with// *
as follows:But this would not work at all and only the initial value would get sent. Has anyone else tried implementing what I am trying to achieve here? I am confident RAC is capable of doing this and my PoC is just an ugly duckling that can be greatly improved.
The gist can be found here: https://gist.github.com/eimantas/51d9dfc81136f340a829
Update: based on @jspahrsummers answer to the question on stackoverflow: http://stackoverflow.com/questions/15075075/when-to-use-racreplaysubject-vs-racmulticastconnection
It seems that RACMulticastConnection is doing the same thing - exposing
RACSubject
asRACSignal
, so I guess I should do the same then?The text was updated successfully, but these errors were encountered: