08-01-2008 01:29 AM
So i'm trying to wrap my head around why a location listener would require a max_age, especially one that is smaller than the interval. Its hard to explain in words so i did in a diagaram..in paint (sorry).
Isn't it fair to say that, assuming 60 second intervals with a timout of 10 and maxage of 20, that maxage will never be used? This is because the maximum age will always be less than the last time a poll was recieved, meaning that even if a poll was recieved last time - its to old?
So in my example, lets say it takes 70 seconds to get the first position, it will take another 50 seconds to get the next position. If the SECOND position isn't aquired after 50 seconds, maxage looks at and the first position and it is 50 seconds old which is outside the 20 second threshold, so its never used?
I've read the javadoc and its examples any help is appreciated.
08-01-2008 11:59 AM
I'm not sure where the GPS fix is occurring in your chart, so I'll try a generic explanation.
The interval is the time for which your application wants to receive location updates. Meaning the Listener should fire at the time period described in the interval.
This does not mean a GPS fix occurs during the interval. This occurs independently.
If your interval has arrived, but the BlackBerry does not have a recent fix it can wait up to the timeout to fire the Listener while it tries to get a fix. If no fix is obtained after the timeout value, the Listener fires anyway with the last known coordinates specifying that the results are not valid.
The max age parameter works in the opposite direction of the timeout. The BlackBerry may have received a fix a X point in time (remember these occur independently from your interval setting). It'll keep these coordinates for future use. When your interval arrives, it checks to see if CurrentTime - X <= max age. If this is true it will pass the coordinates it already has to your listener. If not, it'll try to get more up to date coordinates.
To summarize, the timeout is how long you allow the BlackBerry to wait to fire your listener (while it tries to get a fix). Max age represents how old a fix can be that is passed into your listener at the interval time and still be a valid fix.
08-04-2008 01:41 AM
Thanks mark, excellent response.
So my next question is, if the interval is simply a time period at which a GPS fix can occur at anytime within that time period...does this mean the GPS chip is on the whole time draining battery power?
E.G. I have an interval of 60 seconds, the gps chip is on during that entier 60 seconds sporadically obtaining positions, of which the most recent is passed to my listener at the end of a 60 second time period?
So having a listener is a very inefficient way of obtaining GPS? Why not write your own thread that uses LocationProver.getLocation()? As this would only 'wakeup' the gps chip for every request as oposed to having it constantly running with a listener attached?
FYI Red denoted when a position was obtained in my diagram.
08-04-2008 08:56 PM
I agree - a very good answer Mark!
Not an official answer, but here is what I suspect, based on my experience. Hope it helps
I have written low level Bluetooth interface to GPS units, they will send GPS locations at approximately once a second, until you tell them to stop. I suspect the GPS units in the BlackBerry will do the same thing. So if the GPS unit is switched on, it will drain battery because it will be sending a location every second.
I believe the LocationListener will attempt to decide, based on the length of your interval, if it wants to keep the GPS on, or switch it off. If it leaves it on, then, because it gets a new location every second, the locations you receive will be reasonably current, and you will woken up pretty close to the interval you are expecting.
The problem with the LocationListener switching the GPS unit off, or using LocationProver.getLocation() to get a location, is the time taken to get the location. The GPS unit has lost its satellites, it can take some time to get them again. The first fix after a GPS unit is switched on can take minutes. This is why the getLocation() can block, so should not be issued on an event Thread.
Note, and this is from my experience and I've not seen it documented, the first fix can be 'dubious'.
So if you want a GPS location infrequently, and can afford to wait, then use LocationProver.getLocation(). From a battery overhead, I can see little difference between this and LocationListener, as long as LocationListener is switching the GPS unit off. If you can't afford to wait, or you want locations frequently, then you have to use LocationListener with a short interval and you are going to take a battery hit. I don't know at which interval the LocationListener will start switching the GPS unit off.
08-04-2008 10:38 PM
Another excellent response, thanks very much peter.
I wonder if there is a simple way to test is if GPS is on during the LocationProvider interval, I will take a look, if anyone has anymore input it would be appreciated.
08-07-2008 01:09 PM