3

In my app, I have edit text boxes where the user enters a decimal value that the app uses to run a calculation.

Some users in other locales are reporting problems when entering the numbers, like entering a value and a different one appearing. I have tried to fix this by getting the value from the editText with this method:

public double stringToDouble(String s){
        if (nf == null){
            nf = NumberFormat.getInstance(Locale.US);
        }
        try {
            return nf.parse(s).doubleValue();
        } catch (ParseException e) {
            e.printStackTrace();
            return 0.0;
        }
    }

and 

val = stringToDouble(et.getText().toString());

But apparently that still isn't working for some people.

One user in Slovenia reported that it works fine if

  • settings; Language & keyboard :
  • Select language : set to English(Slovenia)
  • Touch input: set only to English and whatever language(my case Slovenia)
  • Bilingual prediction: OFF
  • Text prediction: OFF

What is the correct way to go about fetching the double values? Thanks

Matt
  • 2,650
  • 4
  • 36
  • 46
  • 1
    is this because some countries use a comma instead of dot for decimals? – Kevin Qiu Sep 20 '11 at 00:33
  • I think that has something to do with it. But when I use the above double to string method with "2,2" it returns a double with a value of 2.2 so I thought it was working. – Matt Sep 20 '11 at 02:10
  • see if this helps http://stackoverflow.com/questions/4323599/best-way-to-parsedouble-with-comma-as-decimal-separator – Kevin Qiu Sep 20 '11 at 03:29
  • 1
    Should the locale be the phone's default locale, instead of Locale.US? The problem is, I have no way of knowing what locale the user will be in so it needs to work in all of them. – Matt Sep 20 '11 at 05:07
  • http://developer.android.com/reference/java/util/Locale.html#getDefault() this will allow you to know their locale – Kevin Qiu Sep 20 '11 at 05:25
  • Thanks, but after reading that page, it looks like I should be using Locale.US in order to get "machine readable" data. NOT the user's current locale... It's kind of ambiguous though. – Matt Sep 20 '11 at 06:58
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/3606/discussion-between-matt-and-kevin-qiu) – Matt Sep 20 '11 at 07:03

1 Answers1

7

From the looks of it, the correct way to do it is:

public double stringToDouble(String s){
        if (nf == null){
            nf = NumberFormat.getInstance(Locale.getDefault());
        }
        try {
            return nf.parse(s).doubleValue();
        } catch (ParseException e) {
            e.printStackTrace();
            return 0.0;
        }
    }

So far that seems to be working for me.

Matt
  • 2,650
  • 4
  • 36
  • 46
  • Caching your `NumberFormat` instance is okay as long as `stringToDouble()` isn't invoked concurrently by multiple threads, as `NumberFormat` isn't thread-safe. – Philipp Reichart Sep 26 '11 at 17:44
  • Thanks, I didn't know that. Should I use NumberFormat.getInstance(Locale.getDefault()).parse(s).doubleValue(); instead? – Matt Sep 27 '11 at 20:36
  • Either that (simplest solution, preferred) or synchronizing at least the invocation of `nf.parse()` on some `private final new Object()` field (only after it's proven to be a bottleneck). Maybe there's even a number-formatting cousin of Common Lang's thread-safe `FastDateFormat` out there, but I couldn't find it right now. – Philipp Reichart Sep 27 '11 at 20:48
  • Končno ena varianta, ki deluje! ;-) – lenooh Oct 05 '14 at 13:18