This sentence is throwing IllegalArgumentException. I still can't figure out whats wrong with this format, its in [+-]DDD:MM.MMMMM as documentation says.
double latitude = Location.convert("-19:59.646");
Looks like the Android platform code for Location.convert(String coordinate) doesn't allow for minute decimal values greater than 59:
https://github.com/android/platform_frameworks_base/blob/master/location/java/android/location/Location.java#L255
Try using the FORMAT_SECONDS or FORMAT_DEGREES format instead as specified in the Location API docs:
http://developer.android.com/reference/android/location/Location.html
For example, your number in FORMAT_SECONDS (DDD:MM:SS.SSSSS) would be -19:59:38.76.
So the code would be:
double latitude = Location.convert("-19:59:38.76");
I verified that this works on Android using the FORMAT_SECONDS format.
You probably need to match that format exactly, so pad it with zeros.
double latitude = Location.convert( "-019:59.64600" );
Related
I've been using this method to find the minimum value of doubleArray :
colections.min()
but when i'm using this method to string Array, it got the wrong result. Likes this :
My stringArray value : {2.3 Km, 10,0 Km, 4.0 Km, 24,7 Km}
but when i call the result, its show 10.0 Km as minimum value instead 2,3 Km.
Can anybody tell me what is the perfect method that i can use to get the minimum value of the srtringArray ?
I know this is a very basic question, but i really need more explanation.
Thank you
A string beginning with 1 comes before a string beginning with 2. Just as it would with A and B. The minimum value of a string array is the string which comes first alphabetically. What are you expecting?
I can't seem to get my head around this. If have tried the following approaches:
DecimalFormat df = new DecimalFormat("00000.00");
DecimalFormat df = new DecimalFormat("######.##");
But the following line always generates and IllegalArgumentException.
double price = Double.valueOf(df.format(((EditText) view
.findViewById(R.id.edit_item_price)).getText().toString()));
// Sample input passed is value of 200 or some other whole number.
item.setPrice(price);
It doesn't make sense as I only copied the obvious solutions in this forum. Most of you got the format() to work.
Originally, I didn't have these lines of code. I just call my setPrice() method after getting the item price. This works. However, Double.valueOf() has a nasty habit of using only one decimal position.
e.g. passed 200. I get 200.0 inside my item object. I figured by using DecimalFormat I could've prevented this but it appears this caused me MORE headaches instead.
When you say you pass 200 and you get 200.0, you mean you get it in a double value? If so, that doesn't matter - it's a number and 200 = 200.0 for double values.
format(...) turns a double value to a String value. You have it the other way round. That's why you get the Exception.
If the price variable is actually a double you should do
double price = Double.valueOf(((EditText) view
.findViewById(R.id.edit_item_price)).getText().toString())
But I think you want that the price is a String, then you should convert the text from the EditText to a double and that double back to a String with something like new DecimalFormat("0.00")
I need to set the direction value when capture a image from the camera in a tag inside the image. I try for example:
exif.setAttribute("GPSImgDirectionRef","T");
exif.setAttribute("GPSImgDirection","142.2");
with no success.
Any idea?
Thks.
I came into a solution for this issue recently, if someone needs it:
According to ExifInterface documentation the attribute using the tag TAG_GPS_IMG_DIRECTION expects a "rational" value. But as far as I could understand it's source code, it validates the inserted value firstly by checking if there's a "/" char in the string, and after that get the numbers before and after the "/" to generate a double value, and just when it can be converted to a double value this attribute will be added to the image file.
So basically to make it work, instead of sending a double value as your attribute, you need to send a fraction.
As a suggestion, making a fraction out of a double could be easily done using Apache Commons Math Lib - Fraction. It would be something like this:
Fraction azimuthAsFraction = new Fraction(azimuthAsDouble);
exif.setAttribute(TAG_GPS_IMG_DIRECTION, String.valueOf(azimuthAsFraction));
This way your azimuth value should be added to the image file metadata.
in android eclipse sometimes a calculation result for both double and float when displayed as a string uses a decimal point (desired) but sometimes using an exponent (bad - confusing to user). anyway to avoid the exponent?
See String.format documentation.
Just set the desired format for your numbers. You probably want String.format("%f",number).
i have a problem with double values i need to store in an android homed sqlite database. since these double values represent gps values (lat & lng), i really NEED an absolute precision down to the 9th number after the comma.
now i have a table like this:
CREATE TABLE x REAL lng;
and insert sth (hardcoded) like:
INSERT INTO x lng = '1.0';
and when reading lng from this table into some (java) double variable, i get a value like "0.999956837" - this renders the values pretty useless to me.
is there a way to enforce the precision i need other than storing the values as "text" fields (what would make expensive casts neccessary) or storing them as integers (meaning i need to multiply/divide at each write/read-op)?
SQLite is typeless, that means all representation is written as text, probably the wrapper api does some converts you don't know of, that you get those results.
If you need to store the data as string do it.
Just when you read out the double make sure you saved in the right format, you can use getDouble on the column.
double has about 17 decimal digits of precision, so if 9 digits is what you need, there should be no problem (assuming that you don't do any complex calculations on those values). Just make sure you never end up using float, because that has only about 7 digits of precision.
You should also make sure you understand how binary floating-point works, and that it will always result in seemingly "round" values becoming slightly off - which simply does not matter for most applications (including yours) as long as it happes somewhere in the 17th decimal digit. See that link also for alternatives for applications where it does matter.