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).
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.
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. However, I would like to see what that looks like
if you have something.
On Fri, Jun 7, 2013 at 3:08 AM, Maxime Cowez <maxime.co...@gmail.com> wrote:
> @alex The polymer project has an interesting take on the conditionals
> you're proposing.
> Some examples:
>
> https://github.com/Polymer/mdv/blob/master/examples/how_to/conditional_template.html
>
> https://github.com/Polymer/mdv/blob/master/examples/how_to/conditional_attributes.html
>
>
> On Fri, Jun 7, 2013 at 9:45 AM, Cosma Colanicchia <cosma...@gmail.com
> >wrote:
>
> > The PROP_CHANGING/PROP_CHANGED event pair concept is interesting, even
> if I
> > still don't get the whole picture of how it will be working.
> >
> > However, please note that I was writing thinking about possible (and
> > incremental) improvements the current MXML states management of Flex 4.x,
> > personally I don't know FlexJS well enough to be of any help - sorry but
> I
> > didn't have the chance yet to really look into it, beside reading the
> > messages on the list.
> >
> >
> >
> > 2013/6/6 Alex Harui <aha...@adobe.com>
> >
> > > To be clear, I'm mainly concerned about how to implement this in
> FlexJS.
> > > I'm not planning to try to upgrade or retrofit this into the current
> Flex
> > > SDK, but someone else is certainly welcome to take that on.
> > >
> > > My thoughts around effects in general is that, in FlexJS, you have
> > > replaceable models. The models that will work with effects/transitions
> > > will probably have a PROP_CHANGING/PROP_CHANGED event pair, where the
> > > CHANGING is cancelable and would probably serve as the trigger.
> > >
> > > On 6/6/13 9:13 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote:
> > >
> > > >AFAIK:
> > > > - currently states also play a role in the skinning contract of a
> > > >skinnable component (skinStates)
> > > > - states are supported by transitions management
> > > >
> > > >The first one maybe could be dropped, resulting in a "relaxed"
> skinning
> > > >contract: the button may have bindable "model" properties such as
> > > >isFocused
> > > >or isDefault, and the skin could adjust its visuals looking at their
> > > >values
> > > >(currently, MXML skin are enforced by the compiler to declare as
> states
> > > >all
> > > >the skin states in the host component metadata - but if I remember
> > > >correctly AS skins don't have this restriction).
> > > >
> > > >However, I don't know if a transition management like the current one
> > > >could
> > > >be adapted to work without states.. the includeIn and
> property.state=...
> > > >MXML syntax allow to declare the "final value" of a property in a
> > > >specified
> > > >state, but unlike a binding that would apply the value immediately,
> > when a
> > > >transition is defined that value will only be applied at the and of
> the
> > > >entire transition, giving the effects a chance to provide smooth
> visual
> > > >changes in between. In other words, is a way to decuple the
> > > >"focusGroup.alpha" view property from the (ideal)
> > > >"hostComponent.isFocused"
> > > >model property, thus allowing effects to play in between - a kind of
> > > >decoupling that could probably be achieved by defining a lot of
> > > >intermediate variables in the view layer, but the resulting code would
> > be
> > > >ugly and hard to manage.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >2013/6/6 Alex Harui <aha...@adobe.com>
> > > >
> > > >> Good stuff.
> > > >>
> > > >> Today, you can sort of do this with fx:Declarations/fx:Component,
> but
> > it
> > > >> isn't in-line, just in the same document. Do either of you have a
> > skin
> > > >>or
> > > >> component that could truly take advantage of that?
> > > >>
> > > >> And still, you end up writing code to set currentState according to
> > some
> > > >> other set of properties, which is why I'm wondering why you guys
> would
> > > >> rather manage the code that sets currentState vs just tying the
> > visuals
> > > >>to
> > > >> other properties.
> > > >>
> > > >> -Alex
> > > >>
> > > >>
> > > >> On 6/6/13 3:19 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote:
> > > >>
> > > >> >Probably just a sintax choice: having them all toghether could be
> > > >>useful
> > > >> >to
> > > >> >quickly have an outlook of the states stuff when you open an MXML
> > > >> >document,
> > > >> >instead of searching for a number of sparse <s:states> blocks (they
> > are
> > > >> >the
> > > >> >state of the main MXML component, after all) - on the other hand,
> > > >>defining
> > > >> >them inline maybe feels "right" and the resulting code snippets are
> > > >>more
> > > >> >manageable.
> > > >> >
> > > >> >
> > > >> >2013/6/6 jude <flexcapaci...@gmail.com>
> > > >> >
> > > >> >> Yeah. I like the state delegates. What if you took it one step
> > > >>further
> > > >> >>and
> > > >> >> added inline states?
> > > >> >>
> > > >> >> <s:states>
> > > >> >> <s:State name="up"/>
> > > >> >> <s:State name="down"/>
> > > >> >> <s:State name="over"/>
> > > >> >> </s:states>
> > > >> >>
> > > >> >>
> > > >> >> <s:Group id="focusGroup">
> > > >> >> <s:states>
> > > >> >> <s:State name="nonFocused"/>
> > > >> >> <s:State name="focused"/>
> > > >> >> </s:states>
> > > >> >>
> > > >> >> <s:transitions>
> > > >> >> <s:Transition fromState"nonDefault" toState"default">
> > > >> >> <s:Fade target="{focusRect}" alphaFrom="0"
> > > >>alphaTo="1"/>
> > > >> >> <s:/Transition>
> > > >> >> </s:transitions>
> > > >> >>
> > > >> >> <s:Rect id="focusRect" top="0" bottom="0" left="0"
> right="0"
> > > >> >> alpha="0" alpha.default="1"/>
> > > >> >> <s:stroke><s:SolidColorStroke color="..."/></s:stroke>
> > > >> >> </s:Rect>
> > > >> >> </s:Group>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> On Thu, Jun 6, 2013 at 2:12 AM, Cosma Colanicchia <
> > > cosma...@gmail.com
> > > >> >> >wrote:
> > > >> >>
> > > >> >> > Multiple states using spaces (e.g. currentState="up default")
> > looks
> > > >> >>nice
> > > >> >> to
> > > >> >> > the eyes.
> > > >> >> >
> > > >> >> > I was thinking about impact on the transitions management - I'm
> > not
> > > >> >>sure
> > > >> >> > that the current transition approach (fromState/toState) scales
> > > >>well
> > > >> >>once
> > > >> >> > we go this way.
> > > >> >> >
> > > >> >> > A possible idea could be to support "state delegates", i.e.
> allow
> > > >>to
> > > >> >> break
> > > >> >> > up the MXML component in subcomponents, and let each of these
> > > >> >> subcomponents
> > > >> >> > manage its own set of states and the related transitions.
> > > >> >> >
> > > >> >> > Elaborating on the Bill approach, something like:
> > > >> >> >
> > > >> >> > <s:states>
> > > >> >> > <s:ExclusiveStateGroup id="mouse">
> > > >> >> > <s:State name="up"/>
> > > >> >> > <s:State name="down"/>
> > > >> >> > <s:State name="over"/>
> > > >> >> > </s:ExclusiveStateGroup>
> > > >> >> > <s:ExclusiveStateGroup id="focus" stateDelegate="focusGroup">
> > > >> >> > <s:State name="nonFocused"/>
> > > >> >> > <s:State name="focused"/>
> > > >> >> > </s:ExclusiveStateGroup>
> > > >> >> > <s:ExclusiveStateGroup id="selection">
> > > >> >> > <s:State name="nonDefault"/>
> > > >> >> > <s:State name="default"/>
> > > >> >> > </s:ExclusiveStateGroup>
> > > >> >> > </s:states>
> > > >> >> >
> > > >> >> > [...]
> > > >> >> >
> > > >> >> > <s:Group id="focusGroup"
> > > >> >> > top="0" bottom="0" left="0" right="0">
> > > >> >> > <s:transitions>
> > > >> >> > <s:Transition fromState"nonDefault" toState"default">
> > > >> >> > <s:Fade target="{focusRect}"
> > > >> >> > alphaFrom="0" alphaTo="1"/>
> > > >> >> > <s:/Transition>
> > > >> >> > </s:transitions>
> > > >> >> > <s:Rect id="focusRect"
> > > >> >> > top="0" bottom="0" left="0" right="0"
> > > >> >> > alpha="0" alpha.default="1"/>
> > > >> >> > <s:stroke>
> > > >> >> > <s:SolidColorStroke color="..."/>
> > > >> >> > </s:stroke>
> > > >> >> > </s:Rect>
> > > >> >> > </s:Group>
> > > >> >> >
> > > >> >> >
> > > >> >> > This would allow multiple transitions in each "exclusive state
> > > >>group"
> > > >> >>to
> > > >> >> be
> > > >> >> > managed indipendently, and make sense to me as well, because
> > often
> > > >> >>each
> > > >> >> set
> > > >> >> > of these state groups only impacts a specific part of the
> > component
> > > >> >>(or
> > > >> >> of
> > > >> >> > the skin): in the example, focus just add a glowing border on
> top
> > > >>of
> > > >> >>the
> > > >> >> > rest.
> > > >> >> >
> > > >> >> > This allow to grab one or two set of states, and subtract them
> > from
> > > >> >>the
> > > >> >> > cartesian multiplication (and also simplify the related
> > transitions
> > > >> >> > management, isolating it from other states). When the
> > > >>"stateDelegate"
> > > >> >>is
> > > >> >> > not provided, it just means that the related states are managed
> > by
> > > >>the
> > > >> >> top
> > > >> >> > MXML component.
> > > >> >> >
> > > >> >> > In a sense, responding to Jude, this aims to bring the benefits
> > of
> > > >>the
> > > >> >> > composition approach (versus the inheritance provided by
> basedOn
> > > >> >>states).
> > > >> >> >
> > > >> >> >
> > > >> >>
> > > >>
> > > >>
> > >
> > >
> >
>
