incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viras <vi...@users.sourceforge.net>
Subject Re: [PROPOSAL] Orientation Interface
Date Tue, 25 Oct 2011 06:00:49 GMT
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 <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?
>>>>>>
>>>>>
>>>>
>>>
>>
> 

-- 
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by PhoneGap

Mime
View raw message