@PreferenceChange more parameter types #1399
Conversation
[maven-release-plugin] copy for tag androidannotations-3.3
WonderCsabo
force-pushed
the
1394_preferenceChangeMoreParameterTypes
branch
2 times, most recently
from
a0dfe62
to
13fdd1f
Compare
| @@ -42,8 +42,13 @@ | |||
| * <li>A {@link android.preference.Preference Preference} parameter to know | |||
| * which preference was targeted by this event</li> | |||
| * <li>An {@link Object} or {@link java.util.Set Set of strings} or | |||
| * {@link Boolean} or {@link String} to obtain the new value of the | |||
| * {@link android.preference.Preference Preference}</li> | |||
| * {@link Boolean} or {@link Float} or {@link Integer} or {@link Long} or | |||
There was a problem hiding this comment.
not sure how it is in english, but in german we would comma seperate the words but the last. also personally i would change the order a little bit
An Object, String, Set of Strings and also Boolean, Float, Integer, Long or thier corresponding primitive types
There was a problem hiding this comment.
+1 for separating with commas and for the order.
WonderCsabo
force-pushed
the
1394_preferenceChangeMoreParameterTypes
branch
from
13fdd1f
to
bc688e0
Compare
|
Thanks for the suggestion on the JavaDoc, updated. |
|
I just realized i used the new parameter validator API, but it is not available in the master branch we are merging this back. I will change this to only be on top of master and not develop. |
WonderCsabo
force-pushed
the
1394_preferenceChangeMoreParameterTypes
branch
from
bc688e0
to
4992869
Compare
|
Now this branch is based on master. |
|
Correcting myself: of course we have to merge back to a hotfix branch, not directly to master. |
| } else if (type.equals(CanonicalNameConstants.INTEGER) || type.equals(int.class.getName()) || // | ||
| type.equals(CanonicalNameConstants.FLOAT) || type.equals(float.class.getName()) || // | ||
| type.equals(CanonicalNameConstants.LONG) || type.equals(long.class.getName())) { | ||
| JClass wrapperClass = type.startsWith("java") ? holder.refClass(type) : JType.parse(holder.codeModel(), type.replace(".class", "")).boxify(); |
There was a problem hiding this comment.
This is quite hard to understand. Is there another way to get the wrapper class ?
There was a problem hiding this comment.
The problem is that there are two cases:
type is wrapper
type is primitive
In the first case, we can just the holder.refClass. Unfortunetaly in the second case, holder.refClass returns a low letter int class for example. JType.parse is the way to get correct primitive types, but it only expects the name, without the .class. There is no way to get "int" name from "TypeMirror", so we have to remove ".class" manually.
|
I have only one comment. Otherwise, the code is OK. |
@PreferenceChange more parameter types
|
Rebased and merged as of 8d63943. |
Fixes #1394.