Archive for Actionscript
Flex Socket Connections : Socket Policy File
Posted by: | CommentsStarting with certain versions in the 9.0’s of Flash player, socket communication in Flex began adding additional security measures. The one I am going to discuss in the post is the socket policy file. In short, the socket policy file is an XML file that is served by default from port 843 and contains information regarding which ports on _this_ server that Flash may connect to. Additionally it allows you to specify from which domains you wish to allow connections.
Loading the Policy File From Flex
The policy file can be explicitly requested by making the call:
Security.loadPolicyFile("host.withpolicyfile.com:843");
Or you can trust it will implicitly make the request when you attempt a socket connection. The policy is valid for a particular IP address over the life of the SWF. A policy request consists of the following line, nothing more:
<policy-file-request/>
And the correct response is the policy file, followed by a null byte. My example policy server file will not be so picky about it’s request, use it at your own risk. Adobe has one that actually checks to see if the request was formatted correctly before sending the response. Furthermore, rather than reading in an actual policy file, my example hard codes it into the policy server.
Policy File Format
Here is a sample policy file, it is provided by Adobe. You can make whatever changes you need to, as I did in mine:
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd"> <!-- Policy file for xmlsocket://socks.example.com --> <cross-domain-policy> <!-- This is a master socket policy file --> <!-- No other socket policies on the host will be permitted --> <site-control permitted-cross-domain-policies="master-only"/> <!-- Instead of setting to-ports="*", administrator's can use ranges and commas --> <!-- This will allow access to ports 123, 456, 457 and 458 --> <!--allow-access-from domain="swf.example.com" to-ports="123,456-458" /--> <allow-access-from domain="*" to-ports="80" /> </cross-domain-policy>
Policy File Server
And here is the Perl code that runs the policy server. You can see it is just a basic socket server. Adobe’s version of this (which I based mine off) allows you to pass in the port as well as the path to the policy file. This is a stripped down version of that server, with most of the essentials hard coded.
use Socket;
my $NULLBYTE = pack('c', 0);
my $port = 843;
my $content ='<?xml version="1.0"?>'."\n" .
'<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">'."\n" .
'<cross-domain-policy>' . "\n" .
'<site-control permitted-cross-domain-policies="master-only"/>'."\n" .
'<allow-access-from domain="*" to-ports="80" />'."\n" .
'</cross-domain-policy>'."\n";
socket (LISTENSOCK, PF_INET, SOCK_STREAM, getprotobyname('tcp'))
or die "socket() error: $!";
setsockopt(LISTENSOCK, SOL_SOCKET, SO_REUSEADDR, pack('l', 1))
or die "setsockopt() error: $!";
bind (LISTENSOCK, sockaddr_in($port, INADDR_ANY))
or die "bind() error: $!";
listen (LISTENSOCK, SOMAXCONN)
or die "listen() error: $!";
while ( my $clientAddr = accept(CONNSOCK, LISTENSOCK)) {
my ($clientPort, $clientIp)= sockaddr_in($clientAddr);
my $clientIpStr = inet_ntoa($clientIp);
# Consume the request
local $/ = $NULLBYTE;
my $request = <CONNSOCK>;
chomp $request;
# Send the policy file
print CONNSOCK $content;
print CONNSOCK $NULLBYTE;
close CONNSOCK;
}
}
Opening A Port
Remember to open port 843 (in Fedora Core) by adding the following line in /etc/sysconfig/iptables :
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 843 -j ACCEPT
Then reload the iptables:
/etc/init.d/iptables restart
JUICE chat (Stratus Peer to Peer)
Posted by: | CommentsOne of my ongoing weekend projects is an AIR chat application, recently rechristened “JUICE” a.k.a. “John’s Ultimate Internet Chat Experience”. I realize that may only be the case for myself, but the project has been very educational and entertaining for me.
The initial release used AIR/Flex as the front-end, ColdFusion and MySQL for the backend, and BlazeDS messaging for message transmission and “peer discovery”. I worked on it over a couple weeks adding features like encryption, toast-style notifications, as well as a few other less notable things.
I knew the architecture was awful and would never scale beyond a couple hundred users (if that many). Here’s the basics of how it worked:
- The user would login, ColdFusion/MySQL would send back a list of chat buddies.
- Each logged in user would ping the messaging server every 10-30 seconds to announce “I’m still here!”
- The pings would be broadcast to everyone logged in (and connected to the messaging server). The application would filter out the ones it was interested in based on user id.
- Sending messages worked similarly, the user would send the message (which included information about the intended recipient), which would then be broadcast to EVERYONE.
- Everyone would filter this information, and the recipient would know it was for him, and would display it.
You can see why this would not scale well, the amount of traffic and pinging going on. Eventually even a user with only 1 or 2 buddies would notice a significant drop in performance as the number of total users increased. There are some applications of “chat” for which BlazeDS messaging and polling is well suited for (like a chat room). A chat application involving “buddies” is much better suited for P2P.
Enter Stratus. I discovered Stratus a few months ago but was unwilling to delve into it on account of my hectic schedule. Fortunately one of my friends went and did all the dirty work figuring out how to get it up and running (turns out it’s pretty easy) and I was able to apply it to my chat client.
I’m very pleased with the results, though it’s still very much a work in progress. I’ve even been able to add video and voice chat features, which is why I went through the trouble in the first place. Here is how my peer discovery mechanism operates. It requires only 3 calls to the server per client (which I could easily condense to 2 if I wanted).
- The user logs in.
- If the user successfully authenticated, he connects to Stratus and receives his peer ID.
- The user updates his peer ID in the database (which was set to 0) and gets a list of his buddies and their peer IDs. I also update information like whether or not I have a camera/mic.
- The user processes his buddy. If the peer ID is something other than 0, then I know this buddy logged in before me, so I must send him my peer ID.
- Any buddies that have a peer ID of 0 are not logged in, I need to listen for them though since they will get my peer ID when they log in.
- When I log out or close the application, I call the server and reset my peer ID to 0. I also notify all of my connected peers I’m logging out.
There are a few more steps in the process, but it decreases the load on the server significantly, transferring the “burden of proof” onto the clients.
Interesting to note is the way I get the peer ID of a client who connects after me (step 4). I don’t actually have to make a call for this, rather he simply has to start broadcasting to me on the NetStream I set up to listen for him (step 5). When the connection is made, an event will be dispatched by the NetStream class. In fact, 3 events will be fired, I just chose to act on one of them.
The peer ID can be obtained from the peerStreams array on the publishing NetStream. I then use that information to set up my subscribing NetSream.
if (this.peerId == null || this.peerId == &quot;0&quot;) {
this.peerId = publishNetStream.peerStreams[0].farID;
this.subscribeNetStream = new NetStream(model.netConnection, this.peerId);
this.subscribeNetStream.client = new NetStreamClient();
this.subscribeNetStream.play(streamName);
}
Anyway,I’m planning on doing another post to outline my video and voice handshake protocols. They’re nothing to write home about, but I’d love some feedback if there’s a better way. I’m also planning on releasing JUICE after I bring it’s level of functionality back up to where the original version was, so stay tuned and you should see my install badge at the bottom of my blog.
Contextual Shortcut Manager
Posted by: | CommentsI’m about ready to sleep on my ShortcutManager, I figured I might as well finish off the series. I added context to it, while still maintaining backward compatibility with the non-context enabled version. I don’t think I posted it, so it probably won’t matter so much to my readers. For those who haven’t read the previous posts on my ShortcutManager, the “context” I’m referring to is the context in which a keyboard shortcut might be used; such that a given shortcut might have several functions associated with it depending on its context.
In short I needed four things to implement the context aware shortcut manager.
1. The IKeyboardContext interface
This is a simple interface that a model or class can implement that allows a keyboardContext to be set and retrieved. A keyboardContext is simply a string that identifies the current context. These contexts will be associated with a shortcut in the manager. Here is the entire interface:
package com.googolflex.gflib.interfaces {
public interface IKeyboardContext {
[Bindable(event="propertyChange")]
function get keyboardContext() : String;
function set keyboardContext(v : String) : void;
}
}
2. A reference to an IKeyboardContext needed to be added to the ShortcutManager
As the keyboardContext changes in the model, the ShortcutManager needs to be able to access it, so it can retrieve the correct function for a given keycode-flags-context tuple. The IKeyboardContext was left null, which helps with the backward compatibility (the implementer will be forced to set it if she wants to use it). Here is the line I added, which is pretty trivial:
public static var model : IKeyboardContext = null;
3. Add the context to the addShortcut method
I gave it a default value, which incidentally was “default”, so that every function added to the Dictionary would have some kind of context. Here is the new addShortcut() method:
public static function addShortcut(keycode : uint, func : Function, flags : uint, context : String = "default") : void {
if (flags > 0 && flags < 8)
functionMap[keycode + "-" + flags + "-" + context] = func;
}
4. Finally, the shortcutHandler() needed to incorporate the context
I first check if the IKeyboardContext is null, if it is I know to use “default” as the context. If no context was ever specified, and no IKeyboardContext was ever set, then it still works. Here is the modified code:
public static function shortcutHandler(event : KeyboardEvent) : void {
var flags : uint = getFlags(event);
var context : String = (model!=null) ? model.keyboardContext : "default";
if ( functionMap[event.keyCode + "-" + flags + "-" + context] != null )
(functionMap[event.keyCode + "-" + flags + "-" + context] as Function).apply();
}
And was pretty much it. I will post the modified code, along with a demonstration application at the end of the post. I do want to make a couple points to be aware of when actually incorporating this into a project.
First, your model/class will need to implement IKeyboardContext. Second, you need to remember to set ShortcutManager.model = myIKeyboardContext somewhere. Third, you’re on your own when it comes to maintaining your context. Maybe the “SimpleContextManager” will be next, who knows? And fourth, you’ll have to specify a context when you call addShortcut(). Remember if you download the demo, it will need to have some kind of reference to the ShortcutManager code.
Simple Flex ShortcutManager (revisited)
Posted by: | CommentsI’ve put some more thought into my shortcut manager, and have decided on a way to implement the shortcut context, as well as curb the Dictionary explosion that my previous architecture would have had.
The new version uses one Dictionary to store all functions, the keyCode, combo keys, and context is all encoded into the dictionary key. To illustrate here is my new addShortcut() method:
public static function addShortcut(keycode : uint, func : Function, pair : String) : void {
var flags : int = getFlagsFromString(pair);
if (flags > 0)
functionMap[keycode + "-" + flags] = func;
}
It accepts the same parameters, the only difference is that the pair string is now a dash delimited string, containing the key combinations (i.e. “ctrl“, “ctrl-alt“, “shift-ctrl“, etc). Those are parsed by a method getFlagsFromString() which I will probably get rid of in favor of some named constants on the ShortcutManager class. That will eliminate the need for the additional method, and pair (which will be one of said constants) can be added to the key as-is.
The removeShortcut() is very similar. I haven’t implemented “contexts” yet, but you can visualize how it will be done:
functionMap[keycode + "-" + flags + "-" + context] = func;
Now that there is only one Dictionary, the shortcutHandler() method has become almost trivial. Here it is, in all of its 5-lined glory:
public static function shortcutHandler(event : KeyboardEvent) : void {
var flags : uint = getFlags(event);
if (functionMap[event.keyCode + "-" + flags] != null)
(functionMap[event.keyCode + "-" + flags] as Function).apply();
}
Like I said… trivial.
Using Bit-wise Math to Simplify Logic
Posted by: | CommentsStrictly speaking, bit strings are not nearly as easy to understand as named boolean variables; but there are situations when they can simplify or eliminate the need for long boolean expressions.
Consider my recent post about the ShortcutManager. There are three control keys that may or may not be pressed at any given time. This amounts to 8 possible key combinations (7 if you ignore when none of them are pressed). Here’s what this would look like if you used a boolean expression to check for each of the possible combinations:
var ctrl : Boolean = event.ctrlKey;
var alt : Boolean = event.altKey;
var shift : Boolean = event.shiftKey;
if (!shift && !alt && ctrl) {
// CTRL
}
else if (!shift && alt && !ctrl) {
// ALT
}
else if (!shift && alt && ctrl) {
// CTRL-ALT
}
else if (shift && !alt && !ctrl) {
// SHIFT
}
else if (shift && !alt && ctrl) {
// CTRL-SHIFT
}
else if (shift && alt && !ctrl) {
// SHIFT-ALT
}
else if (shift && alt && ctrl) {
// CTRL-SHIFT-ALT
}
That might not seem too bad, and it isn’t that hard to understand what’s going on (even without the comments). But what happens when you’ve got 4 variables (16 possibilities)? The number of combinations increase exponentially. Even if the combinations you are actually interested in are sparse, who wants to type out 10 lines each with 32 boolean variables?
With a simple method to construct my “bit string”, we can greatly simplify this. ActionScript doesn’t have a binary number type, so you’ll have to use integers. If you can count by powers of two you won’t have any trouble. Here’s a method that constructs my “bit string” integer based on selected control keys:
private static function getFlags(event : KeyboardEvent) : uint {
var flags : uint = 0;
flags += (event.ctrlKey) ? 1 : 0;
flags += (event.altKey) ? 2 : 0;
flags += (event.shiftKey) ? 4 : 0;
return flags;
}
Having this integer allows me to simplify the logic as follows (which isn’t harder to understand at all, if you use comments):
switch ( getFlags(event) ) {
case 1: // CTRL
break;
case 2: // ALT
break;
case 3: // CTRL-ALT
break;
case 4: // SHIFT
break;
case 5: // CTRL-SHIFT
break;
case 6: // SHIFT-ALT
break;
case 7: // CTRL-SHIFT-ALT
break;
}
This is powerful, but it’s just scratching the surface. I haven’t even discussed the bitwise operators &, | and ^. Or the bitwise shift operators >> and <<. These come in handy when you store a series of options as a bit string and need to test whether a certain option is on or off.
For example, if we needed to test if value returned by getFlags() had the SHIFT bit set, we could use the following boolean expression to test it. Remember SHIFT = 4:
if (getFlags(event) & 4 == 4)
Of course this doesn’t help us out much now in the ShortcutManager, but assume I was to add 3 possible contexts that these shortcuts might be used in (different screens, for example). They would hold the 8, 16, and 32 bit places. I could use bitwise math to split them if I only needed to manipulate one them at a time (a stretch, I know).
var screenOnly: uint = flags & 56; var keysOnly: uint = flags & 7;
They have a variety of uses and are there when you need them. There’s an excellent explanation of various bitwise operations and their uses here.
Simple Flex ShortcutManager
Posted by: | CommentsJust for fun I wrote a simple ShortcutManager this evening, it turned out to be an interesting little project and taught me a few things about Functions. It’s by no means finished, I’ll detail a few planned improvements after I go over it’s usage.
My goals were to have a static registry that the application could register a keyCode, along with a qualifying key combination (I refer to this as “pair” in the code) like CTRL, or CTRL-ALT. I left out ALT, as Windows seems to have issues with giving up control of the ALT key when used alone. Along with the keyCode, I needed to be able to register a function that would be called when the key combination was pressed. I also wanted to be able to remove a key combination at runtime.
My data structure was simple, I used a separate Dictionary for each of the key combinations I was supporting.
private static var ctrlFunctionMap : Dictionary = new Dictionary(); private static var ctrlAltFunctionMap : Dictionary = new Dictionary();
I wrote an addShortcut method that accepted the keyCode integer, the function to be called, and a string declaring the combination key(s). In it I simply associated the keycode and the function in the appropriate Dictionary. Here is the addShortcut():
public static function addShortcut(keycode : uint, func : Function, pair : String = "ctrl") : void {
if (pair == "ctrl") {
ctrlFunctionMap[keycode] = func;
}
else if (pair == "ctrlAlt") {
ctrlAltFunctionMap[keycode] = func;
}
else {
trace("Key combination not supported.");
}
}
The removeShortcut() method has a similar structure, with one less parameter since we don’t need to know the function. We simply set the appropriate function for the appropriate keycode and combination key to null. Here is the removeShortcut() function:
public static function removeShortcut(keycode : uint, pair : String = "ctrl") : void {
if (pair == "ctrl") {
ctrlFunctionMap[keycode] = null;
}
else if (pair == "ctrlAlt") {
ctrlAltFunctionMap[keycode] = null;
}
else {
trace("Key combination not supported.");
}
}
Finally we need a method that accepts a KeyboardEvent and determines if one of the functions needs to be executed, and then call it. Here is the shortcutHandler() function that does this:
public static function shortcutHandler(event : KeyboardEvent) : void {
if ( event.ctrlKey && !event.altKey && (ctrlFunctionMap[event.keyCode] != null) ) {
(ctrlFunctionMap[event.keyCode] as Function).apply();
}
else if (event.ctrlKey && event.altKey && (ctrlAltFunctionMap[event.keyCode] != null) ) {
(ctrlAltFunctionMap[event.keyCode] as Function).apply();
}
}
I learned an important lesson when I first tried to implement this method. I tried casting the value from the map as a Function, like this:
Function(ctrlFunctionMap[event.keyCode]).apply();
which didn’t work, and spat the error:
EvalError: Error #1066: The form function('function body') is not supported.
Fortunately, one of ActionScript’s more descriptive error messages (I could tell by the parentheses what was wrong) and was able to correct it using the as operator. I didn’t try it, but I might have been able to not bother casting it at all.
Here’s my ShortcutManagerDemo application, demonstrating how it can be used with a variety of functions and function literals.
import com.googolflex.gflib.managers.ShortcutManager;
private function onCreationComplete() : void {
ShortcutManager.addShortcut(89, onCtrlY, "ctrl");
ShortcutManager.addShortcut(89, onAltY, "ctrlAlt");
var f : Function = function():void { trace("Ctrl-U pressed."); }
ShortcutManager.addShortcut(85, f, "ctrl");
ShortcutManager.addShortcut(85,
function():void { trace("Ctrl-Alt-U pressed."); },
"ctrlAlt");
}
private function onAddedToStage() : void {
stage.addEventListener(KeyboardEvent.KEY_DOWN, globalShortcutHandler);
}
private function globalShortcutHandler(event : KeyboardEvent) : void {
ShortcutManager.shortcutHandler(event);
}
private function onCtrlY() : void {
trace("Control-Y pressed.");
}
private function onAltY() : void {
trace("Ctrl-Alt-Y pressed.");
}
I’ll post the code for the manager, and the sample application at the end of the post. Anyway, some improvements I’m planning…
I’d like to associate a context with each command, so that the same keyCodes could be used on different screens. Organizing the manager for such functionality doesn’t strike me as being that hard. I would have to make some changes to my logic to keep down the “conditional explosion”. The daunting part is where to get the context state… I’ll probably end up creating an interface for it, and then make my models implement it.
Of course I’d like to add more combination keys: SHIFT, SHIFT-ALT, CTRL-SHIFT-ALT, etc. The challenging part for that will be simplifying the conditional logic in shortcutHandler() to keep from having to check for a billion cases. I think I would start by pushing the (ctrlFunctionMap[event.keyCode] != null) check down a level, and using my first level of logic only to check the combination keys pressed.
Anyway, if this is useful for anyone I’m glad I could help. Here’s the source:
ShortcutManagerDemo.mxml
ShortcutManager.zip
Update (8/18/09): I added a few things to ShortcutManagerDemo.mxml, namely an interface that allows the user to add their own key commands at runtime. This has limited usefulness in it’s present form, as the functions themselves are still fixed at compile time. Here are some keycodes you can try it out on, anyhow.
a-65; b-66; c-67… 0-48; 1-49; 2-50…
Extending the SkinnableComponent (well, sort of)
Posted by: | CommentsI won’t exactly be extending a SkinnableComponent in this post, I’ll be extending the Button (which extends SkinnableComponent) and creating a few new skins for it. Extending the SkinnableComponent is almost identical to extending the SkinnableContainer (see my previous post). You won’t need the contentGroup, of course.
I wanted to illustrate the power of Flex’s new skinnable architecture when combined with states.
Specifically I will show:
1. How easy it is to create multiple skins for the same class.
2. How easy it is to change skins at runtime via states.
For my collapsible panel, I need a button. All in all the button has 8 possible states: for each of the two expanded or collapsed states of the container, there are the 4 possible button states (up, down, over, disabled). Rather than suffer the madness of creating a skin with 8 possible states and the button class to manage them, I’m going to create two skins (one for expanded, one for collapsed), each which use the 4 standard button states.
I’ll include the full code for the CollapseButtonSkin, (which extends Skin). The code for ExpandButtonSkin is almost identical, except for the image names. The most important thing to note, is how I change the source of the Image using the new state syntax. I’ll be using that same syntax later in my panel.
<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="12" minHeight="12" alpha.disabled="0.5">
<!-- host component -->
<fx:Metadata>
[HostComponent("com.googolflex.gflib.controls.ExpandCollapseButton")]
</fx:Metadata>
<!-- states -->
<s:states>
<s:State name="up" />
<s:State name="over" />
<s:State name="down" />
<s:State name="disabled" />
</s:states>
<mx:Image
source.down="@Embed('../assets/collapse_panel/collapse_down.png')"
source.over="@Embed('../assets/collapse_panel/collapse_over.png')"
source.up="@Embed('../assets/collapse_panel/collapse.png')"
source.disabled="@Embed('../assets/collapse_panel/collapse_over.png')" />
</s:Skin>
I didn’t do anything special in the ExpandCollapseButton class, I just extended Button (which contains the code to change between the up, down, over, and disabled states).
When I add my button to the QuickCollapsePanelSkin class, I specify a skinClass for each of my two panel states. When the state of the component changes, the button skins (which in turn have their own states) will be updated automatically. Here is the code:
<controls:ExpandCollapseButton
width="12" height="12"
top="{(SimpleQuickCollapsePanel(hostComponent).headerHeight - 12) / 2}"
left="4"
skinClass.collapsed="com.googolflex.gflib.skins.ExpandButtonSkin"
skinClass.expanded="com.googolflex.gflib.skins.CollapseButtonSkin"
click="SimpleQuickCollapsePanel(hostComponent).toggleExpanded()" />
You can download the full source for this example here: simple_collapsible_panel.zip
Extending the SkinnableContainer (attempt 1)
Posted by: | CommentsI’ve just created my first Flex 4 component, and loved doing it. It’s not entirely finished, but I wanted to share what I learned for those who may follow after me.
In the component proper, some things to remember:
1. Extend SkinnableContainer.
2. Declare the skin states using metadata brackets. In my case:
[SkinState("collapsed")][SkinState("expanded")]
3. Override getCurrentSkinState() to return one of the strings declared in #2, based on component state.
override protected function getCurrentSkinState() : String { if (expanded) return "expanded"; else return "collapsed";}
4. Call invalidateSkinState(), if necessary. Possibly done in setters or in commitProperties()
In the skin class, some things to remember:
1. Extend the SkinnableContainerSkin.
2. Declare the host component, the component you are skinning. Done as follows, using metadata tags:
<fx:Metadata>
[HostComponent("com.googolflex.gflib.containers.SimpleQuickCollapsePanel")]
</fx:Metadata>
If you need to access any properties of the extended class, ie SkinnableContainer you can do so by using the hostComponent variable. When I wanted to access members specific to my HostComponent, I had to cast hostComponent to a SimpleQuickCollapsePanel.
3. Declare the states of your skin. This may be done as follows:
<default:states> <mx:State name="collapsed"> <mx:State name="expanded"> </default:states>
4. Draw your layers or add your images to the skin as necessary. Reference your states, or hostComponent as necessary.
5. In the case of the SkinnableContainer you’ll want to make sure you add the container for its children. You can supply whatever layout you need, and can even change it based on state. It needs to be called contentGroup, however.
Here’s an example of how I did it:
<s:Group id="contentGroup"
left="3" right="3"
top="{SimpleQuickCollapsePanel(hostComponent).headerHeight+3}"
bottom="3"
visible="{SimpleQuickCollapsePanel(hostComponent).expanded}">
<s:layout>
<s:VerticalLayout />
</s:layout>
</s:Group>
I’ll be including the full source for my QuickCollapsePanel in my next post, where I describe extending the SkinnableComponent.
Update: In the most recent SDK release, the spark.skins.default package has been changed to the spark.skins.spark package. This affects the SkinnableContainerSkin class.
Stay tuned for the next update, when Adobe changes it to the spark.skins.spark.skins package…
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.
Detecting Changes in an Object
Posted by: | CommentsOne of the projects I’m working on right now requires me to detect when changes to an object have occurred, so as to enable or disable some “OK”, “Apply” and “Cancel” buttons in the appropriate context. For the longest time I’ve been thinking I was going to implement this with some sort of data binding, but as it’s distilled on my mind over the past few weeks I’ve decided that wasn’t the right approach. Here are a few of the requirments/factors that played into that decision:
Background info: the gist of this app is that there’s a datagrid whose items can be loaded into a dialog for editing.
- The changes don’t affect the actual object in the model or database being edited until “Apply” or “OK” is pressed (i.e. they can always cancel out of the operation, regardless of any changes)
- If a user edits a field, I want that to register as a change. If they change the field back to what it was, I don’t want that registered as another change, it needs to be as if it had never been changed (i.e. “OK” is not enabled). This is why I ruled out a Binding approach.
- The objects being compared are pretty complex objects. I didn’t want to have to go and manually compare each property, the properties of composed objects, and the properties of objects nested in collections. The time to implement this, and the amount of time it would take to compare the object with its sentinel after each edit seemed to rule this option out.
I became pretty familiar with ByteArrays last year during a computer security class (I implemented my AES, RSA, etc. labs using ActionScript) and so I got the idea of serializing these objects to a ByteArray, and then comparing them. After I came up with the idea, I googled it and realize I’m hardly the first to come up with it, but I’m still going to share it.
First, I built a method to convert an object to a ByteArray, convertToBytes:
public static function convertToBytes(m : Object) : ByteArray {
var ba : ByteArray = new ByteArray();
ba.writeObject(m);
return ba;
}
The ByteArray class has lots of useful writeXXX methods depending on what you’re doing. In this case we use writeObject() which serializes an object to AMF, and writes it to the ByteArray.
Second, I built a method that compares two ByteArrays. There are several ways that this can be accomplished, I chose straight iteration. If someone knows a faster way, please let me know. The faster the better. Here it is:
public static function isByteArrayDifferent(base : ByteArray, revision : ByteArray) : Boolean {
if (base.length != revision.length)
return true;
for (var i : int = 0; i < base.length; i++) {
if (base[i] != revision[i])
return true;
}
return false;
}
Obviously, if they are different lengths they’re not the same. I like that the method short circuits if a difference is detected, which will be the most common case.
Finally, I wrote the method that accepts the two objects, and returns a Boolean indicating whether a change has been detected. It’s simple, as the preceding two methods do all of the work.
public static function hasObjectChanged(a1 : Object, a2 : Object) : Boolean {
return isByteArrayDifferent( convertToBytes(a1), convertToBytes(a2) );
}
And it works pretty well. There are a few gotchas I will point out, fortunately none of them apply to my application specifically.
First, suppose your object has a collection with two objects, 1 and 2. The order matters when the objects are serialized. An object with 1,2 will serialize differently than the same object with 2,1. Depending on your application you may have to handle this case specially (if 2,1 is considered the same as 1,2).
Second, you can’t use this method to tell if two objects are the same instance in memory. There are other ways of doing that, this isn’t one of them.
ByteArrays are very useful and have loads of other applications (see the ObjectUtil.copy() method to see how to make copies of objects using ByteArrays. I’ll include a quick method I threw together to output the contents of a ByteArray (it’s very similar to isByteArrayDifferent(), in case anyone’s interested. I used it for debugging, but it can be easily modified to return the String instead of outputting it.
public static function outputBytes(label : String, block : ByteArray) : void {
var s : String = "";
for (var i : int = 0; i < block.length; i++) {
s = s + uint(block[i]).toString(16) + " ";
}
trace (label + ": " + s);
trace();
}

