Why did you close the previous PR? You could overwrite the branch with git push -f.

i think because he had a wrong branch name there. the other was 203-Generic_AbstractPrefField instead of 1203. or does git/github support branch renaming for a PR?

@chvndb you should add @Override annotations.

Indeed, the branch name was incorrect. I added @Override annotations.

OK, branch renaming is not supported I think. I'll review this later.

What happens if one passes null? I think that will yield NPE while unboxing.

Ah indeed, we had this discussion before and I forgot about it. We agreed on setting the preference to its default value. I will add this.

something like this?

I do not think so. I think we agreed on to add zero if one passes null etc.

re-reading the original issue, it is ambiguous what the action should be when passing null. What do you actually mean by adding zero?

if (value == null) {
  putLong(0);
}

etc

I see, so you would set the preference to what you consider to be the default value for the given type. I think it is more logical to set it to the default value the developer has defined, as he has thought about what the default value should be in the context of his application.

Maybe you are right, but i am not really sure what would be better. @yDelouis WDYT?

E.g. storing a json object in a string preference and the default value is {"name":"chvndb"}. Using put(null) in the first case would set it to the empty string. However, this will most likely break the application while resetting it to the original will not.

I think chvndb is right, we should reset the value to the default one.
Setting a value to null in a preference is restoring the default value for it. So, in our case, we should do the same.

@chvndb please modify the null behavior as @yDelouis suggested. Also the reset() method is not needed in that case, i think. Also please squash your commits into one.

Added the null behaviour to reset the preference to the user defined default.

Added the reset method as it is a cleaner API. It allows a user to explicitly reset a given preference without using the side effect of putting a null value. I can still remove it if you want.

(p.s. squashed the commits)

I think the reset() method is redundant. We already have the remove() method, and after that get() returns the default value.

Thanks! Can you reword the commit as to follow the standard git format (as laid out in the contribution guide)?

Like this?

Yeah, thanks.

@chvndb can you you please react to the review comments?

Sorry, with the new year I guess I missed your comments. Updated.

On 08 Jan 2015, at 13:26, Csaba Kozák notifications@github.com wrote:

@chvndb https://github.com/chvndb can you you please react to the review comments?

—
Reply to this email directly or view it on GitHub #1272 (comment).

Thanks!