if Kotlin's `fixedRateTimer` function appropriate and accurate enough to create a countdown timer? A...

# getting-started

[Florian]

if Kotlin's fixedRateTimer function appropriate and accurate enough to create a countdown timer? And is there any problem with launching a coroutine inside the timer action block?

fun startTimer() {
        timer?.cancel()
        applicationScope.launch {
            val selectedTask = selectedTask.first()
            if (selectedTask != null) {
                taskDao.updateLastActiveTimestamp(selectedTask.id, System.currentTimeMillis())
                startTimerService()
                timerRunningFlow.value = true
                timer = fixedRateTimer(period = TICK_DELAY) {
                    applicationScope.launch {
                        taskDao.increaseMillisCompletedToday(selectedTask.id, TICK_DELAY)
                    }
                }
            }
        }
    }

[ephemient]

kotlin.concurrent.fixedRateTimer uses java.util.Timer which uses java.lang.Object.wait whose precision varies by platform. how accurate does your countdown timer need to be?

[Florian]

@ephemient It's for a stopwatch, but let's say 5 seconds difference on 30 minutes would be bearable

[Florian]

is that within the range?

[Greg Hibberd]

Yes it's fine for a stopwatch, the precision Eph is talking about is at worst +/- 10ms.

[Florian]

Alright, thank you!

[Florian]

I actually had to remove timer because it went nuts when I change the date of the phone manually

[Florian]

do you know anything about this?

[Florian]

does it depend on clock time?

[ephemient]

assuming you're on Android?

[ephemient]

Timer effectively uses the realtime clock so yes, it'll behave poorly if the time is adjusted

[ephemient]

consider https://developer.android.com/reference/android/os/CountDownTimer instead

[Florian]

good to know, thank you!

[Florian]

I considered CountdownTimer, but counting downwards actually makes things more complicated for me

[Florian]

I'm now using coroutines + delay + calculating the elapsedTime difference to combat the imprecision of delay

[Florian]

seems to work fine