RE: renaming enableHighAccuracy

Andrei - see my responses below within <at>   </at>

If there is a group desire to keep the attribute then maybe we can define the attribute in a way that allows the device "intelligence" to switch between low|high power modes without having to have that intelligence in the application. If we did that, that might satisfy my concern.

Regards

Allan

>> Here are a couple of examples:

- You are developing a gadget application that lives on the desktop of
a mobile device. This means it is most likely running all the time.
Your app is showing POI in the user's vicinity / offers search results
relevant to the user's location / shows where the user's friends are /
etc. Since the application is long running (it's on the desktop),
would you say it is reasonable for a developer to set lowPower to
true?

<at> At what point does the developer of the application switch to lowPower? An application has no way of knowing how much longer the application will run. So presumably the application will determine that after X time of running that it should revert to lower power. However, when reverting to that lower power the location accuracy will potentially change from good accuracy to less than good accuracy and the user has no way of understanding why it changed. The application would presumably have to provide a means for the user to switch back to higher power again.
</at>

- You are developing some app that offers turn-by-turn directions.
That is a user-driven action that clearly requires accurate position
fixes, so would you say it is reasonable to use the default values of
the API?

<at> Agreed. But what happens if the user stops in the middle of the route and has a coffee for 1 hour. Does the application keep running at high power? My point is that without intelligence to know when to stop running in high power vs low power the application would just keep running as is. 

One solution to this could be if the device has a motion sensor attached then it could determine that the device is not moving so stop location determination until it detects movement again. That way the device intelligently decides what is good for location and what is good for power consumption on the device. No need for an application to tell it. 

Also what happens when the user enters a building and WLAN location can be provided much more easily than say GPS location (which doesn't work inside as well)? Does the application now know that low power isn't needed cause the location is now being provided by a lower powered option? Any the underlying drivers on the device can determine that change and automatically switch whereas the application would have to have that logic built into it.
</at>

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.

<at> My point is that the attribute can't be set by applications that don't understand all of the parameters that affect power consumption of location. Applications don't have that visibility but you are asking them to set this parameter. That is my objection.
</at>

Finally, let's have a look at what other Location APIs do:

IPhone:
http://developer.apple.com/iPhone/library/documentation/CoreLocation/Reference/CLLocationManager_Class/CLLocationManager/CLLocationManager.html#//apple_ref/occ/instm/CLLocationManager/startUpdatingLocation

That method takes a desiredAccuracy attribute: "The desired accuracy
of the location data. (...) You should assign a value to this property
that is appropriate for your usage scenario. In other words, if you
need only the current location within a few kilometers, you should not
specify kCLLocationAccuracyBest for the accuracy. Determining a
location with greater accuracy requires more time and more power".
Note the word "power" at the end.

<at> The statement on greater accuracy requires more time and more power is just misleading for certain location determination techniques. For GPS or Assisted GPS this might be true but it's not true of other techniques like WLAN location determination. If the application actually knew a WLAN technique was available then they could still get good accuracy without consuming a lot of power. 
</at>

<snip>

(FYI, also have a look at
http://wiki.forum.nokia.com/index.php/KIJ000875_-_GPS_Satellite_fix_results_in_reduced_battery_life
to see the impact of GPS on a modern device)

<at> And that is why GPS is not necessarily the right location determination technique in all environments.
</at>

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") ?

<at> My primary objection is that applications will not necessarily know when to set the attribute to one value or another. And if they do set the attribute, they don't have the intelligence to change the value if the RF environment changes dynamically. Hence optimal performance of a location application is not achieved because when the application sets the attribute to low power the user experience may not get the best location possible for the deployment environment.
</at>

Received on Friday, 3 April 2009 03:51:34 UTC