0

I've seen in some places that it is okay (or even advisable) to persist data in the onPause() method.

Like here

https://stackoverflow.com/a/41778266/3913107

and here

https://stackoverflow.com/a/29496430/3913107

However, the documentation states:

onPause() execution is very brief, and does not necessarily afford enough time to perform save operations. For this reason, you should not use onPause() to save application or user data, make network calls, or execute database transactions; such work may not complete before the method completes. Instead, you should perform heavy-load shutdown operations during onStop()

https://developer.android.com/guide/components/activities/activity-lifecycle#onpause

What am I missing?

Gabriel Moretti
  • 676
  • 8
  • 23
  • 1
    If you're developing with MVVM your viewmodel / model layer should not be lifecycle aware anyway. Best practice is to store persistent data as soon as possible so it's not lost in case your app process is suddenly killed. – Pawel May 22 '21 at 00:59
  • @Pawel That opinion is a little naive. First off- MVVM is not always the best pattern, and only a minority of apps use it. Secondly, writing the model to storage constantly will result in a ton of writes that can become a performance bottleneck. Also, constantly writing to flash storage will hasten the failure of the storage device. If you're writing it with every change to a view model, you're probably doing it wrong. – Gabe Sechan May 22 '21 at 01:04
  • @GabeSechan In most cases "persisting data" comes down to just writing (incremental) updates to the database that result from user interaction so ideally you want them stored ASAP. That won't really cause any bottle neck or extensive storage wear unless queries are really naive (like writing thousands of records every time). Only in some more uncommon cases (like editing a file) I'd consider periodic saving w/ extra save trigger during `onPause`. – Pawel May 22 '21 at 10:32
  • @Pawel And I'd consider anyone doing that on every update extremely wasteful of resources and computing time., I'd reject a code review that did that. I'd even consider it wrong in a lot of cases- for example if the data is a user form, saving it before the user tells you to could lead to inconsistent or incorrect data. I'd say that your approach should almost never be done. A user should do something to enact a save in almost all cases, even if that's just hitting the back button to say they're finished. – Gabe Sechan May 22 '21 at 14:38
  • 2
    @GabeSechan at this point we're just arguing what is an "update" - if anything that's OP looking for universal answer which cannot be provided without at least a bit of context on what he's trying to persist. My point was not to rely solely on lifecycle methods (ideally don't rely on them at all) because it will lead to loss of data if application crashes or is otherwise interrupted. – Pawel May 22 '21 at 15:03
  • 1
    @Pawel And my point is DO rely on lifecycle methods, don't do what you said. In the general case, there may be specific tikmes where that is ok. And really, the only risk of data loss is in the case of a crash. Which if you have decent testing in place, should happen so infrequently it shouldn't concern you. – Gabe Sechan May 22 '21 at 21:47

1 Answers1

2

So that documentation is a little dated. For example it says not to do networking in onPause- you can't anyway. Networking needs to be on a thread other than the main thread, and onPause is always called on the main thread. You could send off a request to another thread to do networking, but that isn't a problem no matter where you do it.

The tradeoffs between doing it in onPause and onStart is when its called. onPause is called when the Activity is no longer foreground. onStop is called when the activity is totally off screen. So onPause will be called in a few situations without calling onStop. This makes me prefer onPause.

The real lesson is that both onPause and onStop should be fast. Don't do a lot of work in either. If you need to do something that isn't quick, do it on another thread. Of course that goes for pretty much everything on the main thread- if it isn't quick, do it somewhere else.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127