Re: DeviceOrientation comments

On Jul 23, 2010, at 5:59 AM, Dean Jackson wrote:

> 
> On 23/07/2010, at 6:18 PM, Maciej Stachowiak wrote:
> 
>> 
>> On Jul 22, 2010, at 9:31 PM, Dean Jackson wrote:
>> 
>>> 
>>> On 22/07/2010, at 9:53 PM, Dean Jackson wrote:
>>> 
>>>> My main comment/proposal is that Accelerometer Event should include the ability to return rotation around the 3 axes. 
>>> 
>>> I've realised this is pretty silly. A new event type is a better idea.
>>> 
>>> interface GyroscopeEvent : Event {
>>> readonly attribute double xRotationRate;
>>> readonly attribute double yRotationRate;
>>> readonly attribute double zRotationRate;
>>> 
>>> void initGyroscopeEvent(....
>>> 
>>> }
>>> 
>>> This way implementations without gyroscopes don't need to waste space sending null values. Similar to AccelerometerEvents, if you can't support it, you fire one event with all nulls.
>> 
>> A) It's not really a significant waste of space to have three more fields in a transient event.
> 
> My thinking was that there may be cases where you only want one but not the other, and this would save turning the hardware "on". The two pieces of hardware might also have significantly different sampling rates, so you could get into situations where the gyro is giving you data but the accelerometer component is null at that instant (or visa versa).
> 
>> B) For applications that care about both of these, are they likely to benefit from being able to process both accelerations and rotation rates at the same time? If so, one event will be more convenient for the developer.
> 
> I can only speak to Apple's API, but it allows you to separate or join, so I assume there are use cases both ways.

Then maybe the right solution is to have both separate and combined events, and you can register whichever you like.

> 
>> C) If an event is not supported, it seems more sensible to me if the implementation doesn't fire it at all, rather than repeatedly firing a fake event with no useful values.
> 
> I was just copying what the existing spec says about Accelerometer. I assume this was the solution for indication that the implementation supports the event but the hardware does not. There needs to be a way to detect that, otherwise you can't tell between a temporarily stationary device and an unsupported one.

I can see the use case for a developer wanting to know that the hardware does not support accelerometer or gyro or combined events. However, I expect most cases where the developer would like to know this, a way to synchronously ask if it's supported would be more convenient than registering for an event and waiting to get back an event that has null values in place of numbers. So maybe the design should aim for that direction.

Cheers,
Maciej

Received on Friday, 30 July 2010 04:05:26 UTC