Re: Sensor API feedback: OrientationData

Okay... That makes perfect sense. I have shown in a couple threads that we
aren't talking about alot of power and there is a way to turn off the
gyroscope sensor via removing the listener. I am wondering why this isn't
good enough.

Thanks again!

Regards,
Doug
On Mar 11, 2012 1:40 PM, "SULLIVAN, BRYAN L" <bs3131@att.com> wrote:

> Because the UX impact of an inefficient API (e.g. re battery impact,
> processor load, etc) will cause users to avoid apps that use the API. Thus
> the intent of the API (to serve use cases) will not be met.
>
> Thanks,
> Bryan Sullivan
>
> On Mar 9, 2012, at 5:59 PM, "Doug Turner" <doug.turner@gmail.com<mailto:
> doug.turner@gmail.com>> wrote:
>
>
> Thanks for the input.  I'd like to know why you think that.
>
> On Mar 9, 2012 2:27 PM, "SULLIVAN, BRYAN L" <bs3131@att.com<mailto:
> bs3131@att.com>> wrote:
>
> I agree with Jose, these types of optimizations are necessary in the API.
> An API which does not perform some reasonable signal integration (or enable
> the app to specify the event rate /conditions) will be ineffective.
>
>
>
>
> -------- Original message --------
> Subject: Re: Sensor API feedback: OrientationData
> From: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es<mailto:jmcf@tid.es>>
> To: Doug Turner <doug.turner@gmail.com<mailto:doug.turner@gmail.com>>,"
> public-device-apis@w3.org<mailto:public-device-apis@w3.org>" <
> public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
> CC: Re: Sensor API feedback: OrientationData
>
>
> Hi Doug,
>
> The problem with the Device Orientation Events spec is that there is no
> way for an application to specify how often the event should be raised by
> the UA. For instance Firefox Mobile implementation raises hundreds of
> events per second and when I implemented a Compass app I had to create a
> wrapper to filter out events to avoid collapsing the browser with
> thousands of repaints of the Compass canvas. But in the end battery can be
> drained due to this fact.
>
> I totally agree that We should not confuse developers, and we should have
> only one mechanism but Device Orientation has flaws.
>
> Thanks best
>
> El 02/03/12 20:12, "Doug Turner" <doug.turner@gmail.com<mailto:
> doug.turner@gmail.com>> escribió:
>
> >Hi Jonas, Tran,
> >
> >I am concerned that there is overlap between the Sensor Api and the
> >DeviceOrientaiton Spec:
> >   http://dev.w3.org/geo/api/spec-source-orientation.html
> >
> >I worry that web developers will not know which API to use.  Tran, have
> >you looked at our draft specification?  I am wondering how we can make
> >these two efforts result in something that is consistent and pleasing to
> >developers.
> >
> >
> >
> >Answer to questions Jonas raised:
> >
> >> I'm having trouble understanding the difference between the
> >>OrientationData and AccelerationData sensors.
> >
> >They are measuring different things.  Orientation has to do with rotation
> >about an axis measured by a gyro.  Acceleration will tell you change in
> >speed measured by an accelerometer.
> >
> >> it's impossible to tell the difference between gravity and acceleration.
> >
> >True. http://en.wikipedia.org/wiki/Equivalence_principle
> >
> >> is the OrientationData sensor simply a convenience function on top of
> >>the AccelerationData sensor?
> >
> >Both tell you something about the reference.  You really want to know
> >both acceleration and orientation to fully understand what is happening
> >to the reference.  You can't always determine orientation from
> >acceleration or visa versa.
> >
> >> Could someone explain the meaning of the alpha, beta and gamma values?
> >
> >The DeviceOrientation spec goes into great detail about what these values
> >are.
> >
> >
> >
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>

Received on Sunday, 11 March 2012 21:09:37 UTC