Best way to see if an edit field is empty.
String myText = xxx.getText();
Check the length of the myText string object? You also should check to make sure that the entry looks like a number before just throwing it at the Double constructor. If it isn't parseable to a number ... the constructor is going to throw an exception. Which you may or may not be catching (the above code doesn't) == app crash.
Double.toString(fooDouble).equals(" ") ??? How does a double ever equal the string " "?
R.styleable | Android Developers
You can change the "input method" for the textView object. If you really need a number (just a number) you could make sure only a valid number can be put into the view in the first place.
If that doesn't fit within your design, then you can drop back to testing the retrieved text again a regular expression of valid characters. TIMTOWTDI (there is more than one way to do it).
begin pseudo code
Code:
if String.length() > 0 and String_looks_like_a_number(String)
then:
;; we're good continue processing
else:
;; bad input, optionally notify user
;; reset bad input
;;return to UI thread
The more you tell the UI about the underlying data format the more the UI can help you validate user input. The UI will/may present the user a number input pad vs the full char input method. This saves the user having to switch to the number input setting on the virtual keyboard. << happier user.
Always expect the data to be invalid. Even if you get a number, and can successfully translate it to a Double/Integer etc, is that number *valid* within the context of your app? .. etc ..
Unit test, Unit test, Unit test...
Things that you should keep in mind.
Exceptions are for exceptional conditions and *generally* should not be used for logic flow. There are certain valid situations where its quite acceptable to use exceptions in this way.
Exceptions cost more vs (a single) if / then / else. If you are 3 methods deep and need to break back to the top level method, then throw an exception. But if your throwing and catching exceptions inside the same method, you may want to rethink the statement flow.
The hardware on the phones (current generation) lack FPU's. Doing FP ops is way more costly than Integer math. If you can get away with starting out with a higher base # ... input * 100 or 1000 or 10000... and then do your calculations against integers ... = much nicer to the cpu and battery life.
