What are your views on using

runBlocking { //room db call }

in

onDestroy()

of an

Activity

to execute a task which must happen when the

Activity

is killed? I could use a

lifecycleScope

which wraps both the db call and

super.onDestroy()

but I was wondering if that might cause any adverse effects.

If you need your DB write to go through, which looks likely here, you can do the write in a larger scope than the activity scope, maybe create an Application Scope.

If the db work can be deferred, then use workmanager. Otherwise Martin's suggestion should work. But consider your app's state if the process is suddenly killed (e.g. dead system, battery pulled from device, or whatever catastrophic event for your app process).

yep. there are various "best-effort" approaches to cleaning up, such as workmanager or building your own service&broadcastreceiver. but there is no way to completely guarantee any of your code will be run in a timely fashion.

I mean even workmanager needs to serialize its parameters somewhere so if the app gets savagedly killed there's no guarantee than anything will run eventually

Also, consider moving this state to the viewmodel, so that you likely need to cleanup only in

ViewModel#onCleared

usually, yes… although you get no notification if your app is force-stopped

You don't even know your app will ever launch again. For all you know it's being uninstalled 😛 (the doom scenarios us mobile devs have to cope with sometimes....... 😉 )

very true! or the system is putting your app into a new doze bucket…

In any case, from experience, an application scope works. Admittedly, it still doesn't feel nice as it's just a form of the singleton (anti-)pattern

https://developer.android.com/reference/androidx/lifecycle/ProcessLifecycleOwner may feel a bit better than relying on Application scope. either way, as log as you keep in mind that this is best-effort, not guaranteed…

But that never receives a destroy event, because you're dead already 😉

haha yep, no code runs in response to process destroy 🙂 but process lifecycle's onStop() does make an effort to run before process termination

Also when simply switching apps, e.g. when going home or when receiving a call. It might not fit a specific use case to save on destroy