That said, I was recently confronted with a situation in which the current service invokers were insufficient. By service invokers, I mean specifically the RemoteObjectInvoker, HTTPServiceInvoker, and WebServiceInvoker classes. Let me explain.
When you use the Web Service code generation tools from FlexBuilder Gumbo MAX Preview, you end up with a service class that wraps a web service and provides a well defined public interface. Each method in the class returns an AsyncToken that allows you to add a responder to be notified of success/failure when the remote method call comes back. The generated code looks something like this:
public class MyService extends WebServiceWrapper
{
public function myRemoteMethod(param1:String, param2:int) : AsyncToken
{
loadWSDLIfNecessary();
var operation:AbstractOperation = _serviceControl.getOperation("myRemoteMethod");
var token:AsyncToken = operation.send(param1, param2);
return token;
}
}
If you've used Cairngorm before, this code should look very familiar. It's the same type of code that you would normally see in the Delegate layer.
How do we use this type of delegate class in Mate? My first approach was to try and use a WebServiceInvoker, but the delegate class is not a WebService. My second approach was to try and leverage AsyncMethodInvoker, but that had a few other problems. The biggest was that the success/failure listeners respond to the class itself and not the token returned by the method. Additionally, the AsyncMethodInvoker doesn't integrate with the UnhandledFaultEvent approach to application-wide service fault handling.
So, I decided the best approach was to create a new kind of invoker, DelegateInvoker, specifically to handle calling these types of delegate classes. Usage is essentially the same as the other Mate service invokers:
<DelegateInvoker instance="{ services.myService }" method="myRemoteMethod"
arguments="{ [ 'param1', 12 ] }"
showBusyCursor="true">
<resultHandlers>
...
</resultHandlers>
<faultHandlers>
...
</faultHandlers>
</DelegateInvoker>
If no faultHandlers are defined, then an UnhandledFaultEvent is generated. This allows the DelegateInvoker to integrate with the application-wide service fault handler.
The DelegateInvoker can be used with any method that returns an AsyncToken. Behind the scenes, the DelegateInvoker attaches a responder to the AsyncToken returned by the method. The responder listens for success/failure and triggers the inner handlers when the method call returns. If the method does not return an AsyncToken to attach a responder to a runtime error is logged.
I've spoken with Nahuel about getting this new DelegateInvoker class incorporated into the Mate core. He will be adding it into the Mate in_development branch. It should be available for download in the next day or so, and I'll update this entry when the class is posted.
The DelegateInvoker class is available as of revision 93 in Mate's SVN. It's currently in the in_development branch, but will eventually be moved to the trunk in a future release.
]]>Usage is exactly the same as before, with the additional option of specifying the strict flag as part of the JSON.decode( string, strict ) call. Example:
- Added throwing error if entire string cannot be consumed (when there are remaining characters left in the input stream)
- Added "strict" flag to decoding process. Default is true for backwards compatibility. When false, relaxes input format rules. Fixes #34, Fixes #41, Fixes #71:
- Allows for hex specification for numbers, ex: { "myNum": 0xFFCC33 }
- Allows for NaN to be parsed as a number, ex: { "myNum": NaN }
- Allows for trailing commas in arrays, ex: [1,2,]
- Allows for trailing commas in objects, ex: { "p1":true, "p2":false, }
- Does not throw error if there were characters left in the input string
- Added tests for strict flag
- Added tests to better exercise comments
- Updated tests to use proper assert types
- Some minor cosmetic code cleanup
// Set strict mode to false to allow for trailing commas to not throw an error var o:Array = JSON.decode( "[0,1,]", false ) as Array; assertEquals( 0, o[0] ); assertEquals( 1, o[1] ); // Same usage as before, strict mode will throw a runtime error if the string is not valid var a:Array = JSON.decode( "[0,1,]" ) as Array;
A default event handler is a method of a component that handles the same event it dispatches and performs some default action. This happens a lot in component development. A component can dispatch an event, but also act on that event with some default behavior. You don't have to explicitly listen for the event because the default action happens automatically within the component itself.
For example, let's think about a "closeable" tab navigator. When you click on the "x" to close a tab, a "closeTab" event might be dispatched to signal that a tab is intended to be closed. The tab navigator itself listens for the "closeTab" event and provides a default behavior of removing the tab that was intended to be closed.
But what if you want to present the user with a confirm dialog first before the tab gets removed? In this situation, you don't want the default behavior to occur because the tab will be removed before the user has a chance to respond to the confirm dialog. So, you need a way to prevent the tab from being removed by the component.
There are 4 things associated with creating default event handlers and allowing them to be canceled. They are:
Rather than elaborating on these pieces with a few paragraphs of text, I think a code sample illustrates this best. Here's a sample component that has an "alarm" event with a default behavior of just showing an Alert dialog to let you know the default behavior has happened:
package
{
import flash.events.Event;
import mx.controls.Alert;
import mx.core.EventPriority;
import mx.core.UIComponent;
[Event( name="alarm", type="flash.events.Event" )]
public class MyComponent extends UIComponent
{
public function MyComponent()
{
// Assign a default event listener for the "alarm" event. The key here
// is the event priority of DEFAULT_HANDLER. This is a low priority and
// allows normal listeners to execute first, giving them a chance to call
// event.preventDefault() to cancel the event's default behavior
addEventListener( "alarm", handleAlarm, false, EventPriority.DEFAULT_HANDLER, true );
}
/***
* Silly method here just to have the component dispatch an event that it
* has a default behavior for.
*/
public function triggerAlarm():void
{
// Create a new event of type alarm. The key here is the third
// parameter which signals that the event is allowed to be canceled
// via event.preventDefault();
dispatchEvent( new Event( "alarm", false, true ) );
}
/**
* The default behavior for handling the "alarm" event
*/
protected function handleAlarm( event:Event ):void
{
// Check to see whether or not the event had it's default behavior prevented
// by another event listener
if ( !event.isDefaultPrevented() )
{
// The event has NOT been canceled, so continue with
// the default behavior
Alert.show( "handleAlarm default handler executed from MyComponent" );
}
}
} // end class
} // end package
Here's a sample Flex application using this component. I add a listener for the "alarm" event, and if the user wants to cancel the default event behavior I call event.preventDefault() in my alarm listener:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" xmlns:local="*">
<mx:Script>
<![CDATA[
protected function handleAlarm( event:Event ):void
{
// Just for example purposes, we have a flag in the UI to indicate
// if we want to prevent the default event handler from executing
// or not...
if ( preventToggle.selected )
{
trace( "Default behavior is prevented" );
event.preventDefault();
}
else
{
trace( "We didn't prevent the default behavior, so we'll see the alert from MyComponent." );
}
}
]]>
</mx:Script>
<mx:Button label="Trigger Event" click="myComp.triggerAlarm();" />
<mx:CheckBox id="preventToggle" label="Prevent default behavior?" selected="true" />
<local:MyComponent id="myComp" alarm="handleAlarm( event );" />
</mx:Application>
So, there you have it! There's not much to it really, but it's a pretty useful technique. I'd actually like to see this covered a bit more in the Events portion of the livedocs site. Creating cancelable default event behaviors is a key part of Flex component development. Having a solid understanding of events will go a long way when it comes to building Flex applications.
Enjoy!
]]>Let's take a look at a quick example. I was launching Firefox with the following technique:
// In linux.properties browser = firefox // In win.properties browser = C:/Program Files/Mozilla Firefox/firefox.exe
<!-- Launch the browser via the exec ANT task -->
<exec executable="${browser}" spawn="yes">
<arg line="${output.index.html}" />
</exec>
Naturally, since this worked on Linux and Windows I figured it would work on OSX just fine as long as I got the path to the browser correct. The first thing that I tried was this:
browser = /Applications/Firefox.app/Contents/MacOS/firefox
When I tested this it almost worked. If I didn't have Firefox already open, it would open the browser correctly and display my target output file. However, things broke down if I already had an instance of Firefox open.
Rather than open the target output file in a new tab (which was the Linux/Win behavior), I would get an error dialog saying that Firefox was already in use and that I was only allowed to launch one instance of it at a time. It asked me to quit Firefox first, and then try again. Since I almost always have a browser window open to keep tabs on my webmail, obviously this wasn't a workable solution for me.
After a bit of digging and experimenting, I came up with the idea of using the "open" command and passing it the Firefox application as a parameter. This has been working great so far and only required a slight modification to the script:
// In mac.properties #browser = open -a Firefox #Does not work, need to pass -a Firefox as args to exec browser = open browser.args = -a Firefox
<!-- Updated the exec tag to use additional arguments -->
<exec executable="${browser}" spawn="yes">
<arg line="${browser.args}" />
<arg line="${output.index.html}" />
</exec>
I know this really isn't new or groundbreaking information here. But, I couldn't find an easy answer trying to google for my problem. I'm posting this to try and save someone else some time in the future who might be running into the same problem that I did. Enjoy!
P.S. I'm starting to like OSX, but I still prefer Linux. I'd consider myself somewhat of a power-user, and there's just too many things Linux has that OSX doesn't. However, I can't get my external monitor xinerama display to work in Linux (doh!) so I think I'm an official OSX user for the time being until I can get my xorg.conf configured right...
]]>Ever since developers have been using ActionScript 3 the quest for the perfect Singleton has been underway. The heart of the issue is that there are no private constructors in ActionScript 3. Thus, it's been a tricky road trying to find the best way to prevent other developers from inadvertently invoking a Singleton's constructor and creating an additional (and erroneous) instance.
For example, a quick google search yields quite a few results. Here are a handful of them that I've tried to place in chronological order:
What do I think? My initial reaction was to not worry about it. Seriously, what does it matter? Do we really need compile time checking? Isn't runtime checking and unit testing enough? If a developer uses the class wrong, is that the class author's fault? As long as there is documentation as to what the class is and how it's used, then this is really a non-issue at best and trivial at worst.
Admittedly that's a bit of a naive attitude. However, in over a year of not caring about the private constructor issue I can honestly say that I've never run into a problem with singletons, or had any of my team members accidentally use them the wrong way.
It was actually a combination of other factors (and personal preference) that made me revisit the singleton pattern. The singleton technique that I prefer was developed to address the other issues I was running into and to reflect my personal coding style. While I was at it, I figured I might as well address the private constructor issue too. After all, we all love being smacked around by the compiler sometimes.
The technique I prefer has the following highlights:
So, with that said, I thought it was worth throwing my singleton version into the ring. This is the method I prefer. If you like it, great. If not, that's fine too. No hard feelings. Really.
Sample code is after the jump.
]]> package someProject.model { // This import is required for Flex 2 //import flash.events.EventDispatcher; [Bindable] public class Model // To avoid binding warnings to "instance" in Flex 2 we need to // explicitly extends EventDispatcher and add [Bindable] to the // static instance getter. //extends EventDispatcher { /** Sample model property. The name of the currently logged in user. */ public var userName:String; // ======================================= // Singleton instance // ======================================= /** Storage for the singleton instance. */ private static const _instance:Model = new Model( SingletonLock ); /** Provides singleton access to the instance. */ // We can use the Bindable metadata with an event name to prevent // Flex from reporting that "instance is not bindable". We have to // use a custom event name because you cannot just use [Bindable] // with a static function (it's a compiler error). // // Since we never actually change the instance, we never need to // dispatch an event, so there is no negative side effects here. If // you're getting warnings in the console log, try uncommenting the line // below. This isn't necessary with recent Flex 3 builds, but it is for // Flex 2. //[Bindable( "instanceChange" )] public static function get instance():Model { return _instance; } /** * Constructor * * @param lock The Singleton lock class to pevent outside instantiation. */ public function Model( lock:Class ) { // Verify that the lock is the correct class reference. if ( lock != SingletonLock ) { throw new Error( "Invalid Singleton access. Use Model.instance." ); } // Normal construction can continue here userName = "sample user"; } } // end class } // end package /** * This is a private class declared outside of the package * that is only accessible to classes inside of the Model.as * file. Because of that, no outside code is able to get a * reference to this class to pass to the constructor, which * enables us to prevent outside instantiation. */ class SingletonLock { } // end classThis still doesn't feel right to me. I don't like the private locking class as I think it's a bit of a hack. But, the compile time and runtime checking is a nice feature to help prevent mistakes. Additionally, the singleton related code in the class takes away from the actual meat of the class itself. I want the class to be a Singleton, but I don't want to have to wade through the Singleton code when I'm working on it. I'm also tempted to remove the get instance and just make it public static const instance. The compiler will prevent assignment to const so the read-only property is a little redundant.
I think my ideal situation would be to introduce new [Singleton] metadata that would automatically take care of the implementation details. The metadata is self documenting as it clearly indicates that the class is intended to be a singleton. The compiler would be able to write the singleton related code for us automatically so that we don't have to do it ourselves and so that it doesn't get lost in the actual meat of the class.
Here's an example of what I envision:
[Singleton( "get instance" )]
// or, if you really want to use getInstance() instead...
//[Singleton( "getInstance()" )]
[Bindable]
public class Model
{
/** Sample model property. The name of the currently logged in user. */
public var userName:String;
/**
* Constructor
*/
public function Model()
{
userName = "sample user";
}
} // end class
} // end package
How cool is that? We clearly mark the class as a singleton and provide the mechanism we want to use to access the singleton instance (either a read-only property, or a static accessor). Then, we let the compiler do the work behind the scenes. I think this ends up being a really clean and elegant solution.
Obviously this doesn't work today because it would need modifications to the mxmlc compiler. I've submitted this as enhancement request ASC-3033. However, since Flex is going open source this is something we could build in our own if we really wanted to, in theory. Food for thought...
Anyway, enjoy!
]]>A downside of using Cairngorm is that you need to remember that Cairngorm events are "special". Because of how the controller registers listeners, you need to dispatch Cairngorm events through the CairngormEventDispatcher instance in order for the associated commands to execute. Self-dispatching events were added in Cairngorm 2.2 to make things a little easier, but that addition still doesn't address the fact that these events are "different" from other events:
public function doLogin():void
{
var event:LoginEvent = new LoginEvent( username.text, password.text );
// Dispatch through the dispatcher directly
CairngormEventDispatcher.getInstance().dispatchEvent( event );
// Or, have the event dispatch itself using Cairngorm 2.2+
event.dispatch();
}
A better approach, I think, is to remove the "special"-ness of Cairngorm events and treat them the same as any other regular event. Rather than having to remember that Cairngorm events get dispatched a special way, doesn't it make sense to simply use the standard dispatchEvent function?
In order to accomplish this, we need to abstract the Cairngorm event dispatching logic further up the chain. We still need to to dispatch Cairngorm events through the CairngormEventDispatcher instance, but we can create an abstraction that allows us to not have to know this extra information. This abstraction allows us to treat Cairngorm events as regular events and just dispatchEvent() them.
So how do we create this abstraction? Simple. We hook dispatchEvent at the UIComponent level. Example code after the jump.
]]> /** Create the dispatch event hook when the Application is created. */ private static dispatchEventHooked:Boolean = hookDispatchEvent(); /** * Add a hook into dispatchEvent high up in the inheritance chain. Any * subclass of UIComponent is now "CairngormEvent-aware" and no longer * needs separate event dispatching code for Cairngorm events. */ private static function hookDispatchEvent():Boolean { UIComponent.mx_internal::dispatchEventHook = cairngormDispatchEventHook; return true; } /** * The event hook itself. Any time we encounter a CairngormEvent, we * dispatch it through the centralized CairngormEventDispatcher. This * abstraction prevents subclasses from having to know how to deal with * Cairngorm events. */ private static function cairngormDispatchEventHook( event:Event, uic:UIComponent ):void { if ( event is CairngormEvent ) { CairngormEventDispatcher.getInstance().dispatchEvent( event as CairngormEvent ); } }The beauty of this approach is that it allows you to use dispatchEvent( cairngormEvent ) from any view in your application. This includes nested child views, popup windows, etc. Additionally, it doesn't interfere with regular events and normal event dispatching. The hook simply allows some code to be run before the regular dispatchEvent is called. Cairngorm events make it to the controller via the hook, and regular events still get dispatched as normal.
That said, there are a few downsides to this technique.
That said, I've been using this on my current project without any issues to speak of so far. It's been great to have a consistent event dispatching mechanism, and finally cleans up one of the "messy" aspects of Cairngorm.
]]>As I've spoken about before, when the Open Source Flex initiative was first announced one of the things I was most excited about was the opening of a publicly accessible issue management system. I've touched on a little bit of my reasoning here, but wanted to call attention to how awesome a system like this truly is.
If you use Flex day in and day out like I do, chances are you're going to run into issues or things that you think can be improved. That's just the nature of software development. Having access to the public bugbase allows you to be actively involved in identifying issues and helping to improve the product for other developers. Better yet, when you encounter a problem it allows you to defer the work of fixing or working around the issue to Adobe.
Let me share an example to demonstrate what I mean.
Earlier this summer I ran into a strange issue with the DateChooser component. Code that should have worked was failing for no apparent reason.
I opened up a web browser to the Flex bugbase, http://bugs.adobe.com/flex/, and searched for the issue. There are a lot of search options here, but I just used the "Quick Search" to get started looking, and then narrowed down via the extended options.
After searching for my specific issue, I didn't see anything related to the problem I was having. This meant that Adobe was not aware of a potential issue. So, I created a new issue describing my problem.
The process for creating a new issue is really straightforward. Use the "Create New Issue" link and just describe the problem your encountering. Having sample code to reproduce the problem really helps well. When you're done creating the issue it gets assigned an id.
For my particular issue, it was assigned SDK-12004. Since this issue was affecting my ability to complete some code I was working on, I was really interested to find out what Adobe thought and I wanted to be notified if anything changed on the issue. I clicked the "Watch it" link so that any changes to the issue would be emailed to me.
By watching the issue I was able to see it move through the Adobe QA system. I knew who was looking at it and what their thoughts where. I was emailed anytime someone commented on the issue, and ultimately I knew when it was fixed. In this case, another bug was found that was related to my original report but not quite the same, so SDK-12008 was opened as well. I opted to watch that issue too since it also affected what I was working on at the time.
When I saw that the issue was resolved as fixed, I found the comment with the associated build number of the fix. Here's where things get really interesting. The particular issue was listed as working fine in build 179224. Sweet, but where's the code for that?
Did you know there are nightly builds of the Flex SDK?
Did you know that when an issue in the bug system is fixed, you can grab the code for the fix from the nightly SDK having a build number greater than or equal to the issue's "fixed in build" number? You have to agree to the terms of the early build access license, but once you click the checkbox for that there is a matrix at the bottom of the page that populates with links to download the nightly build. Even better, there's a change log for each version.
I scanned the change logs looking for the change set that related to my SDK-12004 and SDK-12008 issues. When I found it, I made note of the files that were changed. Then, I downloaded that particular nightly build that contained the fix.
I should note here that the nightly builds are actually for the upcoming Flex 3 SDK, but my current project is still using the Flex 2.0.1 hotfix 3 SDK.
I used the "underriding" technique that Doug described here to apply the changes to my current SDK. Essentially, I took the code for the files that have changed and created versions of them in my local project. My project now has an "mx.controls.DateChooser" class defined that contains the code from the nightly build. Because it has the same fully qualified name as the default DateChooser in my Flex 2.0.1 hf 3 SDK, the version in my project takes greater precedence and it is what gets compiled into the ptoject and used.
This allowed me to apply only the the relevant changes from the nightly build without affecting the rest of my installed SDK. It took a little bit of effort to remove some of the "Flex 3" features from the updated code to downgrade it to work with the Flex 2.0.1 hf 3 SDK, but it wasn't a difficult process.
If you're already using Flex 3, it's even easier to apply a nightly build. In fact, you can just add the nightly build as a new installed SDK in FlexBuilder 3 and simply recompile your project with that SDK to incorporate the changes. It was only because I'm using an older SDK that I had to go through the process of manually applying the changes.
To summarize:
1. I ran into a bug
2. I looked to see if it was a known issue or already fixed
3. It wasn't, so I told Adobe about it
4. I watched the bug to keep informed of its progress
5. Adobe developed a fix for me
6. I downloaded the nightly SDK that included the code for the fix
7. I applied the fix in my project
8. All is well
A positive side effect here is that the fix now goes out to all developers who will be using the Flex 3 SDK going forward. By identifying issues and being involved you not only help yourself by getting Adobe to do the work for you, but you also help the entire Flex community by allowing Adobe to continually improve an already amazing product.
This process isn't limited to just bugs. If you think something could be done better, log an issue for it. It will get prioritized, and Adobe might even take your advice and build the enhancement into a future version.
So, if you haven't been using the Flex bug base, isn't it about time you start?
]]>ObjectUtil.copy is a wonderful utility method to perform a deep copy of an object. Its implementation is also amazingly simple:
var buffer:ByteArray = new ByteArray(); buffer.writeObject(value); buffer.position = 0; var result:Object = buffer.readObject(); return result;
Rather than using introspection and recursively copying properties from one object to another, the entire object is serialized into a array of bytes. When the bytes are deserialized, a brand new object is created copying all of the original contents.
Simple, but effective. Instead of writing a custom deep copy algorithm , the copy() method uses the built in Flash Player AMF capabilities. This is the same serialization that Flash Remoting uses. When you send an object to the server via Flash Remoting (<mx:RemoteObject/>), you send an AMF array of bytes describing the object that the server deserializes to create an identical object on the server.
Because of using AMF behind the scenes to perform object copies, a few interesting things happen:
When an object is deserialized from AMF, it does not automatically get created as a class instance. The object might have all of the properties of a class instance, but it will not be a true class instance unless the AMF packet includes type information about the object. The type information gets added to AMF in one of two ways:
If you're using [RemoteClass] metadata on a class instance being copied, then it is safe to cast the result as that particular class instance:
// The works if Book has [RemoteClass] metadata var bookCopy:Book = Book( ObjectUtil.copy( book ) );
If you're not using [RemoteClass], before performing the copy you need to register the class against a string alias. The alias is written to the AMF packet so that when the object is deserialized, it can be created as the proper type. For example:
// Book doesn't have [RemoteClass] metadata, so associate the my.package.Book string // with a reference to the Book class. registerClassAlias( "my.package.Book", Book ); // Now we can cast the result of the copy without errors. var bookCopy:Book = Book( ObjectUtil.copy( book ) );
So, what about [Transient], and how is this related to the issue I ran into where the copy wasn't working as I had expected? Now that you know how copy works behind the scenes, let's talk about [Transient].
The [Transient] metadata tag is not very well documented in Flex 2 or 2.0.1. If you look in some of the LiveCycle Data Services documentation you can see mentions of it, but there isn't a dedicated page on the subject. In the beta Flex 3 documentation, [Transient] is finally explained. There is also some documentation gathered on The Flex Non-Docs weblog.
Essentially, what it comes to is that using [Transient] on a property removes that property from the AMF packet during serialization. This is important. The reason [Transient] properties are not sent over the wire via Flash Remoting is because, again, they're not included in the AMF packet.
With the background information explained, onto the problem I ran into. Here's a small class that doesn't copy correctly (after the jump):
]]> package { public class Example { /** Constant for when the flag value indicates option 1. */ public static const OPTION_1:String = "1"; /** Constant for when the flag value indicates option 2. */ public static const OPTION_2:String = "2"; /** Constant for when th flag vlaue indicates no option. */ public static const OPTION_NONE:String = "0"; /** One of the option constants, determines what value is used for. */ public var flag:String; /** The numeric value for whatever option the flag indicates. */ public var value:int; // ================================ // option1 property // ================================ /** * Helper method to get/set the value of option 1. Returns -1 if option 1 * is not the flag value. */ public function get option1():int { return flag == OPTION_1 ? value : -1; } public function set option1( value:int ):void { // Anytime the option1 setter is called, set the flag and save the value flag = OPTION_1; this.value = value; } // ================================ // option2 property // ================================ /** * Helper method to get/set the value of option 2. Returns -1 if option 2 * is not the flag value. */ public function get option2():int { return flag == OPTION_2 ? value : -1; } public function set option2( value:int ):void { // Anytime the option2 setter is called, set the flag and save the value flag = OPTION_2; this.value = value; } } // end class } // end packageWhat's important about this class is that there are really only two values that we care about - flag, and value. I'm using option1 and option2 as helper getter/setters to read and manipulate those properties.
Trying to copy this class yields some interesting behavior:
// Create an object and assign a value var example:Example = new Example(); example.option2 = 123; // Register the class so deserialization preserves the type information registerClassAlias( "Example", Example ); // Make a copy of the original object var copy:Example = Example( ObjectUtil.copy( example ) ); trace( "example: " + example.option2 ); // example: 123 trace( "copy: " + copy.option2 ); // copy: -1 trace( example.flag ); // 2 trace( copy.flag ); // 1
Since example and copy have different option2 values, obviously the copy didn't complete as expected. Where did we go wrong?
When the copy() method serialized the data as AMF, Flash Player not only wrote the flag and value properties and their values, but it also wrote the option1 and option2 values. When the deserialization happened, all 4 properties were read back in. The option1 property was read in after option2. This means the option1 setter was called and changed the values of both flag and value incorrectly. Oops!
The solution, now that we know how [Transient] relates to AMF, is to tag the option1 and option2 helper properties as transient. This excludes them from the AMF serialization and prevents errors when the setters would be called during deserialization:
// Flag option1 as transient so it is not included as part // of the object when copied or sent to the server [Transient] public function get option1():int // ... // ...likewise with option2
After adding [Transient], when the example code is run again only flag and value are serialized (and therefore deserialized and copied). This corrects the original behavior and the copy's option2 value is the same as example's value.
I hope this helps in your understanding of AMF, how it relates to class instances and casting, and what kind of effect the [Transient] metadata actually has behind the scenes. Even if a class is never meant to be sent to the server, [Transient] can still be useful.
]]>I've been hard at work on a large Flex 2 application that utilizes Web Services to communicate with the back-end. I've run into a number of issues that had to be worked around, all of which appear to be fixed by Flex 2.0.1 Hotfix 3.
It looks like Hotfix 3's main focus has been the Web Service classes, adding more stability and fixing lingering issues. This should be a welcome update to anyone who's been banging their head against a wall using Web Services.
One of the issues in particular, using a secure wsdl switches useProxy to true which breaks applications, was quite a pain to deal with. This is where the Open Source Flex announcement really pays dividends. I was able to find the issue in the public facing bugbase and monitor progress. I was happy to see that the issue was already reported, that it already had a valid workaround, and that it was going to be fixed in an upcoming Hotfix 3 release. Kudos to Adobe for having transparency here.
As with any Hotfix release, if you're not experiencing any of the issues that were fixed then it is not recommend that you upgrade. As they say... if it ain't broke...
However, if you're using Web Services you might want to consider the Hotfix 3 upgrade at http://www.adobe.com/go/kb402381.
]]>It turns out that in all of the cases where erroneous parse errors were reported, the JSON string looked something like this:
{ prop1: 12, prop2: "hello, world" }
Can you spot the problem?
According to the JSON spec, the above snippet is not actually valid JSON. The reason? It's because the object property identifiers are not string literals. It may be valid JavaScript/ActionScript for creating an object via a literal, but JSON objects contain pairs of string : value and strings are always enclosed in double quotes.
The ActionScript 3 JSON parser I made is a bit on the strict side, I guess. From what I can gather, a lot of JSON decoders will accept the above snippet as valid JSON. Even worse, a lot of JSON encoders will produce JSON in the above format. That is, when you create a JSON string, behind the scenes the JSON string might not actually be valid. Typically the libraries that produce snippets without quotes around object identifiers will also accept those as valid input, so it's usually not a problem.
So, if you're running into parse errors when trying to decode JSON strings in ActionScript 3... make sure the JSON string is actually valid. The first place to look is for quoted identifiers in objects.
If you're using Ruby on Rails and running into this problem, a simple configuration change on the server end will fix the problem:
>> ActiveSupport::JSON::unquote_hash_key_identifiers=false => false
Thanks to Richard Wallace for pointing out the Rails configuration change necessary to produce valid JSON for the ActionScript 3 JSON decoder.
]]>Essentially, modules are loaded into an application via the ModuleLoader class. A typical example looks like this:
<mx:ModuleLoader id="moduleLoader" url="myModule.swf" />
The problem with this approach is that the URL is hard-coded to always load the non-debug version of the module .swf file. Whenever you create an application/module in FlexBuilder, two .swf files are generated: the release version which just ends in ".swf", and the debug version which ends in "-debug.swf"). When you launch a debug session, the debug .html file launches which instructs Flash Player to load the debug .swf file. The debug .swf contains additional information to help the debugger along so you can examine the running application in detail.
In the case of debugging with modules, when you debug the debug version of the main application is loaded and the debugger launches, but the release version of the modules are loaded because of the hard-coded reference to the module's URL. This means that you can't get debugging information from your modules because the release .swf which loads does not contain the debugging information.
The fix is pretty straightforward. When you need to debug the application you have to load the "-debug.swf" module, and when you want to create a release version you have to load the normal .swf file. Rather than constantly changing the URL on each ModuleLoader instance, I've been using a static getter "constant" that makes the process transparent:
public final class Constants
{
/** The path to the swf file for my module. */
public static function get MY_MODULE_SWF():String
{
// Check to see if the application is the debug version, and if
// so then use the debug module...
if ( Application( Application.application ).url.indexOf( "debug" ) >= 0 )
{
return "MyModule-debug.swf";
}
// ...otherwise use the release module
return "MyModule.swf";
}
}
The ModuleLoader then needs to have the url property set via ActionScript. If you try to use binding in the MXML tag itself, you'll get a warning about not being able to detect changes in the { } binding syntax, and trying to make the getter [Bindable] will complain that you can't create bindable static functions. It's a minor annoyance, but I hardly notice it since I control module loading via ActionScript anyway:
moduleLoader.url = Constants.MY_MODULE_SWF; // Load the module var module:IModuleInfo = ModuleManager.getModule( Constants.MY_MODULE_SWF ); module.load();
A nice side effect of using this simple technique is being able to use a "constant" to reference the module from anywhere via the ModuleManager.getModule method.
Now, no matter if you run or debug, the correct version of the module gets loaded and the fact that you're using modules becomes transparent. I believe this is an area that Adobe is hoping to improve upon in Flex 3 (Moxie) and in the future as well, but the above is a good workaround in the near term.
I've been using modules quite a bit for the past few months on my current project. Hopefully I'll have some time in the future to share a few more tips and tricks like this for creating modular architectures in Flex RIAs.
]]>The HorizontalAxisDataSelector is a relatively simple chart annotation that allows a user to select a value along the horizontal axis of the chart. When the uses mouses down on the chart, the selector dispatches a change event and draws a vertical line at the nearest data point along the x-axis.
The selector contains a dataValues property that is an array containing the y value of each chart series at the given x-axis location. You can use these values to present a clear view to the user of all of the y-values for a given x-value rather than forcing them to rely on mousing over data tip points.
You can view the example here, along with the example source code.
Integrating the chart annotation basically just involves adding the following to your chart:
<mx:annotationElements> <flexlib:HorizontalAxisDataSelector id="dataSelector" change="updateDetails();" selectorColor="0x000000" /> </mx:annotationElements>
This is something I wrote a really long time ago, probably on the order of 6 months or so (6 months is like an eon or two in internet-time). It's nothing special by any means, and is still rough around the edges. I had wanted to re-visit it and make some improvements, but just haven't found the time to work on it. As such, I figured it was best to just publish it since it's actually proven itself useful a few times, rather than hold on to it waiting until I have the time to get around to updating it.
In its current form, you can only use this annotation on horizontal axes that are numeric (or date-driven), and that are in ascending order. Kind of a bummer, I know. If you need to use this on a category axis, feel free to modify the source and contribute it back into FlexLib once you get it working!
Note: Right now this is only available in SVN. Doug and I are still sorting out when the best time is to create new packaged FlexLib .swc releases.
On a related note, this annotation isn't nearly as cool as some of the annotations Ely has come up with. His Chart Sampler is amazing. My meager annotation barely scratches the surface of what is possible in the charting framework. To this day I'm still amazed at just how flexible and extensible the charting framework is...
]]>Friend: Would you happen to have any idea why when i include 'import flash.external.ExternalInterface;' i can't use it, like 'ExternalInterface.available' gives me 'Access of possibly undefined property available through a reference with static type Class.'
Me: hmm, smells fishy.
Friend: yeah i'm thinking something is hosed with my fbuilder or something
Me: I wonder if it's one of the .swc library files, like playerglobal.swc, in the framework lib directory
Me: Have you installed something that might've overwritten that, like apollo?
Friend: yeah, apollo
Me: maybe it just got overwritten by a bad version then, check to see when it was last modified
Friend: i don't think that's it, same date as the others
Me: hmm, ok, nevermind then
Friend: when I i do ExternalInterface. something
Friend: nothing comes up
Me: are you sure its the EI class that the error is coming from?
Me: and not a different compiler error?
Me: sometimes that happens when you have a syntax error in the file
Friend: oo maybe
Me: like, FB can't process the code hints because of a previous error (previous meaning in time, not necessarily earlier in the file)
Friend: let me try something
Me: if you're not getting code hints, check to make sure you have matching {}'s, ()'s, etc.
Friend: that's it, it works now
Me: I'm going to blog this quickly :-)
Friend: haha, i work with this clown that can't write code that compiles and asks me why it doesn't work
Me: nah, I won't mention you by name, unless you want me too.. haha
Friend: oo the problem was that my project was named ExternalInterface as well
Moral of the story: I have multiple personalities, and I'm really just talking to myself. Wait.. no....
Moral of the story: If you ping me on IM be aware that I just might make an example of you on my weblog! Wait.. that's not it either!
Real moral of the story: Sometimes the error you're getting from FlexBuilder is misleading. If all of a sudden something stops working such as code hints, or you get an error message that just doesn't make sense, check to make sure the rest of the file has correct syntax. Sometimes there are situations where FlexBuilder erroneously reports one error when it should've reported something else.
Also, check to make sure that you don't have an mxml file with the same name as another class you're trying to use. Remember, all mxml files are compiled into ActionScript 3.0 classes behind the scenes. You might have to use a fully-qualified name for a class if you have a conflicting mxml file that shares the same name. For example, use flash.external.ExternalInterface.available if you already have an ExternalInterface.mxml file.
These types of errors don't happen often, but when they do hopefully the above information will help you to fix them!
]]>