Just ran into this gotcha while trying to apply a Resize transition for my AIR WindowedApplication in Flex 4 (Gumbo) using states. It appears — at least in my app — that simply setting the width.stateName and height.stateName doesn't work: it causes the animation to jump. Instead, I found that I also had to set explicitHeight.stateName, explicitWidth.stateName and minWidth.stateName and minHeight.stateName.
The Gotcha: Resize transition for Adobe AIR WindowedApplication in Flex 4 article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Here's a simple snippet to illustrate:
<WindowedApplication xmlns="http://ns.adobe.com/mxml/2009" width="416" height="285" explicitWidth="416" explicitHeight="285" minWidth="416" minHeight="285" ... width.headLess="110" height.headLess="198" explicitWidth.stateName="110" explicitHeight.headLess="198" minWidth.headLess="110" minHeight.headLess="198" > <transitions> <Transition> <Resize duration="500" target="{this}" easingFunction="Quadratic.easeOut"/> </Transition> </transitions> <states> <State name="aliveAndWell"/> <State name="headLess"/> </states> ... <Script> <![CDATA[ import mx.effects.easing.Quadratic; private function offWithHisHead() { currentState = "headLess"; } // etc. ]]> </Script> ... </WindowedApplication>
The Gotcha: Resize transition for Adobe AIR WindowedApplication in Flex 4 article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Hey Aral,
What SDK are you using here? Just asking because now you require the Spark namespace for most of the tags used in this example. Well to be exact, before you did, then you didn’t, now you do again, if that’s correct?? :)
Hey Richard, I was using a previous version of the SDK from a few months back. I just updated that app to the latest SDK and I wasn’t impressed by the latest Fx to namespaces change (http://aralbalkan.com/2202).
Electronic cigarette, but Israel does not have the powder components as well as the poisoning is lacking nicotine
Hi Aral,
Someone pointed me to this as I’m working on effects for Flex 4 on the Flex team.
I think you’re hitting an unusual case with the interaction of width/height on an app window. Typically, effects figure out stuff about the before/after state internally (by setting values, running layout, restoring values), and then run the animation from start to end; you never see anything but the end result. Resize works fine on a Button, or any other component, but just examining the width/height changes and doing the right thing. But there’s something different about the app window that causes it to visually set the end state values before actually running the animation. I’m thinking it has to do with us setting actual values on the underlying window, and the OS may act on that immediately whereas the typical component sizing is single-threaded and thus under our control.
This is the case for the old Resize effect as well (or at least it was in my testing – let me know if you saw something different).
Anyway, I’ll go figure this out and see if there’s a better way to make this happen for WindowedApplication.
I also wanted to point out that you’re not actually getting a Quadratic ease here – you’re using the old easing function approach with the new effects, which actually take an instance of the new IEaser interface. Check out Sine/Power/etc. in spark.effects.easing (post-rename location). To get a Quadratic ease-out, you’d actually write this:
Hope that helps.
Chet.
Seems to have cut out my attempt at MXML in my previous comment. Try this instead:
<s:Power id="quadratic" easeInFraction="0" exponent="2"/>
<s:Resize easer="{quadratic}" …/>
Finally getting back to this…
The original problem of width-vs-explicitWidth seems to have gone away since I filed the bug; I get the same Resize behavior regardless of which properties I use in the WindowedApplication tag. (this is using the latest Flex 4 beta builds, as of 12/1/2009).
The jumpy behavior is, unfortunately, not fixable. As I said my earlier comment, changing the size of a WindowedApplication immediately sets the size of the underlying native window. Flex transitions work by setting properties to their end-state values, capturing all of those values, then rolling the values back to their starting values. This approach works for browser apps (or anything inside the WindowedApplication container) because we roll the values back before any changes are made on the screen. But it’s inherently problematic with WindowedApplication because setting the end-state values immediately causes the jump into the window size that you’re seeing. There’s nothing we can do about this; it’s just a conflict between the way that WindowedApplication works and the way that transitions work.
You can still get a smooth resize effect, but you would have to do it by manually running an effect that sets the size of the window, not a Resize in a transition that picks up the values from the states (and thus hits the transitions problem).
Note that there’s also a herky-jerky problem with running Resize on a WindowedApplication because we are changing width/height independently (and each one causes immediate changes in the underlying native window). It might be better to change the dimensions atomically, like the approach in this example:
http://graphics-geek.blogspot.com/2009/10/video-resizing-air-windows-with-flex-4.html
By the way, the SDK bug I filed on this issue is sdk-21444:
https://bugs.adobe.com/jira/browse/SDK-21444
Chet.