RE: renaming enableHighAccuracy

I've said it before...

It seems like Apple have the right level of abstraction.  Specify what result you are looking for and let the device manage the details.  CLLocationAccuracy is a double, in metres.  No need for any secret understanding of what distinguishes 'true' from 'false'.  Just a nice, clear, easy to understand semantic defined in terms that can easily be related to the application.

http://developer.apple.com/iPhone/library/documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html#//apple_ref/doc/c_ref/CLLocationAccuracy


> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Allan Thomson (althomso)
> Sent: Friday, 3 April 2009 2:51 PM
> To: Andrei Popescu
> Cc: Angel Machín; public-geolocation
> Subject: 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/Re

> ference/CLLocationManager_Class/CLLocationManager/CLLocationManager.htm
> l#//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>
> 
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Friday, 3 April 2009 04:22:06 UTC