I want to get my coordinates every minute, even if a user is not moving. So i used requestLocationUpdates with the following parameters:
locMgr.requestLocationUpdates(
LocationManager.GPS_PROVIDER,
60000, // minTime in ms
0, // minDistance in meters
PosljiLokacijo.this);
But when i test it on my HTC Hero (2.1 Android) and i am not moving, onLocationChanged() is never called. If i change minDistance to 1, then i get a few updates at start but after that, they come in very unregular intervals.
How should i choose these 2 parameters (minTime and minDistance) to receive coordinates every minute?
I don't think "minTime" or "minDistance" will help in this case, unless: save the last location into variables and output them every minute. Let the locationManager overwrite those variables so after a minute, the location change becomes visible. That way there's no need to wait for an update as your variables always hold the actual position.
You can also retrieve the location from the locationManager and request the location again after one minute (or whatever you'd like your interval to be) without using requestLocationUpdates.
e.g. take a look at the Timer to set a repeated call to your method that gets the location:
http://developer.android.com/reference/java/util/Timer.html
That way you should also save battery as the system won't be looking for updates all the time.
According to the documentation:
minTime the minimum time interval for notifications, in milliseconds. This field is only used as a hint to conserve power, and actual time between location updates may be greater or lesser than this value.
The only way I see to do what you want would be to set minTime to 0 and throw out values that are too frequent. You'd still not be guaranteed to get updates as often as you'd like, and be prepared for your app to be a battery killer as well.
Related
I am new to android and have been thrown in at the deep end with a somewhat complicated project.
I effectively have a number of devices running the same app and they are either staff or Exclusion zones.
I need to use bluetooth beacons to have the devices transmit their GPS coordinates, and the exclusion zones also transmit their boundary size (Bluetooth beacon distance detection was not reliably accurate enough.)
What I want to do is have a service running (I think) that has the staff devices listen for one second, whilst the exclusion zones broadcast, then all devices flip between listening and broadcasting for the next second, then repeat.
Any detected boundary violations calculated by taking the distance between the devices own GPS coordinate and any that have been broadcast by other devices of the opposing type are then to be logged.
How can I get a timer to start, and repeatedly call the function every 2 seconds, at the next exact multiple of 2 seconds?
NOT 2 seconds from the point at which the function is called. For instance if the time is 12h:35m:01s:223ms I want the repeating function to be called at 12:35:02
Compute the time remaining to the next two-second mark and then use that to schedule a delayed, one-time task that will start a two-second repeating timer.
For an Android App, that will show the value of an internal sensor (e.g. Acceleration) in a graph, i need to find a way to access this signal periodically.
At the moment i am using a SensorEventListener, but unfortunately this only gives me the possibility to get a value whenever it changes.
Since I want to display the graph (point to point) in dependency of the time, this means it would directly draw a line from the old to the new value (and if the old value has been a long time, it looks like a linear changing of the value).
So my question: How can I get access to a sensor's data periodically?
The documentation for SensorManager says that registerListener(android.hardware.SensorEventListener, android.hardware.Sensor int)
"Registers a SensorEventListener for the given sensor at the given sampling frequency."
To get these events, though, your application would need to be active (hold a partial wake lock). It would be better to do this in a background service so that the application doesn't need to remain active. See for example, SensorEventListener in a service
So in the end i used a timer, which checked the values from my sensor, which I put into an array, periodically.
Unfortunately registerListener didnt work, since the value is just a suggestion for the system.
Thanks though for the help.
I've noticed that System.currentTimeMillis() time is device dependent. If I change the time on the device's clock, this method will return a different answer.
For example: If the real time now is 10:00, and I change the clock on my device to 9:30, then System.currentTimeMillis() will return the 9:30 time (in milliseconds..).
I've also tried this answer and some other answers, but didn't find anything useful.
I should state that my app works mostly offline.
Is there a way to get the real current time (device independent) without external API?
If it were not for the 'offline' part, I'd have suggested to use a time server, but given that your app is offline most of the time that might not be a good solution.
If you don't need the actual time but just a time that cannot be messed with, you can use SystemClock.elapsedRealtime() which gives you the time since the device last booted.
You could also combine time server and SystemClock.elapsedRealtime(): Fetch the time from timer server once (e.g. after bootup) and from then on add elapsedRealtime() to that initial value (minus the elapsedRealtime value of when you get the timerserver value).
If you use the GPS location provider, getTime() will return the UTC time derived from the GPS signal, rather than the device time. The GPS location provider can work offline - but it will be much slower to obtain a fix compared to being online when it can access the A-GPS info.
I have an Android app which finds the time interval between two events.
When Event 1 fires a broadcast, I store the current time using System.currentTimeInMillis()
I do the same when the second event occurs and then calculate the difference.
However, the result is always a couple of seconds off, in the sense that I know the interval was around 4 seconds but the value I get is around 6.
Is this because of the delay between sending the broadcast, receiving it and then storing the value?
If so, what's a better way to do it to get a more accurate value?
Per Developer.android.com (http://developer.android.com/reference/android/os/SystemClock.html):
System.currentTimeMillis() is the standard "wall" clock (time and
date) expressing milliseconds since the epoch. The wall clock can be
set by the user or the phone network (see setCurrentTimeMillis(long)),
so the time may jump backwards or forwards unpredictably. This clock
should only be used when correspondence with real-world dates and
times is important, such as in a calendar or alarm clock application.
Interval or elapsed time measurements should use a different clock.
If you are using System.currentTimeMillis(), consider listening to the
ACTION_TIME_TICK, ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED
Intent broadcasts to find out when the time changes.
Is there any way to specify the time intervals that the Location Manager broadcasts the current location?
I am using a method called startListening:
public void startListening() {
locationManager.requestLocationUpdates(
LocationManager.GPS_PROVIDER,
0,
0,
this
);
}
Thanks
public void requestLocationUpdates (String provider, long minTime, float minDistance, LocationListener listener, Looper looper)
Registers the current activity to be notified periodically by the named provider. Periodically, the supplied LocationListener will be called with the current Location or with status updates.
It may take a while to receive the most recent location. If an immediate location is required, applications may use the getLastKnownLocation(String) method.
In case the provider is disabled by the user, updates will stop, and the onProviderDisabled(String) method will be called. As soon as the provider is enabled again, the onProviderEnabled(String) method will be called and location updates will start again.
The frequency of notification may be controlled using the minTime and minDistance parameters. If minTime is greater than 0, the LocationManager could potentially rest for minTime milliseconds between location updates to conserve power. If minDistance is greater than 0, a location will only be broadcasted if the device moves by minDistance meters. To obtain notifications as frequently as possible, set both parameters to 0.
Background services should be careful about setting a sufficiently high minTime so that the device doesn't consume too much power by keeping the GPS or wireless radios on all the time. In particular, values under 60000ms are not recommended.
The supplied Looper is used to implement the callback mechanism.
Parameters
provider the name of the provider
with which to register
minTime the
minimum time interval for
notifications, in milliseconds. This
field is only used as a hint to
conserve power, and actual time
between location updates may be
greater or lesser than this value.
minDistance the minimum distance
interval for notifications, in meters
listener a whose onLocationChanged(Location)
method will be called for each
location update
looper a Looper
object whose message queue will be
used to implement the callback
mechanism.
Throws
IllegalArgumentException if provider is null or doesn't exist
IllegalArgumentException if listener is null
IllegalArgumentException if looper is null
SecurityException if no suitable permission is present for the provider.
minTime : the minimum time interval for notifications, in milliseconds. This field is only used as a hint to conserve power, and actual time between location updates may be greater or lesser than this value.
minDistance: the minimum distance interval for notifications, in meters
locManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 9000, 500,locListener);
// 60000 Is 1 Minute and 100 is KM
Above you have 9000 (Nine Seconds) and 500 which is if the location has moved more than 500KM