The GPS setting enables the hardware to be turned on, but I don't think this automatically tells the GPS provider to go collect fixes from the hardware. And if all you're using is the passive provider, it's possible that there are no last fixes anywhere to be got because no other apps asked for location updates for your app to piggyback on. In fact, based on your evidence, that seems like a probable cause. It seems strange that you should get back a value of 0/0 instead of null, since 0/0 is clearly not a true last known location for the device. That sounds to me like a bug that you'll have to work around. Unfortunately, this probably means requesting location updates from a non-passive location provider, which means requiring permissions, which it sounds like you were hoping to avoid.
- dave On Feb 20, 11:40 am, Jake Colman <[email protected]> wrote: > I guess what I am having trouble understanding is why a user of my > widget was unable to get updates if he has his GPS on all the time. > It's clear from his email to me that getLastKnownLocation() returned a > latitude/logitude of 0.0/0.0. This clearly indicates that a position > was not available. But if his GPS always on shouldn't I have gotten > back a value. Or is it dependent on whether one of his other apps ever > used the GPS to update itself? > > >>>>> "d" == davemac <[email protected]> writes: > > d> There's no magic to the PASSIVE_PROVIDER. While you don't need to > d> turn on a location provider to use passive, *somebody* must have > d> turned something on, otherwise there won't be any updated > d> locations. Passive let's you piggyback on someone else's location > d> updates. Which means, if your location-aware widget or clock is > d> updating often enough, passive should give you a reasonable > d> location. The challenge is to know when to trust a result from > d> passive. Anything that is location aware can enable a provider > d> (assuming it has permissions to do so), get a location result, > d> then disable that provider until it wants another location. This > d> has been the recommended advice if you don't need frequent > d> location updates so the location hardware is off as much as > d> possible. If you check for enabled location providers (using > d> getProviders() with the enabledOnly parameter), you could find > d> that they're all off. On the positive side, a location should tell > d> you when it was acquired (using getTime()). You could use that to > d> make a judgment call on whether or not the retrieved location is > d> recent enough for your app to trust it. > > d> - dave > > d> On Feb 20, 8:17�am, Mark Murphy <[email protected]> wrote: > >> On Sat, Feb 19, 2011 at 8:34 PM, Jake Colman <[email protected]> wrote: > >> > If my phone is running a location-aware clock or a > >> > location-aware weather widget, would getLastKnownLocation() be > >> > guaranteed to return a value in my app? > >> > >> There are no guarantees in life. > >> > >> For example, a "location-aware clock" might only check location > >> sporadically (e.g., daily). > >> > >> >�Or is that the point of the 'passive' provider? > >> > >> The passive provider is so you can get location data without > >> necessarily turning anything on (e.g., GPS radio). > >> > >> > With my widget installed on my HTC EVO, which runs the HTC > >> > standard location-aware clock, it always knows where it is as I > >> > travel from home to work. �That would imply that my app's call > >> > to getLastKnownLocation returned results since the phone knew > >> > where it was. �Does that make sense? > >> > >> Yes. Unless your app is only for you, though, you can't exactly rely on > >> that. > >> > >> -- > >> Mark Murphy (a Commons > >> > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > >> > >> Warescription: Three Android Books, Plus Updates, One Low Price! > > d> -- > d> You received this message because you are subscribed to the Google > d> Groups "Android Developers" group. > d> To post to this group, send email to [email protected] > d> To unsubscribe from this group, send email to > d> [email protected] > d> For more options, visit this group at > d>http://groups.google.com/group/android-developers?hl=en > > -- > Jake Colman -- Android Tinkerer -- 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
