What are your views on using `runBlocking { //room db call }` in `onDestroy()` of an `Activity` to e...

# coroutines

[Sudhir Singh Khanger]

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.

[mbonnin]

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.

[Erik]

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).

[ephemient]

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.

[mbonnin]

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

[mbonnin]

But if the cleanup is "reasonably" short I guess the OS will allow it to run from the destroy() hooks?

[Erik]

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

[ephemient]

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

[ephemient]

if you really need to, you could try to detect on the next app launch if that has happened, but… best not to rely on it

[Erik]

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....... 😉 )

[ephemient]

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

[Erik]

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

[Erik]

Also note about `Activity#onDestroy`:

Note: do not count on this method being called as a place for saving data!

https://developer.android.com/reference/android/app/Activity#onDestroy()

[ephemient]

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…

[Erik]

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

[Erik]

So I find that I move my work to onStop or to the view model more often than using a process lifecycle owner

[ephemient]

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

[Erik]

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

[Erik]

Note that configuration change, e.g. rotation, also destroys activities but keeps view models, so likewise, moving to a view model might not fit all use cases either