Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As the documentation states:</p> <blockquote> <p>Parameters</p> <p>key The name of the preference to retrieve. defValue Value to return if this preference does not exist. </p> <p>Returns the preference value if it exists, or defValue. Throws ClassCastException if there is a preference with this name that is not an int.</p> </blockquote> <p>If the documentation is to be believed then the preference doesn't exist at all, you can test this by making your <code>getInt</code> values different to your values in your xml, if it is returning your <code>getInt</code> values you know the preferences don't exist.</p> <p>In the above case your preferences must be being removed or weren't set up properly in the first place, this seems quite unlikely though.</p> <p>Another thing you could look at is are you calling <code>commit</code> when you update your preferences or are your preferences being updated.</p> <p>You could also try playing with the modes when you set up your preference, try <code>MODE_MULTI_PROCESS</code> as the broad cast receiver is a separate process and presumably you are setting the preferences elsewhere and also try 'MODE_WORLD_WRITEABLE'.</p> <p><strong>UPDATE</strong> from comments</p> <p>Firstly, the code is a little confusing I guess because I can't see it all but you can't copy the whole project here so I will have to live with that.</p> <p>This is how I understand the problem: You are setting these values in your preference and you can call <code>getInt</code> on these preferences at one point and it's correct, then after a certain event (perhaps triggered by going on stand by) you call <code>getInt</code> again and the preference is back at the default as specified in the preference.xml and not the default value passed when calling <code>getInt</code> (as this would suggest the preference doesn't exist).</p> <p>I notice you are copying values to these ExampleWidgetProvider.* variables, are you certain that these aren't the correct values you are retrieving as preferences and whatever values exist in the preferences are never set correctly. I fail to see the point in having these variables as you are required to synchronize them when you change either one. If they are part of a work around then they should be removed so they don't convolute the original problem. </p> <p>As I am sure you know; if you restart the app the preferences should be the same as before the restart as the preference values are persisted (presuming you have them configured correctly) and as it says in the documentation:</p> <blockquote> <p><strong>android:defaultValue</strong> The default value for the preference, which will be set either if persistence is off or persistence is on and the preference is not found in the persistent storage.</p> </blockquote> <p>Which suggests that the preference is not getting reset to the original value but rather it doesn't exist for what ever reason (if it's this particular default value which keeps reappearing).</p> <p>There exists the method <code>setDefaultValues(Context context, int resId, boolean readAgain=true)</code> but you said you aren't calling that. So it seems unlikely that the preference is getting reset but rather it is removed or never existed in the first place.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload