Reading from SharedPreferences vs. keeping an instance of the object

Question

THE SCENARIO

I have a class that makes use of a request list set by the user. The request list is stored in SharedPreferences. The dilemma I'm facing is to whether to keep an instance of the request list or to read from SharedPreferences every time the request list is needed (which is very frequent).

Also not that Gson is used to deserialize the object.

The code goes like this:

public List<PrayerTimesCalculator.Time> getDefaultRequestList() {
    if (mRequestList != null) return mRequestList;
    // Try getting request list from preferences;
    Gson gson = new Gson();
    String json = mSharedPref.getString(KEY_PREF_REQUEST_LIST, null);
    Type listType = new TypeToken<List<Time>>() {
    }.getType();
    mRequestList = gson.fromJson(json, listType);
    if (mRequestList != null) return mRequestList;
    // Create default list;
    mRequestList = Arrays.asList(
           Time.DAWN,
           Time.MORNING,
           Time.AFTERNOON,
           Time.EVENING,
           Time.MID_NIGHT);
    return mRequestList;
}

THE GOAL

My concern is that if I keep around an instance of the request list, and there are multiple instances of this class, an update to the request list in one instance of the class would not be reflected in the rest of the instances until they are recreated.

Thus, I'm leaning towards reading from SharedPreferences unless there is a better way to keep the request list objected updated in all instances.

THE QUESTION

(1) So, how efficient is it to read the same key from SharedPreferences quite frequently by multiple instances of the object? and (2) Is there a better way to keep the request list objected updated in all instances?

Answer 1

So there are a couple of approaches you can take to this.

First, your object is small - re-reading SharedPreferences thousands of times would hardly be noticeable. It's not like SharedPreferences is on a remote drive or has a "bad connection."

Second, if you don't like that answer, then you need a DAO (Data Access Object). SharedPreferences is a form of this already. It provides a means to store and retrieve data with confidence that you have the most recent data available. But, if you feel like you can improve on it's optimization (because it's generic, and this is your app), then you can provide access to you data through a static object that performs both "read" and "write" operations. This will guarantee that access to the object is done with the most recent data. Of course, you will need to be thread aware, etc. (something that is not always guaranteed by SharedPreferences).

Next, you could persist your data in a database and use Cursors or other built-in or custom DAOs. This requires another level of complexity and a lot of overhead, but is useful when several components of your app might need access to the data, provide updates or needs real-time monitoring of changes because background threads or other objects may make modifications that will change your app behavior or result in UI updates.

Last, you could use more complex data stores like a Content Provider. This is really required for cases where you want/need other apps to access data provided by your app (and your app may also consume the data). That's a complex solution and implementation is well outside the scope of this question.

But I mention it because you seem interested in being certain that frequent reads of SharedPreferences is acceptable. It definitely is acceptable - otherwise there would be something else besides it, databases and Content Providers.