Re: Sensor API feedback: OrientationData

On Mar 6, 2012, at 10:38 PM, Jonas Sicking wrote:

> On Tue, Mar 6, 2012 at 8:04 AM, Doug Turner <doug.turner@gmail.com> wrote:
>> Jonas,
>> Thanks for your feedback.  It is kind of a shame that there is a lot of overlap with the Sensor API.  I am happy that Tran is going to drop the Device Motion bits from this DAP spec.
> 
> I'm not convinced that we should do that. But let's see where this
> thread is heading.

I disagree and think the DAP overlap is clearly a mistake.  It will lead to develop confusion.

> I'm very interested in getting feedback on this. Does anyone know if
> keeping the sensors on matters at all battery-wise? Does it draw more
> power if results are retrieved 60 times per second vs. twice a second?

If it is on, it is on.  There, of course, is power associated with propagating the event from the sensor to the application to the java context.

Also, you will want to keep them on while using them since both devices tend to drift.  Having them both on, they can recalibrate each other.  

Lastly, lets assume that you can save a bunch of power by cycling sensors.  I tend to think this an implementation detail.  UA should conserve power.  Implementation can clearly see what the timeouts are and power up and down the sensors as they see fit.


> If we don't need to worry about this I agree that the API likely
> should be significantly changed.

Right.

>> 
>> Third, the problem with adding public accessors to every Device Motion property, if you think about it, is that we don't always know what the answer is.  Sometimes, we have to power up the accelerometer or gyro and wait.  So, there are times when the ua can't return an answer.  I don't think we should throw or something awful like that.  Therefore, we do not have anything like that.  Also, according to the Device APIs Requirements and Design Decisions (http://dev.w3.org/2009/dap/api-reqs/) methods (like a getter for device motion property) "must support asynchronous, cancelable operation".  So, maybe with the Joy stick API you don't have to power things up, but with many sensors you do.
> 
> This is indeed a problem. However just throwing up our hands and
> pushing the problem to authors is the wrong solution IMHO.


Well, this isn't a problem in my mind.  Access sensor values through a callback works perfectly well.  Geo does that and is very popular.  We didn't get much (any?) feedback that users really wanted to have getters instead of callbacks.  IMO, over complex and not required.

Fwiw, here is the code that you need to implement what you are talking about:

window.addEventListener("devicemotion", function (event) {
    window.accelerationIncludingGravity.x = event.accelerationIncludingGravity.x;
    window.accelerationIncludingGravity.y = event.accelerationIncludingGravity.y;
    window.accelerationIncludingGravity.z = event.accelerationIncludingGravity.z;
   }, false);


> I suspect
> that games are the main use case of this type of API and the feedback
> I've received from game developers is that they all end up writing
> exactly the same code to use the stream of events into a state
> variable which is then polled.

I claim you can add this boilerplate to a library.  We should be providing primitives for the most part.

Doug