Archive for Architecture
Flex 4 and States (they finally got it right)
Posted by: | CommentsI’ve finally started a serious investigation into Flex 4. Unfortunately it takes me a while to get around to these things, especially in the middle of a project with 2 developer casualties thus far. The project is winding down a bit, the interaction designers are finally off the project, and I’ve had a bit more time to turn my attention to other things. It couldn’t have happened at a better time, either, since I’ll be giving a Flex 4 presentation at the local user group meeting this coming Tuesday (specifically on the MVC changes involving Flex components).
Anyway, I just have to say I am very impressed with the new “states” implementation. Though in many ways it’s still the same old states we had with Flex 2 and 3, the approach is much cleaner and much more in line with how such a feature should be used.
What has had the greatest effect is the separation of component behavior from component appearance. With this new separation comes a much clearer understanding that states are intended to manage component state. I think this must be what the architects originally introduced states for, but because the way it was implemented this purpose was a lost somewhat.
There’s a fine line between using states as a means to add and remove children from the Application or component based on changing application state, and using them to track component state. There are occasions when application state and component state are the same thing; there are many cases when they are not. The new approach makes it much easier to handle both cases, and to know when to use states and when not to…
Define your states in the component skin, and add a corresponding SkinState metadata tag to your component class. That’s where the states belong… there should be no need to have states or use the currentState property in your component class, though it inherits it from UIComponent.
Based on your data model, or user gestures, you should rely on one of the skins states (or a separate skin altogether) to change the view to match the state. There’s a method called getCurrentSkinState() where this can be handled, and it will be called after invalidateSkinState() is called (perhaps inside commitProperties().
In conclusion, though the nasty, nasty states syntax will become history, states should still be used judiciously.
Private Variables and Monkey Patching
Posted by: | CommentsI’ve been pretty busy the past two months finishing up a project for my client. I may have mentioned it before, but their creative vision is pretty intense (especially considering this is an in-house app… in my limited experience I’ve never seen so many resources allocated toward getting the look and feel of an in-house app to be just right).
Anyway, I’ve had to monkey patch approximately 10 Flex framework classes (for various reasons) in order to realize their vision. In each of these cases I’ve first tried to use inheritance or composition to achieve the desired functionality, mostly in terms of interaction. And in each of these cases I was unable to do so, and had to resort to making changes directly in a framework class which I maintain in an mx.controls.etc, etc structure with the rest of my project. I don’t think I need to point out the many evils that this exposes the project to, suffice it to say it’s not ideal.
I just wanted to make an observation as to why I was unable to use normal OOP techniques to achieve the desired functionality. The most common reason I have been unable to extend classes to do what I need is because there are too many private variables being used in protected functions. So if I need to tweak one line of a protected method, I can override it. However, assuming I don’t want to call super.methodName(), there’s no way to recreate the lines that interact with the private variables.
This leaves me two alternatives: 1) monkey patch the file to make the variable protected, or 2) monkey patch the file and just make the change directly to the method. I make that decision depending on whether I’m fixing a bug, or just adding functionality. Either way, it’s still a pain in the butt; and will probably be a bigger pain down the road.
Responding to FocusIn and focusOut Events
Posted by: | CommentsI recently had some problems responding to focusIn and focusOut events, trying to handle them from my MXML code. After some experimentation and poking around, I discovered the solution was to override the focusInHandler and focusOutHandler methods. These are protected methods inherited mx.core.UIComponent class.
My particular application was to stop a timer that was triggering events when the control had focus, and to restart the timer when focus was lost. Since you’ll be overriding the method, be sure to call super.focusInHandler(event) to ensure the default behavior is still maintained (unless your reason is to override rather than extend the default behavior). Here are the method signatures:
override protected function focusInHandler(event : FocusEvent) : void override protected function focusOutHandler(event : FocusEvent) : void
