Yah I thought they already had orientationchange. I guess the issue with the
event in js is that there's no way to prevent the change from happening at
that point.
On Oct 26, 2011 3:15 AM, "Jesse" <purplecabb...@gmail.com> wrote:
> Patrick:
> I agree we should not pollute the root of our object tree.
> I currently do not foresee any other methods on the CB.rotation object
> though, is there another field that it makes sense to group it with?
> CB.device.allowOrientations(... ); // ?
> CB.sensors.orientation.allow(... ); // ?
>
> Viras, Dave :
>
> We can definitely prevent the view changing to a new orientation based on
> device movement on all platforms.
>
> The more difficult case is when, for example, the device is already in
> landscape, and we set a new value for the 'allowed' orientations that does
> not include landscape.
> ie. precluding the current orientation
> These are considered to be attempts OR requests and not guaranteed.
>
> Android:
>
> public void setRequestedOrientation (int requestedOrientation)
> Since: API Level 1
> Change the desired orientation of this activity. If the activity is
> currently in the foreground or otherwise impacting the screen orientation,
> the screen will immediately be changed (possibly causing the activity to be
> restarted). Otherwise, this will be used the next time the activity is
> visible.
> Parameters
>
> requestedOrientation An orientation constant as used in
> ActivityInfo.screenOrientation.
>
> iOS 5
> attemptRotationToDeviceOrientation
> Indicates that the value returned by
> shouldAutorotateToInterfaceOrientation:
> has changed.
>
> + (void)attemptRotationToDeviceOrientation
> Discussion
> If the current interface orientation does not match the current device
> orientation, a rotation may occur, provided all relevant view controllers
> now return YES from the shouldAutorotateToInterfaceOrientation: method.
>
> Availability
> Available in iOS 5.0 and later.
>
> In iOS 4 it is not possible to force an orientation change, but it is
> possible to prevent a future orientation when the device is moved.
>
> Dave:
> All the devices already support the event 'orientationchange' on the window
> object.
> so more like this :
> window.addEventListener("orientationchange",function(e){
> // do something
> },false);
>
> Cheers,
> Jesse
>
>
>
>
>
> On Tue, Oct 25, 2011 at 11:48 PM, dave johnson <dave.c.john...@gmail.com
> >wrote:
>
> > +1 to Patrick's comment about jquery style same name like
> > CB.rotation.allow() for get / set.
> >
> > +1 to Viras as well since can we actually prevent an orientation at
> > runtime on any of the platforms we are interested?
> >
> > If we can indeed prevent the view from changing due to orientation
> > change, then I would think we should be doing it like devicemotion etc
> > and document.addEventListener('orientationchange', function(e) {if
> > (e.landscape) return false;}); Once we have that in place we can
> > consider sweetening it up with CB.rotation.allow().
> >
> > On Mon, Oct 24, 2011 at 6:33 PM, Patrick Mueller <pmue...@gmail.com>
> > wrote:
> > > On Mon, Oct 24, 2011 at 18:54, Brian LeRoux <brian.ler...@nitobi.com>
> > wrote:
> > >
> > >> Ok, so a setter --- think that was the key missing piece of info. b/c
> > >> this is behavioral we'd probably be better off making it a function
> > >> call:
> > >>
> > >> CB.supportOrientation(0, 180)
> > >>
> > >
> > > Quick +1 on not using setters/getters. Pain to deal with, IMO, from a
> > > debugging point of view. One less thing for users to learn - they
> > already
> > > know how to use functions, setters/getters are ... different.
> > >
> > > Oh, and you can't naturally define them in CoffeeScript :-)
> > >
> > > --
> > > Patrick Mueller
> > > http://muellerware.org
> > >
> >
>
