SharedPreferences - Android

Question

I have a little doubt about the SharedPreferences in Android .

To delete a preference, we mainly have two options:

First:

SharedPreferences.Editor edit = (Editor) getSharedPreferences(Constants.APP_DEFAULT_PREF, MODE_PRIVATE).edit();
edit.putString(Constants.PREF_ACC, null);
edit.commit();

Second:

SharedPreferences.Editor edit = (Editor) getSharedPreferences(Constants.APP_DEFAULT_PREF, MODE_PRIVATE).edit();
edit.remove(Constants.PREF_ACC);
edit.commit();

In either case, fetching Constants.PREF_ACC value from SharedPreferences will return null .

I was wondering which one should I prefer. Is there any memory related issues in either of them? What will the System.gc behavior be with them?

Answer 1

Theoretically remove is better than put(null) , because it removes both the key and value (once committed) instead of mapping (and keeping) the key to a null value.

But judging by the Android 5.1.1 implementation , they are equivalent :

    ...
    String k = e.getKey();
    Object v = e.getValue();
    // "this" is the magic value for a removal mutation. In addition,
    // setting a value to "null" for a given key is specified to be
    // equivalent to calling remove on that key.
    if (v == this || v == null) {
        if (!mMap.containsKey(k)) {
            continue;
        }
        mMap.remove(k);
    } else {
    ...

That is also what one of the putXXX methods ( putStringSet ) documentation says :

Passing null for this argument is equivalent to calling remove(String) with this key.

Answer 2

I would recommend using remove .

When we putString or remove nothing is done, it is just marked in the Editor as TO BE DONE and gets done only when commit is called And when the commit is called all the remove calls are executed before the put calls. So it is better to use the remove calls to remove something from the Editor.

Answer 3

Judging by the docs of the interface SharedPreferences.Editor for remove(String) :

Mark in the editor that a preference value should be removed, which will be done in the actual preferences once commit() is called.

Note that when committing back to the preferences, all removals are done first, regardless of whether you called remove before or after put methods on this editor.

… and for putInt(int) :

Set an int value in the preferences editor, to be written back once commit() or apply() are called.

… there seem to be only one striking difference: remove(String) calls will be "done first, regardless of whether you called remove before or after put methods" .

That said, I really doubt the actual order of execution won't matter much to average use-cases, so you could just choose either one of those methods and be completely fine.

ps , I'm still looking for the concrete class of SharedPreferences.Editor which might provide more clues about this. Will update as soon as I found one.