0

What's the best way to save any changes to global state, that would be lost if the process was killed due to low memory etc?

For activities we have onSaveInstanceState() which allows state to be saved when needed.

I would like something similar for global state. Our Application class holds a references to many objects that can be simply reloaded in onCreate() when the app next starts. But we also change the state of some of those objects, and require these changes to be maintained through the app being killed due to low memory etc.

We could of course persist every time changes are made to the objects in memory. But this would be very wasteful.

My current thought is to use onActivitySaveInstanceState() and keep a dirty flag to know only to call it once. But this adds complexity and probably isn't what this method was intended for.

This cannot be a particularly uncommon requirement, but most of the resources on the net focus on just Activity lifecycle. I'd be pleased to learn of a better approach.

LordRaydenMK
  • 13,074
  • 5
  • 50
  • 56
Justin Caldicott
  • 739
  • 8
  • 22
  • There is no `onDestroy()` (or equivalent) for the application itself. The safe way would be persisting using `SharedPreferences` whenever needed. – matiash Jun 09 '14 at 14:24
  • Anyone facing similar issues can refer to: http://prismatic.github.io/android-state-saving/ – siddhant Dec 26 '15 at 06:28

2 Answers2

0

You can always store values in your Application class. On a high level, this is very simple, you create a custom MyCustomApplication, that extends the Android Application class. The Applicaiton class only lives, while the App is in scope (including when it's in the background, which is somewhat unpredictable in Android).

Then you would can access this using the getContext().getApplication()

The implementation details are more complex, and you really should extend the Applicaiton into a Singleton, as described in this SO post: Singletons vs. Application Context in Android?

Community
  • 1
  • 1
Booger
  • 18,579
  • 7
  • 55
  • 72
  • Thanks, but I'm fine with that. I'm asking how to handle save / restore of that state when the application is killed, as can happen in low memory situations. – Justin Caldicott Jun 09 '14 at 14:05
  • Ah, then use SharedPreferences or a Database - these are your only options if the app is killed. SharedPrefs are extremely easy to implement (basically a name/value DB, that is ready to use). – Booger Jun 09 '14 at 14:32
0

There is no concept of Global State and I actually think that you don't need it at all. An app consists of several independent parts which have their own "state". Thus each part is responsible for its own state. For instance, a fragment which shows particular data knows where to get this data and what to do if there is no such data. An activity which shows user settings knows where to get user settings, how to update it and so on. Both of these parts know what to do when lifecycle methods are calling.

eleven
  • 6,779
  • 2
  • 32
  • 52
  • 2
    We're storing cache and indexes at an application scope, as it would be expensive to create them for each activity. So I think global state or whatever we call it has a place. But I agree that it is best to keep Activities as independent as possible. Your answer led me to work out that it is possible for us to avoid mutable state (at least, where it is not immediately persisted) at the application scope and avoid this problem. Thanks. – Justin Caldicott Jun 09 '14 at 18:50