Re: renaming enableHighAccuracy

On Wed, Apr 1, 2009 at 5:30 PM, Allan Thomson (althomso)
<althomso@cisco.com> wrote:
>
> I still don't see how this attribute can be set intelligently by applications and until I understand that, I don't get why this attribute is so important in a standard location API.
>

Fair enough. 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?

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

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.

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.

Android:
http://developer.android.com/reference/android/location/Criteria.html

"A class indicating the application criteria for selecting a location
provider. Providers maybe ordered according to (...) power usage
(...)".

Nokia S60:
http://library.forum.nokia.com/index.jsp?topic=/S60_5th_Edition_Cpp_Developers_Library/GUID-07F7CEA3-DC49-40E1-B313-5AAC1A5A3F8D_cover.html

"IMPORT_C TInt SetOrderPowerConsumption(TOrder aOrder); Assigns a
priority to the power consumption of a positioning technology when
selecting a positioning module."

(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)

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

Thanks,
Andrei

Received on Thursday, 2 April 2009 10:15:25 UTC