On 6/10/13 6:53 PM, "flexcapaci...@gmail.com" <flexcapaci...@gmail.com>
wrote:
>I had forgot the other reason for bringing up this up but I remember it
>now.
>
>When creating mobile apps I try to support both portrait and landscape
>modes. The Flex framework has some support for this built in. When you
>switch from portrait to landscape and you have a state named "portrait" or
>"landscape" then the framework will switch to that state. However, the
>problem I run into is that I usually need to support more than those two
>states.
>
>Looking at one of my projects I have:
>
>
> <s:states>
> <s:State name="portraitOff" stateGroups="off, portrait"/>
> <s:State name="portraitOn" stateGroups="on, portrait"/>
> <s:State name="landscapeOff" stateGroups="off, landscape"/>
> <s:State name="landscapeOn" stateGroups="on, landscape"/>
> <s:State name="reportPortrait" />
> <s:State name="reportLandscape" />
> </s:states>
>
>Then I have a resize group handler that is manually handling setting the
>correct state:
>
>
> /**
> * Determines orientation
> * */
> protected function
>group1_resizeHandler(event:ResizeEvent):void
>{
>
> // get orientation
> if (height>width) {
> orientation = PORTRAIT;
> }
> else {
> orientation = LANDSCAPE;
> }
>
>
> // if on then set correct orientation
> if (currentState==PORTRAIT_ON ||
>currentState==LANDSCAPE_ON) {
> if (orientation==PORTRAIT) {
> currentState = PORTRAIT_ON;
> }
> else {
> currentState = LANDSCAPE_ON;
> }
> }
> else {
> if (orientation==LANDSCAPE) {
> currentState = LANDSCAPE_OFF;
> }
> else {
> currentState = PORTRAIT_OFF;
> }
> }
> }
>
>This is because when I had portrait and landscape defined, the framework
>would set the current state to one of those two values on orientation
>change, correct? BTW This should probably should be in getCurrentState()?
>
>I'm now aware of the basedOn property where I can inherit from the
>portrait
>or landscape state and I could have used it in my code above just as well
>as using state groups (which is more confusing to me looking back at this
>code).
FWIW, I have this vague recollection that Flex 4 states don't support
basedOn.
You might run into some issue at some point.
>
>This is the other situation I'm wondering if we can improve as well in
>this
>thread. It's really a case of, "if button.selected==true". Some sort of
>conditional branching in states.
I'm not sure I understand what you're getting at here.
>
>Alex, I'm trying to avoid binding expressions at the moment because one of
>my constraints (for personal reasons) is to keep MXML as close to pure
>vanilla XML as possible. If there are binding it is not "self contained"
>so
>to speak, meaning the compiler has to do some special processing, it has
>to
>know what a binding is.
Hmm. Doesn't the compiler have to do some special processing for current
states syntax, event handlers and a whole lot more? I'm curious about
what advantage there is to not using binding.
>However, I would like to see what that looks like
>if you have something.
One possibility is we use some other syntax to "bind" a property
conditionally to some other property. I haven't looked at what characters
we could use in xml, but suppose that # is valid.
In some simple form it could be:
property#conditionalproperty
So, if a TextInput width changes in portrait vs landscape (and assume we
have a boolean property on a document called "isPortrait"
<TextInput width#isPortrait="100" width="200" />
In this simple form, you have to have boolean properties on the document
for each conditional. That means you have put more complex expressions as
booleans in your script block. May or may not be messier than your
currentState setting logic.
Maybe it is possible to put any expression after the #. Maybe there is
something else besides {} we should use within the quotes.
FWIW, a goal for FlexJS binding is to do more of it "in the same document"
(no more separate XXWatcherSetupUtil) and fewer anonymous functions. I
hope to sniff out simple expressions and reduce them to more efficient
forms and evaluate them only when needed.
-Alex
