https://kotlinlang.org logo
#coroutines
Title
# coroutines
s

Sudhir Singh Khanger

06/01/2021, 1:28 PM
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.
m

mbonnin

06/01/2021, 5:47 PM
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.
e

Erik

06/01/2021, 6:53 PM
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).
e

ephemient

06/01/2021, 7:27 PM
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.
m

mbonnin

06/01/2021, 7:29 PM
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
But if the cleanup is "reasonably" short I guess the OS will allow it to run from the destroy() hooks?
e

Erik

06/01/2021, 7:33 PM
Also, consider moving this state to the viewmodel, so that you likely need to cleanup only in
ViewModel#onCleared
e

ephemient

06/01/2021, 7:33 PM
usually, yes… although you get no notification if your app is force-stopped
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
👍 1
e

Erik

06/01/2021, 7:35 PM
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....... 😉 )
e

ephemient

06/01/2021, 7:36 PM
very true! or the system is putting your app into a new doze bucket…
e

Erik

06/01/2021, 7:38 PM
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
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()
e

ephemient

06/01/2021, 7:41 PM
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…
1
e

Erik

06/01/2021, 7:42 PM
But that never receives a destroy event, because you're dead already 😉
So I find that I move my work to
onStop
or to the view model more often than using a process lifecycle owner
e

ephemient

06/01/2021, 7:50 PM
haha yep, no code runs in response to process destroy 🙂 but process lifecycle's onStop() does make an effort to run before process termination
e

Erik

06/01/2021, 7:52 PM
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
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