Re: renaming enableHighAccuracy

On Fri, Apr 3, 2009 at 1:31 PM, Angel Machín <angel.machin@gmail.com> wrote:
> Hi Andrei,
>
> On Thu, Apr 2, 2009 at 12:14 PM, Andrei Popescu <andreip@google.com> wrote:
>
>> In general, if you don't care about this issue or you want the best
>> results you can get, you can just use the API with its defaults
>> values. For those cases where you think the usage of this API may be
>> detrimental to the user experience (e.g. by draining a phone's battery
>> and preventing the user from making phone calls), I feel that this
>> attribute may be useful.
>
> Yes, but suppose that you are using a web application requiring high
> accuracy location while you are indoors. In this case, the UA will
> switch the GPS on trying to find satellites maybe for minutes, all
> that resulting in a useless waste of time and battery.
>

Yes but how is the 'lowPowerOnly' attribute creating a problem in this scenario?

Also, what is your concrete suggestion here? I am a bit confused.

>> I understand extremely well that we're designing a much higher-level
>> API than any of the above, but I think having a simple boolean
>> attribute offers quite a bit of value with very little cost. But ok,
>> if the majority of the people disagree, we'll take it out. But before
>> that, can you please summarize the main reasons why you don't want
>> this in the API (perhaps other than "devices will get better in XYZ
>> years") ?
>
> The parameter could be useful but I think that this discussion is
> mainly about who controls the location hardware to be used: developers
> or users.... or both.
>
> Maybe developers writing applications with the Location APIs you
> posted (iPhone and Android)  use these accuracy options to build UIs
> allowing users to manually set them to the value they prefer.
>

Maybe or maybe not. Nothing prevents a UA implementer from doing that,
anyway. All I am saying is that the application itself should be
allowed to have a say about what its power requirements are.

Thanks,
Andrei

Received on Friday, 3 April 2009 12:53:23 UTC