Where to save Android GPS (Latitude , Longitude) points?

On onLocationChanged event I want to save my GPS route (Latitude , Longitude). Later I want to load this data and draw the route.

Who is the best way to do this, by using some array type (and save or load by using database) or XML files开发者_运维百科 or something else?

Thanks.

The best way of storing double values in SharedPreferences without losing precision is:

• Transform to bit representation to store it as long:

  prefsEditor.putLong("Latitude", Double.doubleToLongBits(location.getLatitude()));
  

• To retrieve, transfrom from bit representation to double:

  double latitude = Double.longBitsToDouble(prefs.getLong("Latitude", 0);
  

However, I think that if you want to store a big amount of points is better using a SQLite database than saving each coordinate in a Key-Value pair in SharedPreferences or serialize the array in XML and write it to a file or to SharedPreferences. The database offers you the advantage of loading in memory only the points within the area you are displaying in the map, so you can save memory.

Correct me if I'm wrong, but it might be better to convert the double values to strings and then whenever you call them convert them back to doubles. Sounds like a pain, but oracle's website (http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html) says:

"use a float (instead of double) if you need to save memory in large arrays of floating point numbers. This data type should never be used for precise values, such as currency"

prefEditor.putString("Latitude", Double.valueOf(loc.getLatitude()).toString());

Then, to call the value

String latitudeString = pref.getString("Latitude", "0");
double latitude = Double.parseDouble(latitudeString);

It definitely seems like more of a nuisance, but seems also more likely to return the exact value that you saved, also, instead of something slightly off. And I suppose that would depend on how completely accurate you need the values to be.

Though, as far as using an array, I'm clueless because I've never needed to use them and have no experience with them.

Use SharedPreferences and Editor.

Check out this open source code, it will probably help you a lot: OsmandSettings.java

I'll explain the important parts of the code:

import android.content.SharedPreferences;
import android.content.SharedPreferences.Editor;

// These settings are stored in SharedPreferences, replace com.osmand.settings 
// with your own package name, or whatever String you want.
public static final String SHARED_PREFERENCES_NAME = "com.osmand.settings";
public static final String LATITUDE = "latitude";
public static final String LONGITUDE = "longitude";

To write to SharedPreferences:

public void onLocationChanged(Location location){
    SharedPreferences prefs = Context.getSharedPreferences(SHARED_PREFERENCES_NAME, Context.MODE_WORLD_READABLE);
    Editor editor = prefs.edit();
    //Save it as a float since SharedPreferences can't deal with doubles
    edit.putFloat(LATITUDE, (float) Location.getLatitude());
    edit.putFloat(LONGITUDE, (float) Location.getLongitude());
    edit.commit();
}

To read from SharedPreferences:

public void onLocationChanged(Location location){
    SharedPreferences prefs = Context.getSharedPreferences(SHARED_PREFERENCES_NAME, Context.MODE_WORLD_READABLE);
    double lat = (double)prefs.getFloat(LATITUDE, 0);
    double lon = (double)prefs.getFloat(LONGITUDE, 0);
}

Think about the precision (not accuracy) you need to represent the data. Would a couple inches be close enough? Most handheld GPS receivers are lucky to be good to a couple meters. One degree-second of longitude at the equator moves you about 100 feet. If you use a signed 32-bit integer to represent your latitudes and longitudes, LatE6 & LonE6, you could store the largest longitude there is as +/-180,000,000 and the least significant digit is:

(1 / 1E6) * (3600 sec/deg) * (100 feet/sec) = 0.36 feet or 4 inches.

I've got to imagine my Garmin uses something like this, not a float with only 24 bits of precision and certainly not a 64 bit double. Conversion between integer and the double shouldn't cost much. You could even pack a lat/lon pair into a long.