I have a coroutine that runs in a loop and delays ...
# coroutines
c
I have a coroutine that runs in a loop and delays every 30 seconds before doing some work, but on some android devices it seems like it delays longer. like a minute or 2 before it triggers again. Any ideas?
c
possible that the work duration is exceeding the next delay? e.g. delay 30s, do 1.5m of work, delay 30s ---> 2m from work to work.
c
nope. the work happens "instantly". just logging something right now lol
Copy code
viewModelScope.launch {
      snapshotFlow { myChosenInterval }
          .collectLatest { interval ->
            while (true) {
              delay(interval)
              //log
            }
          }
    }
s
Does that happen even when the app is in the foreground?
And while the
viewModelScope
is alive and active?
c
viewModelScope is alive and active
i can't repro locally, but it seems to happen to my teammate if he just leaves his phone untouched on his desk
s
And his phone's screen locks (and goes to sleep)?
If so, the app is no longer in the foreground and may not get (enough) cpu time.
c
Nope. Phone screen stays on
I wonder if I should move this to a different dispatcher
maybe i should change the dispatcher
@streetsofboston do you know if I moved to using Threads instead if that would solve my problem? Or would I still have the possibility of the app not being allocated enough cpu cycles?
the only way i was able to repro was with turning the display off
s
Moving to a Thread won't help.
There's a lot of nuances on being able to run stuff in the background on Android. Too much for here in this thread (pun intended! 🙂). The developer.android.com documentations should help you
c
Yeah. I'm aware of the background siderations, services, foreground service, workmanager, etc. I was mostly just enlightened to the fact that even though my process is running, it would still be delayed.
i thought services etc helped when your activity was put in the background and workmanager when your process actually died. which in this case, I would have just expected for my process to get killed before my delay was throttled
u
Did you try logging timestamps before/after delay? Could it be, that snapshotFlow is juts not emitting for a while? I have never heard of such a thing as throttling in foreground and don’t think that exists. So looking for other ways this might fail
l
Is the app state resumed, with screen on?
c
I was able to repro it with screen off, and once I turned the screen back on everything started behaving normally.
l
That's just deep sleep… delay uses Handler.postDelayed, which is based on SystemClock.uptimeMillis
👍 1
You probably want to reschedule it every time the lifecycle goes back to the resumed state.
👍 1
What's your use case?
c
cool. TIL. My use case was to get it to happen during the app being foregrounded, but was investigating a report from QA. thanks all for teaching!
👍 1
c
I know WorkManager was setup for this kind of thing on Android, is there a similar WorkManager for iOS?
1
173 Views