Oh, also... If a GPS fix is all you will accept, firstly your app will not work in big buildings, under tunnels, dense metro areas [San Francisco, NYC, etc] or anywhere like that where 3 GPS satellites are not accessible. Secondly, if you can't get a fix after some sort of realistic timeout, you'll need to notify the user of this so they're not waiting around while your app repeatedly fails to get a GPS fix.
To expand on my above post, I would definitely recommend using both listeners side-by-side but just always giving precedence to GPS updates. This fixes many problems: 1) You'll pretty much always be able to get some sort of fix. 2) In cities where GPS may unavailable, there are likely lots of cell towers so cell triangulation will be quite accurate [In Los Angeles, I've seen a Network fix be merely tens of meters off from a GPS fix]. 3) In rural areas where cell towers are few and far between, GPS is likely accessible [not many tall buildings] so you'll be able to use that accurate fix. -Nick On Apr 16, 11:38 pm, patbenatar <[email protected]> wrote: > I have solved this problem [with much thanks to the brains on this > group] by running two LocationListeners side-by-side, one fine [GPS] > and one coarse [Network]. The first provider to get a location update > wins and I use that location. This works for me as I don't care about > the location being super accurate at this point [later in my app I > allow the listeners to run their lives and whenever GPS is active and > available I use its updates then if it goes unavailable/disabled I > allow Network to take over [the whole while I'm running the two > listeners side-by-side, and just not handling updates from Network if > GPS is active/available]. > > You really have no reason to have a LocationListener[10] array... > There are really only two location providers, Network and GPS. So all > you need are two LocationListeners: fineLocationListener and > coarseLocationListener. > > Here, this is the thread in which I learned how to do > this:http://groups.google.com/group/android-developers/browse_thread/threa... > .. its a pretty good discussion on LocationListeners. > > Hope this helps! > > -Nick > > On Apr 16, 6:06 pm, JP <[email protected]> wrote: > > > > > > > What I do. > > I never even look at lastKnownLocation; as you state it might be old > > like dustballs. > > This means I will only process locations received fresh from > > onLocationChanged(). > > As you note, this may never happen. So keep users informed > > accordingly! If you couldn't acquire a fix, let the user know. > > > On Apr 16, 3:41 pm, Anna PS <[email protected]> wrote: > > > > > On Apr 16, 12:45 am, JP <[email protected]> wrote: > > > > On Apr 15, 8:35 am, Anna PS <[email protected]> wrote: > > > > > > Yet in my log files, I can > > > > > still see the Android NetworkLocationProvider logging > > > > > onCellLocationChanged events. Is this a bug in my code? > > > > > Without diving into your code. Double check it by using GPS. GPS is > > > > considerably more accurate than base station based triangulation, > > > > which may not result in location changes even if you move a hundred > > > > meters (in my experience, anyway). > > > > The basic issue is this. I don't want to accidentally end up with a > > > LastKnownLocation that's days out of date, so I have to check the age > > > of the location fix. > > > > Since the GPS time (from location.getTime()) and the system time can > > > be quite different (as <a href="http://www.mail-archive.com/android- > > > [email protected]/msg47517.html">discussed here</a>, > > > comparing the two doesn't work. The only reliable way seems to be: > > > > - get an initial location from getLastKnownLocation > > > - wait for a location update from onLocationChanged > > > - compare the age of the two to make sure the latter is newer. > > > > However, I'd also like to write code that handles gracefully the > > > possibility that the user is (say) indoors, and therefore won't get an > > > onLocationChanged event at all. (In which case, we should just take > > > the LastKnownLocation, and never mind if it's out of date.) > > > > I seem to be at a logical impasse. What can I do? I can't wait for an > > > onLocationChanged event if it's never going to happen - my code will > > > hang forever! But equally I can't just take getLastKnownLocation every > > > time - it might be wildly inaccurate. > > > > Maybe I need to run some kind of timer in the code, to check how long > > > we've been waiting for an onLocationChanged. Does that seem like the > > > best idea? > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected] > > > For more options, visit this group > > > athttp://groups.google.com/group/android-developers?hl=en > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group > > athttp://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
