incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [PROPOSAL] Orientation Interface
Date Mon, 24 Oct 2011 23:30:45 GMT
RE: setter, I agree, setting an Array is not the best choice.

I prefer naming more like this :
CB.setSupportedOrientations(0,180);
This provides more indication to the developer that they are setting all of
them, where supportOrientation( ) might imply that you are simply adding a
value to the list.
Again, it's semantics.

RE: CB.config.supportOrientation
moar semantics :
config does not add much value in my mind, config implies that values are
known up front.
This could be a level above the functionality I intended to discuss,
ex. within a view framework, where each view 'config' defines some values
that a viewManager maps to a call to CB.setSupportedOrientations()

RE: config.xml
- this could define the complete set of available orientations, so an app
that should only ever display in portrait would simply set the value here,
and never worry about the runtime apis
- default value presumably all orientations



On Mon, Oct 24, 2011 at 3:54 PM, Brian LeRoux <brian.leroux@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)
>
> ...
>
> But smells like configuration and less like something that should
> dynamically set/reset --- and probalby has some sensible defaults that
> could exist/be overwrit by config.xml ... how about:
>
> CB.config.supportOrientation(0, 180)
>
> ???
>
>
> On Mon, Oct 24, 2011 at 3:28 PM, Jesse <purplecabbage@gmail.com> wrote:
> > 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 <brian.leroux@nitobi.com
> >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 <purplecabbage@gmail.com> 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 <b@brian.io> 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?
> >> >>
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message