Repository navigation
Better handling of float/integer in preferences #503
Description
Activity
Meanwhile, one solution would be to use customized preference editors.
Like EditFloatPreference
Here's a sample :
<PATH_TO_NAMESPACE.EditFloatPreference android:key="listMaxSpeed" android:numeric="decimal" android:title="Max speed for list" />Note : more information about android:numeric
Or even fancier, a sliding preference editor or other SeekBarPreference...
Could you please tell us what your patch would do ? AFAIK SharedPreferences API doesn't allow type checking.
Well the patch would be something pretty basic, like this:
public float getOr(float defaultValue) { try{ return sharedPreferences.getFloat(key, defaultValue); }catch( ClassCastException e ){ // The pref could be a String, if that is the case try this // recovery bit try{ String value = sharedPreferences.getString(key, ""+defaultValue); float result = Float.parseFloat(value); return result ; }catch( Exception e2){ // our recovery bit failed. The problem is elsewhere. Send the original error throw e ; } } }(I hope this makes sense as I am not in front of compiler)
And the same for the
integer.I updated to doc to show how to use the prefs with a
PreferenceActivityhttps://github.com/PerfectCarl/androidannotations/wiki/SharedPreferencesHelpers
So the heart and soul of this issue is to have the
@Prefsclass and theEditTextPreferencecoexist nicely for numeric values (int, long and float).The issue is: the EditTextPreference reads and writes a string, while the typesafe
@Prefuses the real numeric type.So even if the classCastException is handled in the Prefs's side, EditTextPreference will crash with another ClassCastException.
Falling from Charybdis to Scylla
So there two solutions here:
@Prefwriting the data as strings and converting them to the "real type" at each call- Giving up on
EditTextPreferenceand using a better suited replacement (as mentionned in my first post). The UI to input number is pretty terrible to begin with.
I think that 2) makes more sense. Maybe adding documentation on how to use
@Prefwith aPreferenceActivitywould be a good idea...
In that regard, theClassCastExceptionis worth fixing even if the application will break when the@Prefattempts to write those number values.
At least, we went from an issue happening on read/write cases to one that happens only when writing.As I said, from Charybdis to Scylla...
Hello,
I'm using the @PREF annotations along with PreferenceFragment so that the built-in preference UI can publish my AA generated preferences.
It works great with string/checkbox pref (edited with :
EditTextPreference/CheckBoxPreference), but there is an issue with a number (int or float).I use a this declaration to publish my float preference :
When I update the value and try to use it with the
Pref_class, I get this error :The reason is
EditTextPreferenceconvert the value to string which is not very smart.Of course, the
Pref_class expects a float (and rightfully so).Would it possible to add this use case when doing :
... and add a conversion from string to float if the value has been converted to a string by the (stupid) preference UI ?
Note : I can provide a patch (and tests).