13

There's applications I'd like to write where I'd like some things to occur on a schedule.

Polling a URL for updates every few minutes seems to be a fairly common use case. In this particular case, though, I'm just trying to implement a clock.

This works:

@Composable
fun App() {
    var ticks by remember { mutableStateOf(0) }

    // Not 100% happy about this unused variable either
    val timer = remember {
        Timer().apply {
            val task = object : TimerTask() {
                override fun run() {
                    ticks++
                }
            }
            scheduleAtFixedRate(task, 1000L, 1000L)
        }
    }

    MaterialTheme {
        Text(
            // A real application would format this number properly,
            // but that's a different question
            text = "$ticks"
        )
    }
}

But I had to import java.util.Timer, so it's not going to be portable.

Jetpack Compose can do animation, so it surely has its own timer somewhere, implying there should be some portable way to do this as well, but I can't seem to figure it out.

Is there a cross-platform way to get a timer for this purpose?

Hakanai
  • 12,010
  • 10
  • 62
  • 132
  • I should also throw in that I have found existing questions here asking how to implement a timer in Jetpack Compose, but the answer involved using an Android-specific class, which embeds this exact same problem. – Hakanai Feb 20 '22 at 04:20

3 Answers3

32

In Compose you can use LaunchedEffect - it's a side effect which is run on a coroutine scope, so you can use delay inside, like this:

var ticks by remember { mutableStateOf(0) }
LaunchedEffect(Unit) {
    while(true) {
        delay(1.seconds)
        ticks++
    }
}
Phil Dukhov
  • 67,741
  • 15
  • 184
  • 220
  • That's an interesting solution to the problem. Obviously calculating the actual delay is nontrivial, but it does give me an idea of how I could scaffold up a useful timer class. – Hakanai Feb 20 '22 at 06:37
  • @Hakanai what exactly do you need to calculate? I don't know Timer well enough, but `scheduleAtFixedRate` seems running once a second in your example just like in mine – Phil Dukhov Feb 20 '22 at 07:10
  • @Hakanai if you need to sync it with time seconds, it's pretty easy: `delay(1000 - Date().time % 1000)` – Phil Dukhov Feb 20 '22 at 07:41
  • Well, I think I have to avoid `Date()` as well but I'm not entirely sure. What I might have to do is make my own multiplatform function to get the time. Or, pull in the entirety of kotlinx-datetime just to get the time, and then use `delay(1.seconds - Clock.System.now().nanosecondsOfSecond.nanoseconds)`. – Hakanai Feb 20 '22 at 09:23
  • How to restart the timer. I need on the OTP page. Resending code. – Sardorbek Muhammadjonov Nov 28 '22 at 08:09
  • 4
    @SardorbekMuhammadjonov you can reset launched effect using `key` parameter, e.g. something like [this](https://gist.github.com/PhilipDukhov/685d121ba9be64827465e50a720b61b7) – Phil Dukhov Nov 28 '22 at 09:28
3

I just wanted to share an alternative I have experimented with in case someone else thinks of it and encounters the same issues I have. Here is the naive implementation:

@Composable
fun Countdown(targetTime: Long, content: @Composable (remainingTime: Long) -> Unit) {
    var remainingTime by remember(targetTime) {
        mutableStateOf(targetTime - System.currentTimeMillis())
    }

    content.invoke(remainingTime)

    LaunchedEffect(remainingTime) {
        delay(1_000L)
        remainingTime = targetTime - System.currentTimeMillis()
    }
}

Assuming you want a precission of up to a second, this snippet will cause the LaunchedEffect to update a second after remainingTime is updated, updating remainingTime in relation with the current time in milliseconds. This basically creates a loop. Wrapping this logic in a @Composable is good as it prevents the excessive re-composition this would cause if you embedded your LaunchedEffect in a large component tree.

This works, but there is a catch: you will eventually notice your timer is skipping seconds. This happens because there will be some extra delay between the assignment of a new value to the remainingTime variable and the re-execution of LaunchedEffect which will essentially mean there is more than a second between updates.

Here is an improved implementation of the above:

@Composable
fun Countdown(targetTime: Long, content: @Composable (remainingTime: Long) -> Unit) {
    var remainingTime by remember(targetTime) {
        mutableStateOf(targetTime - System.currentTimeMillis())
    }

    content.invoke(remainingTime)

    LaunchedEffect(remainingTime) {
        val diff = remainingTime - (targetTime - System.currentTimeMillis())
        delay(1_000L - diff)
        remainingTime = targetTime - System.currentTimeMillis()
    }
}

We simply subtract the time it took for LaunchedEffect to re-execute from the intended delay time. This will avoid your timer skipping seconds.

The extra delay should not be an issue for the implementation in the accepted answer. The only advantage of this approach I noticed is that the loop will stop running once we navigate away from the screen. In my tests, the while loop with a true condition kept running when navigating to another Activity.

argenkiwi
  • 2,134
  • 1
  • 23
  • 26
1
@Composable
fun TimerTicks(
    initTick: Long = 1_000L,
    interval: Long = 1_000L,
    content: @Composable (tickTime: Long) -> Unit
) {

    var ticks by remember(initTick) {
        mutableStateOf(initTick)
    }

    content.invoke(ticks)

    LaunchedEffect(ticks) {
        val diff = ticks + interval
        delay(interval)
        ticks = diff
    }
}