A quick practical question: is this actually supported at runtime by e.g. Android & iOS?
Am 25.10.2011 01:30, schrieb Jesse: > 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 <[email protected]>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 <[email protected]> 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 <[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? >>>>>> >>>>> >>>> >>> >> > -- GOFG - Get On Fat Guy http://www.gofg.at/ - powered by PhoneGap
