Re: Regarding orientation lock and more

Hi Marcos,


On Sat, May 3, 2014 at 12:12 AM, Marcos <marcos@marcosc.com> wrote:

> Hi Lars,
> Apologies for the delay.
>
np - I am glad that it was picked up :)

>
> 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>
>
ok

>
> > 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.
>
Sounds good - we might need a few simplified ones to cover different cases
(e.g. to support "labyrinth game", "flight sim", etc.).

>
> 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.
>

ok - then maybe just going for a rolling ball/labyrinth that can be locked
to different directions (e.g. 0, 90, 180 and 270 degrees relative to "std
portrait up") to quickly see if the ball rolls in the right direction on
all devices?