Flex4 : Component state vs skin state

Question

Hello,
I still can't quite figure the difference between the two ( if there is even a difference )
component state : Defined by UIComponent's current state
skin state : Determined by SkinnableComponent->getCurrentSkinState.
Now, when should one use these 2 different mechanisms ?
My first thought was that skin state was used for small variations ( selected effects, small controls appearing, etc ) and that component state was more for application state, like a view representing a form would change drammatically if currentState became FORM_BEING_SUBMITTED. But a skin could very well be applied to a huge and complex view so this reasonning fails.
->  Another interpretation is that you would use a skin only if flexibility is required, or else just use the old component state mechanism.
Is that correct?

Answer 1

Hi,
It can be a bit confusing, no worries.  Not sure if this will help but here goes...
A Flex 4 "skin" is itself a component - e.g. Skin is derived from UIComponent and as such supports view states.   So when you see the term 'skin state' all it really means is that it is the 'currentState' of the Flex 4 skin.   The 'currentState' of a Skin is controlled automatically by the SkinnableComponent the skin is associated with (based on what getCurrentSkinState returns at a given point in time).
There really is no functional difference between how view states work for a Flex 4 Skin vs. how they work for say any other MXML component (like Application) - other than who is responsible for changing the state over time.  It's just that in the case of Application where (as in your example) you may define 3 different orientations of your application for example - you'd be responsible for setting currentState when appropriate.
The one thing to remember (and I'm sure is the reason for most folk's confusion) is that for a SkinnableComponent instance, there really aren't any "states" for the component itself - the 'currentState' and states array are unused in this case.
A simple example:
Button. The actual Button class has no states itself, but its Skin does.  The Button is responsible for putting the Skin in one of the possible view states at runtime based on user interaction over time (e.g. up, over, down, disabled).  e.g. getCurrentSkinState is called on Button and depending on what is returned, the Button will (behind the scenes) set 'currentState' of the Skin component to one of the 4 states.
Setting 'currentState' on a Button itself has no affect, because the Button has no actual states defined (as far as the states API is concerned), even though it happens to also be a UIComponent.
-Corey