RE: skeleton Geolocation API

What about the case where the user has an external GPS puck that they can plug-in or unplug? In that case the availability of the API is transient. I don't think having the geolocation object become null is a good solution. An error regarding "NotAvailable" seems like a cleaner method.

-----Original Message-----
From: Aaron Boodman [mailto:aa@google.com]
Sent: Thursday, July 24, 2008 1:53 PM
To: Andrei Popescu
Cc: Alec Berntson; Shyam Habarakada; Chris Prince; Doug Turner; public-geolocation@w3c.org
Subject: Re: skeleton Geolocation API

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:57:20 UTC