Re: Regarding orientation lock and more

Hi Lars, 
Apologies for the delay. 

On April 24, 2014 at 7:12:16 AM, Lars Knudsen (larsgk@gmail.com) wrote:

<snippin' to focus just on orientation ... we can address the other stuff relating to audio and stopping the screen from dimming in the future>

> For the sake of relevance, let's focus on the accelerometer ;)
>  
> If I design a game and I am going to use the acceleroemeter as input, in
> 99% of the cases I will be interested in having full control over the
> auto-rotate so the device behaves exactly like I want when the user
> moves/rotates the device around. For this I need an orientation lock (so
> far so good) - but I also need to be 100% sure that my accelerometer
> readings are always the same relative to the orientation chosen - no matter
> what device my users choose to run my game on.


Ok, so first thing we need to do is create "the reference app". That supports orientation locking and maybe a accelerometer visualization. 

Filed bug:
https://github.com/w3c-webmob/orientation/issues/3

> Currently, we are given the first iteration of a proposal for an
> orientation lock that has settings like portrait/landscape and
> primary/secondary - and even allowed vendors to have "landscape oriented
> devices" and "portrait oriented devices", affecting anything accelerometer
> and orientation related - almost to the pleasing of the individual branch
> of a given mobile device manufacturer implementing the stack (in the end)
> providing the values and behavior to the developer and end user.
>  
> I have seen - even within the same company - that these mappings were wired
> up totally differently depending on device line, base platform and if this
> by coincidence was considered mostly a landscape or mostly a portrait
> device.
>  
> What we need it to keep things robust and stable for the people who are
> going to use these APIs/features and not require them to purchase a huge
> range of different devices to test on (and do mappings for) and I have some
> points I'd really like to get across that I know will make things easier
> for all:
>  
> 1. decide on ONE (either portrait or landscape) "0 degree rotation" =
> "device up" that will trickle through all specs relating to orientation.
> In practice, this would mean that lockOrientation("0deg") ~
> (x,y,z)=(0,1,0) , where lockOrientation could be an async request telling
> if the angle was allowed, etc. - e.g. more options could be given
> ("0deg,180deg") and maybe "180deg" is set and returned...The important
> thing here is that the developer has a consistent way of mapping the locked
> orientation to the data coming from the accelerometer.


Filed bug on spec:
https://github.com/w3c/screen-orientation/issues/14

> 2. if we really want to win the hearts of native app developers, the whole
> spec'ing community needs to consider some changes:
>  
> A. Make a dependency graph of all specs (in use) and how they relate to
> one another (e.g. deviceorientation and lockorientation touch base on:
> rotation, accelerometer, etc.). This holistic view can help make APIs
> more consistent and the whole "develop a web app" experience more coherent

Filed bug: 
https://github.com/w3c-webmob/orientation/issues/4

> B. Make sure that example apps are made and that average joe developers
> are invited to test APIs - BEFORE THEY GO OUT OF DRAFT (or are shipped in
> stable => written in stone)

This above is the same as bug #3 (see link a few paras above). We might build additional sample apps, but one should be sufficient for now.

Received on Friday, 2 May 2014 22:12:45 UTC