Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
`tickerFlow` implementation #1908
Conversation
testZeroInitialDelay added to test 0 initialDelay. testDoNotReceiveAfterCancel testcase fixed.
*/ | ||
public fun tickerFlow( | ||
period: Long, | ||
initialDelay: Long = period |
joffrey-bion
May 13, 2020
Contributor
To follow the example of functions like withTimeout
and debounce
, I think we should add the Millis
suffix to these parameter names, and maybe provide an overload using kotlin.time.Duration
?
ibrahimyilmaz
May 13, 2020
Author
Good point for naming and we have .receiveAsFlow()
extension function.
Directly we can use kotlinx-coroutine's ticker
. Also this can be better idea to have single implementation.
What do you think about it?
joffrey-bion
May 15, 2020
•
Contributor
It could indeed be done this way, but that would couple it to JVM platform
I am not sure a channel would be necessary behind the scenes to implement it, but I will let the maintainers comment on this.
EDIT: moved part of this comment to the relevant conversation
val timer = Timer() | ||
timer.schedule(initialDelay, period) { | ||
offer(Unit) | ||
} |
joffrey-bion
May 13, 2020
•
Contributor
This implementation uses a background thread and is JVM-specific.
Couldn't we simply use a loop with delay()
and make it multiplatform? Or am I naive here?
I fail to see the benefit of running another thread here.
ibrahimyilmaz
May 13, 2020
Author
Thanks! very good point.
Also ticker
implementation can be moved to commonMain
.
joffrey-bion
May 19, 2020
Contributor
I can see now why a concurrent behaviour is necessary and would like to backtrack a bit: we can't use a simple loop with delays because otherwise the ticker delay is impacted by the execution time of the collector code, which is probably not desirable in this case.
That's why we do need some concurrent process (a coroutine?) to send the ticks.
This still doesn't mean we have to use a thread and Java's timer.
There may be a multiplatform way to do this.
I'll let the maintainers of the lib comment on this, though
… receiveAsFlow extension function.
mode: TickerMode = TickerMode.FIXED_PERIOD | ||
): Flow<Unit> { | ||
require(delayMillis > 0) | ||
return ticker(delayMillis, initialDelayMillis, context, mode).receiveAsFlow() |
joffrey-bion
May 19, 2020
Contributor
Because the channel is hidden here, we probably want to handle cancellation properly.
Using consumeAsFlow()
instead of receiveAsFlow()
should do the trick I think.
This pull request contains basic implementation of the ticker with Flow.
I have seen this issue(#540) maybe this can contribute to that issue(plan)