Re: skeleton Geolocation API

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.

Same goes for the getCurrentPosition() scenario: if no error callback
was specified, and there is an error, the successCallback will never
be called. Please note that we can't invoke the successCallback with
null in such cases, since that would force the developer to check for
errors anyway.

So how about having both callbacks required?

Thanks,
Andrei



> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org] On Behalf Of Alec Berntson
> Sent: Thursday, July 24, 2008 9:48 AM
> To: Aaron Boodman; Shyam Habarakada
> Cc: Chris Prince; Doug Turner; public-geolocation@w3c.org; Andrei Popescu
> Subject: RE: skeleton Geolocation API
>
>
> That was the use case I was thinking about for 1. I don't know if this is a strong enough reason to make the callback optional
> I agree with 2.
> As for 3, I don't think there is a permanent, 'no more location ever' error. I agree that the implementation will just not send callbacks if the provider(s) (or privacy controls) are not currently giving location data.
>
> -----Original Message-----
> From: Aaron Boodman [mailto:aa@google.com]
> Sent: Wednesday, July 23, 2008 11:52 PM
> To: Shyam Habarakada
> Cc: Chris Prince; Doug Turner; public-geolocation@w3c.org; Alec Berntson; Andrei Popescu
> Subject: Re: skeleton Geolocation API
>
> On 7/23/08, Shyam Habarakada <shyamh@microsoft.com> wrote:
>>  1. Are there use-case where errors SHOULD be ignored?
>
> Should? No, but I can imagine use cases where a developer simply
> doesn't care about errors and wants to ignore them. For example, say I
> call watchPosition() to trace a user's position on a map. I might
> implement it like this:
>
> 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
>
> For this hypothetical usage, I don't really care about getting errors.
>
>>  2. If we say errorCallback MUST be provided and a caller does not comply, what is the desired runtime behavior? Throw an exception?
>
> Usually, if a parameter is required, then the behavior is to throw
> when the function is called. That makes sense here too.
>
>>  3. Are there error scenarios where we MUST signal the caller to invoke clearWatch(watchID)?
>
> No. If the error is permanent, the implementation will just never call
> either callback again.
>
> - a
>
>
>
>

Received on Thursday, 24 July 2008 19:11:27 UTC