W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2008

Re: skeleton Geolocation API

From: Aaron Boodman <aa@google.com>
Date: Thu, 24 Jul 2008 13:53:09 -0700
Message-ID: <278fd46c0807241353h4a8216a5gbe428391991cb6e8@mail.gmail.com>
To: "Andrei Popescu" <andreip@google.com>
Cc: "Alec Berntson" <alecb@windows.microsoft.com>, "Shyam Habarakada" <shyamh@microsoft.com>, "Chris Prince" <cprince@google.com>, "Doug Turner" <doug.turner@gmail.com>, "public-geolocation@w3c.org" <public-geolocation@w3c.org>

On Thu, Jul 24, 2008 at 12:10 PM, Andrei Popescu <andreip@google.com> wrote:
> Hi,
>
> On Thu, Jul 24, 2008 at 6:00 PM, Alec Berntson
> <alecb@windows.microsoft.com> wrote:
>> What happens when a system doesn't support location (no providers)? Does the success callback just never return anything? Or is that a compelling reason to require the errorCallback to see is location is available?
>>
>
> That's a good point. I'm starting to think that the API should be
>
> void getCurrentPosition(successCallback, errorCallback, [positionOptions]);
> int watchPosition(successCallback, errorCallback, [positionOptions]);
>
> Aaron mentioned the following scenario:
>
> 1. Show status UI telling the user we are looking for a fix, with a
> button to cancel
> 2. Call watchPosition()
> 3. When we get the first fix, clear the status UI and update the position
> 4. For each new fix, update the position again
>
> However, if this is running on a device that doesn't have any location
> provider available (e.g. there's no GPS onboard and, for some reason,
> cellular or wifi data isn't available either), then the above scenario
> will appear to freeze at step 2. Due to the diversity of HW that will
> be running this API, I don't think too many app developers will afford
> to assume that everything will just work.

That was exactly my point with having the cancel button in the status:
that the developer would not care what happens in step 2. This UI
basically normalizes the behavior when the data is slow and when it
isn't available at all. I see this sort of thing done from time to
time and I think it is a valid use.

Devices which completely lack HW support are a really interesting
point. My opinion would be for that case, the value of
window.navigator.geolocation should be null, or something similar. The
reason is that as a developer, I don't want to even show any UI
offering to geolocate if the device has no hope of doing that.

> So how about having both callbacks required?

I still feel that onFailure should be optional. It is a meaningful
operation to call this API and not handle errors, and we shouldn't try
and babysit. There is also no real downside to making the parameter
optional.

- a
Received on Thursday, 24 July 2008 20:53:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT