pseudo xui code ... a simple case
// image view should be freely oriented
function showImageView() {
x$("#listView").css({display:'none'});
CB.supportedOrientations = [0,90,-90,180];
x$("#imageView").css({display:'block'});
x$("#imageView .closeBtn").click(showListView);
}
// list view always wants to display in portrait or portrait upsidedown
function showListView() {
x$("#imageView").css({display:'none'});
CB.supportedOrientations = [0,180];
x$("#listView").css({display:'block'});
x$("#listView li").click(function(e){
// assume some DOM modification based on selected item.
showImageView();
});
}
On Mon, Oct 24, 2011 at 3:11 PM, Brian LeRoux <[email protected]>wrote:
> k, so imp semantics aside for a second. can you futz up a quick
> example of how you would call the code? (rather than how you'd impl
> it)
>
> want to understand use cases here..
>
>
>
> On Mon, Oct 24, 2011 at 3:00 PM, Jesse <[email protected]> wrote:
> > Storing values in an object IMHO adds little or no value.
> > The Array has the additional benefit of providing a preferential order as
> > well, for the case where the requested 'supportedOrientations' does not
> > contain the physical current orientation.
> >
> > I do see a benefit to have defined type values, but deviating from the
> > numeric values only makes things more difficult to understand. The
> numeric
> > values were chosen because these ARE the values passed to listeners of
> the
> > 'orientationchange' event
> > On most platforms, window.orientation already contains an integer value
> > which is one of : 0,90,-90,180
> >
> > north|south| .. imply that we are talking about the compass direction
> that
> > the device is facing, which absolutely not the case.
> >
> > We could make it absolutely understandable to all by providing a static
> > human-readable version of the values. Like this:
> >
> > // This definitely SHOULD be namespaced
> > OrientationType = {
> > PORTRAIT:0,
> > LANDSCAPE:90,
> > LANDSCAPE_LEFT:90,
> > LANDSCAPE_RIGHT:-90,
> > PORTRAIT_RIGHTSIDEUP:0,
> > PORTRAIT_UPSIDEDOWN:180
> > };
> >
> > // RE: I can see more orientation
> > // settings emerging in the future. For example, future devices may have
> a
> > // fluid orientation ....
> >
> > This should not be confused with the devicemotion or accelerometer apis
> > which provide much more granular control when needed. Orientation values
> are
> > intended to be discrete values and not a continuous series. The only
> other
> > orientations I foresee are possible additions of FACEUP and FACEDOWN,
> > although they are primarily just modifiers in another dimension to the
> > existing values.
> >
> >
> >
> >
> >
> >
> > On Mon, Oct 24, 2011 at 2:17 PM, Brian LeRoux <[email protected]> wrote:
> >
> >> Good suggestions mr. brooks. Also, we might as we get used to this, it
> >> will be spaced under CB. Also, I think we could be more colloquial:
> >>
> >> CB.orientation.supports = {
> >> north:true,
> >> south:false,
> >> east:false,
> >> west:true
> >> }
> >>
> >> if (CB.orientation.supports.north) {
> >> // ...etc
> >> }
> >>
> >> Is there API utility in the absolute #'s in an array that we're
> >> missing here Jesse? How are ppl using orientation?
> >>
> >
>
