Suggestion regarding formatCurrency

[kenshin171]

I refer to the below class method formatCurrency. It would be better if the formatCurrency be inlined into the widget class itself e.g. mCurrencyEditText.getFormattedCurrency() or make the formatCurrency method a static method e.g. CurrencyEditText.formatCurrency(Long|String)

Reason being when inlined into the widget class it looks much cleaner and users will not be able to input the wrong arguments into the formatCurrency method, at least for its intended usage with the widget.

And i have one feature request. Often when I have a currency input field, I would usually like to get the value as a double for saving the value into a database or POJO(nosql db like realm or firebase). So could we have a convenience method like mCurrenctEditText.getDoubleValue() which returns a double?

Currently this is what i am doing mCurrenctEditText.getRawValue()/100.0

Anyway keep up the good work!

//rawVal contains "1000"
CurrencyEditText cet = new CurrencyEditText();

... user inputs "$10.00"

//rawVal is 1000
Long rawVal = cet.getRawValue();

//formattedVal accepts "1000" and returns "$10.00"
String formattedVal = cet.formatCurrency(Long.toString(rawVal));

//or

String formattedVal = cet.formatCurrency(rawVal);

[BlacKCaT27]

I agree with the comment regarding formatCurrency. It's on my to-do list to limit the public API exposure to solely the CurrencyEditText class, and refactor the currency formatter so it's both private and not static. But since this is would represent a breaking change, I have to be cautious. I'll get to it eventually.

Regarding your request for exposing input values as doubles in the API. I will not be adding such functionality. The entire design of this library from day 1 is based upon the fact that the user will always be inputting values in the lowest denomination of a given currency, and as such, that is the 'true' data. Since it's already given to the code in its purest representation, the library strives to keep it in a pristine state at all times.

If we were to expose the values as doubles, such as by dividing the result by 100 (or, more correctly, dividing it by whatever the users currency uses as its divisor, if it has one which not all do), we're now introducing floating point division errors into the picture and tainting the quality of the data.

As I call out in the readme, it is recommended that apps do NOT divide the values to get decimal values. The correct solution is to store the values given by getRawValue directly, then feed those back into the widget the next time they're read from the database.

If for whatever reason you truly feel you need to be storing the decimal variant of the value, you may want to consider calling .getText(), removing the currency symbol, and converting that to a double using Double.parseDouble() (though, to be completely honest, I'm not familiar with the internals of parseDouble. It may well somehow still introduce rounding depending on how it converts the decimal values.)