0

I am working with an android app and am looking for a way to establish some global preferences that will be later accessible to all all activities/classes in my app. This is similar to what i know some people end up using the AppDelegate in objective c programming. The answers i have seen on the net suggest that i either extend from Application or save the data to SharedPreferences. I would like to know if there is a way to combine the two approches so that in my app, i can keep calling properties of a Preferences object (such as Preferences.getName()) and also persist the data to SharedPreferences so that, in case Android decides to restart my application and i loose all the data in my Preferences object, i can still get it back from SharedPreferences and repopulate the Preferences object. Can anyone please let me know how this can be done and if it is viable?

Pavel Dudka
  • 20,754
  • 7
  • 70
  • 83
John Baum
  • 3,183
  • 11
  • 42
  • 90

1 Answers1

2

See my answer at https://stackoverflow.com/a/13673178/338479

In short, I create a "singleton" class to hold my preferences, and the data persists as long as the application stays in memory. If the application is killed by the system, the singleton class silently reloads it later.

It's also possible to do this by extending Application class, but conventional wisdom holds that there's no real advantage to doing it this way.

Community
  • 1
  • 1
Edward Falk
  • 9,991
  • 11
  • 77
  • 112
  • Just a couple of quick questions on your approach. What is the use of volatile and synchronized keywords? Also, could i perhaps merge the writing to the sharedPreferences in this pref object as well? So whenever i instantiate the object, i fill up its fields, persist to sharedPreferences. Can i accomplish this by method overloads? Having a method of getting the instance without the context means i will save to file. Another method with a context parameter means i will instantiate from sharedPreferences? Dont know if i am making sense :) – John Baum May 21 '13 at 23:54
  • Do a search on "Singleton Pattern", and your questions will be answered in detail, but the short answer is that by using them, you allow multiple threads to access the same object at all times, without danger of corruption or accidentally creating more than one instance. – Edward Falk May 21 '13 at 23:58
  • As far as writing to sharedPreference, that's exactly what I did in the app I took that source code from (I simplified it for my post). Or are you suggesting subclassing SharedPreferences? I never thought about that, but it might work. – Edward Falk May 22 '13 at 00:00
  • In your app, where did you write to SharedPref? I am not too sure if i am able to do this, but i was talking about having two getPrefs() methods, one with context as a parameter and another that will be used in my app to construct the singleton for the very first time and use that to dump my object into sharedPreferences. I am just thinking of merging the reading and writing to sharedPreferences into one singleton object so when i instantiate it for the first time ever, it will write to sharedPreferences and when the app reloads the singleton, repopulate from sharedPref – John Baum May 22 '13 at 00:11
  • Well, you could certainly write two **getPrefs()** methods -- one that accepts a context and reads from shared preferences, and one that takes no arguments and just initializes all fields with default values. The Prefs object could then be used to hold any persistent data you want, and optionally be written back to SharedPreferences later. At this point, I leave it as an exercise for the reader. – Edward Falk May 22 '13 at 00:18