You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
@PreferenceChange minor parameter related changes #1394
You are supporting a Boolean parameter on the @PreferenceChange annotation (but not mentioned in documentation), and you are not supporting a
Set<String>
parameter (but is reported in the documentation, you probably only meant to say that Set is supported) Finally the Long parameter is not supported (and correctly not reported in the documentation).
Maybe while you are at it you can also change @SharedPref to support Double, and also make @PreferenceChange support doubles?
These are not longs, these are strings. You will have a String object as the newValue parameter. Looking at the code, ListPreference is only capable of storing Strings actually.
Our @SharedPref only works for you because we parse the string to a long (#503). Maybe we should do it here, too (it is little bit more compliated then in SharedPref)?
@PreferenceChangevoidmyPreferenceChanged(Integervalue) {
// TODO
}
if (newValueinstaceofString) {
intvalue = Integer.parseInt(newValue);
myPreferenceChanged(preference, value)
// this will throw a `NumberFormatException` if the String does not store an int, that is OK
} elseif (newValueinstaceOfInteger) {
myPreferenceChanged(preference, (Integer) value)
} else {
thrownewNumberFormatException("only can convert strings to numbers")
}
This ugly snippet is only generated if the parameter type is Integer, Float, Double or Long.
will be never used with the android default Preference class implementations. I am not sure we should prepare for other ones, since they could use any type.
Activity
WonderCsabo commentedon May 4, 2015
What
Preferenceuses aLongvalue? I quickly read throught thePreferencesubclasses in theandroid.preferencepackage:EditTextPreference:StringListPreference:StringMultiSelectListPreference:Set<String>CheckBoxPreference:BooleanOf course one could use other subclasses from libraries or own code, which use different values.
athkalia commentedon May 4, 2015
I am always keeping in mind your @SharedPref annotation.
In my implementation I have linked a ListPreference to have longs and store it:
@SharedPref(value = SharedPref.Scope.UNIQUE)
public interface Settings {
}
and the xml:
and the 2 arrays:
WonderCsabo commentedon May 4, 2015
These are not longs, these are strings. You will have a
Stringobject as thenewValueparameter. Looking at the code,ListPreferenceis only capable of storingStrings actually.Our
@SharedPrefonly works for you because we parse the string to a long (#503). Maybe we should do it here, too (it is little bit more compliated then inSharedPref)?athkalia commentedon May 4, 2015
Ah, I just noticed now that you mentioned it. Well it wouldn't be too bad to have unless it's difficult to implement
WonderCsabo commentedon May 4, 2015
OK, i can think of this generated code:
This ugly snippet is only generated if the parameter type is
Integer,Float,DoubleorLong.WonderCsabo commentedon May 4, 2015
OK, actually this branch
else if (newValue instaceOf Integer) {will be never used with the android default
Preferenceclass implementations. I am not sure we should prepare for other ones, since they could use any type.WonderCsabo commentedon May 9, 2015
Fixed.