I am designing the map-based app and I want to do certain set of steps when user's location has been acquired (blue dot has been shown on the map). On some of the devices it may take up to 1 min due to location services ramp-up process.. So the question is how do I know when Android Map managed to acquire my location, so I can start doing the rest of initialisation process?
I was thinking about implementing my own LocationListener and trigger callback when I receive location, but this solution seems worthless since I need to only know the point when current location has been acquired and blue dot has been shown. I don't care about location updates.
If you are talking about the blue dot on a map, I suppose you add the MyLocationOverlay to your map. If it is so, there is an easy way to do what you want - MyLocationOverlay has runOnFirstFix(Rannable) interface, so provided Runnable will be run as soon as the map acquires your current location:
this.currentLocationOverlay.runOnFirstFix(new Runnable() {
#Override
public void run() {
//do your magic here
}
});
Related
I've an Android Application that displays a map.
The map is by default centered on the user position following its movements (the center is updated according to the position updates).
However I want the user to be able to use gestures to navigate throw the map. When the user starts the navigation I want the "following" to stop, and a button is displayed so that it can start again.
How can I know when the user has moved the map center?
On the GoogleMap.OnCameraChangeListener, I don't know if the change is due to a location changed or a user interaction.
I've a a kind of working solution using the OnCameraChangeListener, but its a bit "dirty" and I don't find it very nice:
map.setOnCameraChangeListener(new GoogleMap.OnCameraChangeListener() {
#Override
public void onCameraChange(CameraPosition position) {
// gpsPosition contains the last position obtained
if(isFollowing && gpsPosition!=null && (Math.abs(position.target.latitude - gpsPosition.latitude)>0.000001 || Math.abs(position.target.longitude - gpsPosition.longitude)>0.000001) ){
isFollowing = false;
map.getUiSettings().setMyLocationButtonEnabled(true);
}
}
});
Is there a nice Solution to the problem?
If you want to detect user interacting with the map OnCameraChangeListener is surely too late to do that. It may be called seconds after user started interacting with the map.
What you need to do, is add 2 other listeners:
OnMyLocationButtonClickListener - to know when to start tracking (set your isFollowing to true)
OnMyLocationChangeListener - when your isFollowing is true, call GoogleMap.animateCamera to the new position
So the only thing left is when you set isFollowing to false:
Create an invisible overlay in your layout (like here, but with normal View instead of custom) and assign this overlay (the View) an OnTouchListener (ok, it is 3rd, I lied that you need only 2).
In this listener always return false, but also set isFollowing to false. This when when user starts interacting with the map and you should stop automated camera movements.
I also see you are showing and hiding my location button, so do this where you change the value of isFollowing. Btw.: good idea to do that. I'll try it too.
I have never tried this, but here are some ideas off the top of my (balding) head:
Option #1: Handle the location change updates yourself, by recentering the map yourself when the location change comes in. If a camera-change event occurs that does not appear to be tied to the location change (e.g., 5+ milliseconds later), that was presumably a user modifying the map via gestures.
Option #2: Subclass the Maps V2 MapView and override touch-related methods like onTouchEvent(). In addition to chaining to the superclass, you would know that a camera change that happens very soon from now probably is from the user modifying the map via gestures.
Option #3: Do both of the above. That way, all changes to the map should touch your code, which should increase the reliability of your determining the source of the camera change.
BTW, I filed a feature request for a better solution.
The simpliest way should be saving the center Longitude and Latitude of your Map.
Now create an EventListener and check it in an if-statement:
if(oldLongLat != newLongLat){
//Something has moved
}else {
//Nothing has moved
}
I've been using the fused location provider since its release and I am pretty happy with it (way better than the old system). But I ran into a peculiar problem when using geofencing in combination with LocationClient.lastKnownLocation(). The setup is as follows:
I drop several geofences around some home location (with increasing ranges). When I get the intent that a fence is crossed I retrieve the last known location from LocationClient and work with it. Apart from than I also registered for regular location updates with update mode PRIORITY_BALANCED_POWER_ACCURACY.
Most of the times this works perfectly fine, but sometimes this happens:
Time 000 s - (Lat,Lon,Accuracy) = (48.127316,11.5855167,683.0)
Time 120 s - (Lat,Lon,Accuracy) = (48.1260497,11.5731745,31.823)
Time 300 s - (Lat,Lon,Accuracy) = (48.1217455,11.5641666,143.81)
Time 420 s - (Lat,Lon,Accuracy) = (48.1189942,11.559061,36.0)
Time 600s - (Lat,Lon,Accuracy) = (48.127316,11.5855167,683.0)
Notice that all these locations are retrieved by getLastKnownLocation(). What seems fishy here is that the first and the last location are identical (even in the other attributes), to be more specific:
* intent at time 0: *
component: ComponentInfo{package.Class}
key [location]: Location[mProvider=fused,mTime=1373524391934,mLatitude=48.127316,mLongitude=11.5855167,mHasAltitude=false,mAltitude=0.0,mHasSpeed=false,mSpeed=0.0,mHasBearing=false,mBearing=0.0,mHasAccuracy=true,mAccuracy=683.0,mExtras=Bundle[mParcelledData.dataSize=352]]
* intent at time 600: *
component: ComponentInfo{package.Class}
key [location]: Location[mProvider=fused,mTime=1373524994871,mLatitude=48.127316,mLongitude=11.5855167,mHasAltitude=false,mAltitude=0.0,mHasSpeed=false,mSpeed=0.0,mHasBearing=false,mBearing=0.0,mHasAccuracy=true,mAccuracy=683.0,mExtras=Bundle[mParcelledData.dataSize=352]]
* note the ~600 s difference in the timestamp *
I do not understand how this can happen, as there have been locations in between that were both more recent and more accurate. Also the new timestamp on an old location makes me curious... apparently similar things happened when using the old API, but this new location provider is just called fused, so I can not distinguish GPS from WPS from sensors... If it is the cell tower switching problem (outlined in the linked question concerning the old API) then why would the phone connect to a "far away" tower if it has seen closer towers?
Why is this happening?
The first and last points were gotten using cell triangulation. The error/accuracy is typical of cell-based location, and it looks like the Google power saving logic decided that switching to cell would be OK, even as you say its recent history included points much closer.
Aw, SHUCKS! I got this too today... And I moved to the new Google Play Services location precisely to AVOID this... And I was so thrilled up until just now when I got it too. You may or may not know that the old one had these kind of problems, and it was a pain.
There are lots of threads regarding this, including one of my own :(
Why is locationmanager returning old location fixes with new gettime-timestamp?
I guess the only thing to do is avoid using cached location...
Instead of polling, one can work around one or more sources of inaccuracy using this subscription mechanism.
LocationListener locListener = new LocationListener() {
#Override
public void onLocationChanged(Location location) {
if (location == null)
return;
// process these:
// location.getLatitude();
// location.getLongitude();
// location.getAccuracy();
...
}
...
}
((LocationManager) getSystemService(Context.LOCATION_SERVICE)
.requestLocationUpdates(LocationManager.GPS_PROVIDER,
minTimeMilliSec,
minDistanceMeters,
locListener));
I am looking to figure out how I can replicate the follow current location feature that exists in Maps on Android (and iPhone) using the Google Maps external library. The way the feature works in Maps is that when you press the button it begins panning with your location until you touch (and/or move) the map. Using the following I have been able to get my app to keep the current location on the screen but not keep the current location in the center of the screen (it pans when the location gets near the edge of the screen whereas Maps keeps it in the center the whole time):
butMapCurrentLocation.setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
runOnUiThread(new Runnable() {
public void run() {
mapController.animateTo(myLocationOverlay.getMyLocation());
}
});
}
});
I also tried setCenter rather than animateTo and they seem to have the same effect.
Additionally it is worth noting I need to be able to stop this function that keeps the location in the center (such as when another button is pressed or the map is touched). The Runnable above doesn't stop right away and I cannot get it to stop properly when requested even when using .cancel as discussed here: Android: How do I stop Runnable?
There is no official way yet to do that in Google Maps v2.
You can do what you want however. There is two things you have to do:
Register for location updates from some LocationProviders (eg gps) to get the user's location. When you get the location animate map to the new location.
Stop this when the user moved the map.
So doing 1. is easy, doing 2. is not possible officially with the Maps v2 api. Look at this issue for more details.
The workaround suggested there is to create your own MapView (extend the original MapView) and override it's dispatchTouchEvent method. There you can catch any touch events and can detect if the user touched/moved the map.
Background
I am writing an Android app whose main function is tracking the user's location and making an alert when the user gets near some point. Therefore I need to update the user's location at regular intervals, and these intervals should get smaller as the user comes closer to the target. So when the user is within, say, 1 km of the target, I want the location to be updated every 20 seconds and so on, until the user arrives.
Problem
When I test it (provider = LocationManager.NETWORK_PROVIDER), a call to requestLocationUpdates(provider, minTime, minDistance, locationListener) with any minTime < 45000 has the same effect as minTime = 45000, i.e. I get updates with an interval of exactly 45 seconds.
I know the minimum time parameter is only a "hint", but it is not taken as a hint by my app. I get updates with the interval specified until that interval passes below 45 seconds. It seems as though a minimum time of 45 seconds between location updates is hardcoded into Android, but that would be kind of odd. Plus I have never heard of this problem before, and I have not been able to find it addressed here on Stackoverflow.
Because I am not able to get frequent updates, my workaround (for now) is to manually call requestLocationUpdates whenever a new location is needed, and then just use the first available location. To do this at small intervals I use handler.postDelayed(myRunnable, updateInterval) to delay the calls, and myRunnable then takes care of calling requestLocationUpdates. However, this method only works about 50 (apparently random) percent of the time.
Does anybody know of the problem, and is there a way to fix it? Or is my only option to set minTime = 0 and just hope for the best?
Source code
Here is the source code for myRunnable, whose run() method I manually call regularly with handler.postDelayed(myRunnable, updateInterval):
public class MyRunnable implements Runnable {
private LocationManager manager;
private LocationListener listener;
#Override
public void run() {
// This is called everytime a new update is requested
// so that only one request is running at a time.
removeUpdates();
manager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);
listener = new LocationListener() {
#Override
public void onLocationChanged(Location loc) {
location = loc;
latitude = loc.getLatitude();
longitude = loc.getLongitude();
accuracy = Math.round(loc.getAccuracy());
handler.sendMessage(Message.obtain(handler, KEY_MESSAGE_LOCATION_CHANGED));
checkForArrival();
}
// Other overrides are empty.
};
if(!arrived)
manager.requestLocationUpdates(provider, updateInterval, 0, listener);
}
/**
* Removes location updates from the LocationListener.
*/
public void removeUpdates() {
if(!(manager == null || listener == null))
manager.removeUpdates(listener);
}
// Another method for "cleaning up" when the user has arrived.
}
And here is my handler:
handler = new Handler() {
#Override
public void handleMessage(Message msg) {
switch(msg.what) {
case KEY_MESSAGE_LOCATION_CHANGED:
if(myRunnable != null) {
myRunnable.removeUpdates();
handler.postDelayed(myRunnable, updateInterval);
}
break;
}
}
};
Additional info
The whole location updating thing runs in a service.
I have read the doc several times, Google'd the problem, and tried various other workarounds. Nothing quite does it.
I have logged the damn out of this thing, and the only exciting thing to see is a big fat "ignore" to my frequent location requests. All the right methods are called.
Any help will be very much appreciated!
You are completely right, the minimum time 45 seconds is harcoded in Android.
This seems to be a NetworkLocationProvider class source code, when it was still in Android core:
http://www.netmite.com/android/mydroid/frameworks/base/location/java/com/android/internal/location/NetworkLocationProvider.java
Look at the variable:
private static final long MIN_TIME_BETWEEN_WIFI_REPORTS = 45 * 1000; // 45 seconds
And the method:
#Override
public void setMinTime(long minTime) {
if (minTime < MIN_TIME_BETWEEN_WIFI_REPORTS) {
mWifiScanFrequency = MIN_TIME_BETWEEN_WIFI_REPORTS;
} else {
mWifiScanFrequency = minTime;
}
super.setMinTime(minTime);
}
Now NetworkLocationProvider is out of the Android core, you can find it in NetworkLocation.apk in /system/app
You can find an explanation of why is out of the core here:
https://groups.google.com/forum/?fromgroups=#!topic/android-platform/10Yr0r2myGA
But 45 seconds min time seems to still be there.
Look at this NetworkProvider decompilation:
http://android.fjfalcon.com/xt720/miui-trans/apk-decompiled/NetworkLocation/smali/com/google/android/location/NetworkLocationProvider.smali
.line 149
const-wide/32 v4, 0xafc8
iput-wide v4, p0, Lcom/google/android/location/NetworkLocationProvider;->mWifiScanFrequency:J
As you might guess if you convert 0xafc8 to decimal you get 45000 milliseconds
I haven't found an explanation of why 45 seconds. I suppose there will be reasons like avoiding service overloading or other uses they don't want.
In fact, there is a 100 request courtesy limit to Geolocation API:
https://developers.google.com/maps/documentation/business/geolocation/#usage_limits
But they don't seem to respect this rule in Google Maps app. If you open it and you only active network location you can notice that yout location is updated much more frequently than 45 seconds.
I noticed this line suspiciously frequent (33 times a second) in logcat when Google Maps is open:
02-20 17:12:08.204: V/LocationManagerService(1733): getAllProviders
I guess Google Maps is also calling removeUpdates() and requestLocationUpdates() again to obtain a new position.
So I think there is no fix and this is the best you can do if you want to get network locations over one in 45 seconds.
You can set the minTime to any value. However, you will only get an update once a new location is available. The network only updates every 45 sec or so on every phone I own. This seems to be a limitation of the Network Provider. If you want more frequent updates use the GPS provider. Depending on the GPS hardware you should get a maximum update rate around 4Hz.
I was having a similar issue. I put a call to locationManager.requestSingleUpdate() at the end of onLocationChanged() and it forced back to back updates. You could set a delay command then execute requestSingleUpdate, making sure to register the containing locationListener.
I was trying to create a GPS clock but the updates were inconsistent updating anywhere from 1-5 seconds or so. but it might work for another application.
I've got a question on making an navigation app more faster and more stable.
The basic layer of my app is a simple mapview, covered with several overlays (2 markers for start and destination and one for the route).
My idea is to implement a thread to display the route, so that the app won't hang up during the calculation of a more complex route (like it does right now).
After implementing the thread there are no updates shows any more, maybe you can help me with a short glance at an excerpt of my code below:
private class MyLocationListener implements LocationListener {
#Override
public void onLocationChanged(Location loc) {
posUser = new GeoPoint((int) (loc.getLatitude() * 1E6), (int) (loc
.getLongitude() * 1E6));
new Thread(){
public void run(){
mapView.invalidate();
// Erase old overlays
mapView.getOverlays().clear();
// Draw updated overlay elements and adjust basic map settings
updateText();
if(firstRefresh){
adjustMap();
firstRefresh = false;
}
getAndPaintRoute();
drawMarkers();
}
};
}
Some features have been summarized to a method like "drawMarkers()" or "updateText()"...(they don't need any more attention ;-))
When are you actually asking for the thread to run? I only see code for creating it. If you did, you'd discover that only the main (UI) thread is allowed to update, as RPond notes.
Instead, split off your work and post the results back to the main thread via a Handler.
You can only update the UI on the UI thread so I think that is the problem. Check out this article on threading for solutions to this problem.
I may be barking up the wrong tree here, but my guess is that it's something to do with the fact that you're making changes to the MapView on a thread that isn't the UI thread.
I'd expect this to result in one of these possibilities:
Your changes are throwing an exception that you're not seeing (again possibly because it's on another thread)
Your changes are being ignored because they're being made on the wrong thread.
The map's being updated but your UI thread doesn't know it needs to redraw the map.
Hope this helps - at least by pointing you in vaguely the right direction.
One would hope you're not using the Google MapView for rendering your navigation, since from my reading of the terms and conditions, navigation is not included in the acceptable use policy.
From the Android Maps APIs Terms of Service
Under this Section 8, you must not (nor may you permit anyone else to):
...
8.7. use the Service or Content with any products, systems, or applications for or in connection with (a) real time navigation or route guidance based on position input from a sensor (including but not limited to any visual or audible turn-by-turn route guidance);
...