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 loc
On Sun, Feb 20, 2011 at 11:40 AM, Jake Colman 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.
The GPS radio, if on continuously, will drain the battery in a few
hours. I feel fairly comfortable that
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. Bu
There's no magic to the PASSIVE_PROVIDER. While you don't need to turn
on a location provider to use passive, *somebody* must have turned
something on, otherwise there won't be any updated locations. Passive
let's you piggyback on someone else's location updates. Which means,
if your location-aware
On Sat, Feb 19, 2011 at 8:34 PM, Jake Colman 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 ch
> "MM" == Mark Murphy writes:
MM> getLastKnownLocation() may not have values, if nothing is causing the
MM> device to go find locations. You should consider using
MM> requestLocationUpdates() to get the device to figure out where you
MM> are.
Mark,
Can we get back to this commen
On Fri, Feb 18, 2011 at 2:14 PM, Jake Colman wrote:
> In my instance, I don't much care whether I get a fine or coarse
> location fix. And I cannot know whether the user will even have a GPS.
> Does this imply that I always just ask for a network fix?
Use the Criteria object to determine what lo
> "MM" == Mark Murphy writes:
MM> On Fri, Feb 18, 2011 at 1:25 PM, Jake Colman wrote:
>> Hmmm. Now we are getting somewhere. 'locationupdater' runs every
>> hour and updates a file with current location. 'sunrise' runs
>> every 60 seconds (or whatever) and reads the file for
On Fri, Feb 18, 2011 at 1:25 PM, Jake Colman wrote:
> Hmmm. Now we are getting somewhere. 'locationupdater' runs every hour
> and updates a file with current location. 'sunrise' runs every 60
> seconds (or whatever) and reads the file for the location. When the app
> is first installed to the
> "MM" == Mark Murphy writes:
MM> On Fri, Feb 18, 2011 at 12:57 PM, Jake Colman wrote:
>> Once I have a location, wouldn't getLastKnownLocation() return it
>> to me?
MM> Possibly. I have no idea how long Android holds onto those.
>> In this scenario, the appwidget would sta
On Fri, Feb 18, 2011 at 12:57 PM, Jake Colman wrote:
> Once I have a location, wouldn't getLastKnownLocation() return it to me?
Possibly. I have no idea how long Android holds onto those.
> In this scenario, the appwidget would start two services: sunrise and
> locationupdater. The Sunrise serv
I need to review the code and think about this before asking any dumb
questions. But one quick thought comes to mind.
Once I have a location, wouldn't getLastKnownLocation() return it to me?
If so, the "60-second" service can see whether it gave me a location and
use it. A second service can
On Fri, Feb 18, 2011 at 12:27 PM, Jake Colman wrote:
> Lets say you have a widget that displays the number of minutes remaining
> until Sunrise. The widget itself cannot, in its own context, determine
> its location for astronomical calculations since that takes too long.
> So we use a service to
Lets say you have a widget that displays the number of minutes remaining
until Sunrise. The widget itself cannot, in its own context, determine
its location for astronomical calculations since that takes too long.
So we use a service to do the actual work of figuring out where we are
and what tim
On Fri, Feb 18, 2011 at 10:43 AM, Mark Murphy wrote:
> On Fri, Feb 18, 2011 at 11:36 AM, Jake Colman wrote:
> > I am about to reread Mark's chapter on Location Provider from his Busy
> > Coders book. If I put my listener only asks for Network updates (coarse
> > location) it will still hear GPS
On Fri, Feb 18, 2011 at 11:36 AM, Jake Colman wrote:
> I am about to reread Mark's chapter on Location Provider from his Busy
> Coders book. If I put my listener only asks for Network updates (coarse
> location) it will still hear GPS updates too if available?
Not automatically via the LocationL
-developers@googlegroups.com
Subject: [android-developers] Re: Issue Determining the Location
>>>>> "T" == TreKing writes:
T> On Fri, Feb 18, 2011 at 9:20 AM, Jake Colman
T> wrote:
>> But doesn't the device always know where it is - as
> "T" == TreKing writes:
T> On Fri, Feb 18, 2011 at 9:20 AM, Jake Colman
T> wrote:
>> But doesn't the device always know where it is - assuming it has a
>> GPS, WiFi or network connection?
>>
T> Having those features doesn't mean much if they're not actually
T> used.
No, the device doesn't *always* know where it is. That's why
getLastKnownLocation() returns null sometimes.
Obtaining and maintaining a GPS fix (location) is expensive for the battery.
Only when needed locations are obtained and maintained.
I think that in API-level 8 a new location provider was
On Fri, Feb 18, 2011 at 9:20 AM, Jake Colman wrote:
> But doesn't the device always know where it is - assuming it has a
> GPS, WiFi or network connection?
>
Having those features doesn't mean much if they're not actually used. If
nothing on the device is requesting it's location, why would the
But doesn't the device always know where it is - assuming it has a GPS,
WiFi or network connection?
Other than getLastKnownLocation() is my code a reasonable paradigm for
getting the best available location fix?
> "MM" == Mark Murphy writes:
MM> getLastKnownLocation() may not have value
21 matches
Mail list logo
