Difference Between Getdefaultsharedpreferences and Getsharedpreferences

PreferenceManager.getDefaultSharedPreferences() vs getPreferences()

From android github repo(1), we can see that getPreferences does nothing other than invoking getSharedPreferences method with current class name.

public SharedPreferences getPreferences( int mode ) {
    return getSharedPreferences( getLocalClassName(), mode );
}

There is nothing limiting other activities/code from accessing the shared preference with appropriate class name. More importantly, I prefer not to use getPreferences, since that implies => never ever change the Activity name. If you change, then take care of the accessing shared preferences with explicit mentions to the earlier class name ( before upgrade ).

Android getDefaultSharedPreferences

Try it this way:

final String eulaKey = "mykey";
Context mContext = getApplicationContext();
mPrefs = mContext.getSharedPreferences("myAppPrefs", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = mPrefs.edit();
editor.putBoolean(eulaKey, true);
editor.commit();

in which case you can specify your own preferences file name (myAppPrefs) and can control access persmission to it. Other operating modes include:

• MODE_WORLD_READABLE
• MODE_WORLD_WRITEABLE
• MODE_MULTI_PROCESS

One can use getDefaultSharedPreferences and getSharedPreferences(nome,mode) in the same app?

If I do that, there's any chance of one cause interference on another?

no there is not such a thing. They are stored in two different xml files (unless you are so lucky to guess the default name, context.getPackageName() + "_preferences").

Shared Preferences differences

1) You can have multiple SharedPreference files (so they are called SharedPreferences). The argument name of method getSharedPreferences(name, mode) specifies the the name of SharedPreference file to handle.

PreferenceManager.getDefaultSharedPreferences(context) returns the default SharedPreference file having default name and mode. Default name is based on your app's package name (as packagename_preferences.xml) and default mode is MODE_PRIVATE.

If you just want to use a single SharedPreferences file, PreferenceManager.getDefaultSharedPreferences(context) is concise to use.

2) With SharedPreferences you can save some key-value data.

3) Your last question: how to make a setting screen? is too wide topic to answer here. However, I suggest that using PreferenceActivity or PreferenceFragment you can manage a SharedPreferences without handling SharedPreferences directly.

Showing values which is put in sharedpreferences are not showing in textView

You are creating two sharedPreferences xml files in Your app directory. The default one is the standard preferences xml, the other one which you have created with

sharedPreferences = getSharedPreferences("Mypreferences", Context.MODE_PRIVATE);

will store your prefs inside a Mypreferences.xml. MODE_PRIVATE means, that this preferences are only available for your app (but on a rooted device, everybody can access).

If you want to access your saved sharedPreferences, you have to use the same preferences that you have used to save them. That means either you have to use everywhere you are accessing the same keys:

sharedPreferences = getSharedPreferences("Mypreferences", Context.MODE_PRIVATE);

or

sharedPreferences = PreferenceManager.getDefaultSharedPreferences(MainActivity.this);

not both. In Your button_show click method, you don´t have to create a new sharedPreferences object, just delete this line:

SharedPreferences sharedPreferences = PreferenceManager.getDefaultSharedPreferences(MainActivity.this);

because you have generated a global sharedPreferences object and can access it everywhere in your class.

Mess with the shared preferences of android - which function to use?

Here's the answer to my own question:

First, let's take a look at the implementations of those 3 functions.

//1.
public static SharedPreferences PreferenceManager.getDefaultSharedPreferences(Context context) {
    return context.getSharedPreferences(getDefaultSharedPreferencesName(context), getDefaultSharedPreferencesMode());
}

//2.
public SharedPreferences Activity.getPreferences(int mode) {
    return getSharedPreferences(getLocalClassName(), mode);
}

//3.
public SharedPreferences ContextWrapper.getSharedPreferences(String name, int mode) {
    return mBase.getSharedPreferences(name, mode);
}

Here mBase is a reference to an object of type Context.

We see that the 2nd functions calls the 3rd one, and all those 3 functions are basically equivalent but with different parameters. Think of overloading.

Next, going deeper to the 1st function's implementation, we can simplify its call as the following:

//1.
public static SharedPreferences PreferenceManager.getDefaultSharedPreferences(Context context) {
    return context.getSharedPreferences(context.getPackageName() +
        "_preferences", Context.MODE_PRIVATE);
}

and similarly, for the second function:

//2.
public SharedPreferences Activity.getPreferences(int mode) {
    return mBase.getSharedPreferences(getLocalClassName(), mode);
}

To sum-up, the 1st function creates a shared preference file with a name as <your_package_name>_preferences, the 2nd function creates a shared preference file with a name as <your_class_name>, and finally, the 3rd function lets you to specify arbitrary name for the shared preference file.

Needless to say that you need to specify the correct name for the shared preference file in order to retrieve the saved values back. So you may use the 3rd function to specify the name yourself or to use the 1st or 2nd function respective to how you have saved it before.

Warning! Make sure you are passing the correct instance of the Context class.
For example, a messy scenario would look like this: you are saving into shared preferences from a background thread which is running in the system (like for example when using the android's out-of-the-box SyncAdapter framework) and trying to get back the saved values from your UI-thread, you may get the default/wrong values!

Hope this will be helpful for someone else... ;)

---

Related Topics