Making FlexMonkey and Mate Property Injection Play Nice Together

For the past month I’ve had my head buried in the world of Flex programming. It’s an exciting world where rich interfaces can be easily prototyped and built out. Overall, I’m finding that the general enterprise development architecture for the platform is very young. And this can lead to some problems.

Two areas I’ve been focusing on are implementing a test strategy and framework for Flex applications, and implementing an MVC solution for flex applications.

For testing, I’ve been using FlexMonkey, which despite its youth, is a very handy application for testing stand-alone flex applications. It’s not so handy when it comes to testing an integrated application of traditional HTML based web-app which interacts with a Flex-driven application, but that’s an issue for another blog post.

I’ve also been using Mate for MVC implementation. But Mate is more than simply an MVC impl for Flex. It also provides IoC implementation, and a nice tag-based event handling and mapping architecture for interacting with the server.

For the past 24 hours I’ve been wrestling with an issue that emerged when our application was being tested inside of the FlexMonkeyLauncher.swf. We were encountering numerous ActionScript-style NPEs. Objects that were supposed to be bound and populated after a login event, were coming back null. But this was only happening when run inside of the FlexMonkey test runner. When our application was running standalone everything behaved fine.

Each of the bindable variables had one thing in common. They were being populated by Mate property injectors. Think of spring bean injection, but for Flex. When the application was run in FlexMonkey the property injection was silently failing. Eventually, I determined that because our app was not the parent app when FlexMonkey was involved, the Mate binder was not finding the target views in the run-time display list, and property injection was failing silently. It would be nicer if there was a debug log saying something like “Hey, that view you said had that one variable I should use? Remember that one? I can’t find it, so I’m exiting. Have a nice day!”

In the end, the solution was to use the InjectorRegistry singleton provided by Mate to explicitly register any views in my application which contained public variables which needed to be hooked up for bindable property injection. Here’s an example:

<!–
Here’s my Flex UIComponent instance, in this case a VBox.
Under normal circumstances it would have more attributes, but
I’m only calling out the necessary one for the example
–>
<mx:VBox initialize=”onInit()” xmlns:mate=”http://mate.asfusion.com/”>

<mx:Script>
<![CDATA[
// Import the injector registry
import com.asfusion.mate.ioc.InjectorRegistry;

// Define the function to run when the component/view is initialized
private function onInit() : void {
InjectorRegistry.register(this); // Add this VBox to the injector registry
}

[Bindable]

public var myBindableArray : ArrayCollection;
]]>
</mx:Script>

</mx:VBox>

I tried a couple of other approaches, including the <InjectorTarget /> tag, but that didn’t work how I expected it to. I’d definitely be happy to hear from Mate or FlexMonkey folks who have a better workaround for this. But if you’ve run into this incompatibility, hopefully this solution will save you some time.

My Experience with Windows

On the first day of my new job I was handed a Windows laptop. This came as a bit of a surprise because prior to my start date they had asked me whether I wanted to work on Mac or Windows, and I said Mac.

it was quickly explained to me that a certain set of circumstances had resulted in me receiving a bulky Dell machine with Windows XP loaded on it, in lieu of an Apple machine, and that some time over the next few weeks I would be getting a Mac.

In the meantime, I would have to make due with Windows. I actually hadn’t used Windows as my primary operating system for almost eight years. The last time I’d used it was when I was managing the web site at Carthage College. I was dreading having to work on the machine as my main development environment while learning my role in a new company, and learning a new programming platform (Flex).

I was actually surprised at how (relatively) comfortable I was on the machine. I’ve of course used Windows for years to do testing and debugging for web applications, but not as my main development machine. Cygwin was definitely handy. There are lots of powerful command-line interactions that I can achieve much quicker in a *nix shell than in DOS. So whenever I needed to do something familiar on the command-line, but didn’t know the best way to do it in DOS, I could always fall back on the Cygwin prompt.

After a couple of weeks, I finally got my nice 17″ Macbook Pro and dropped the Dell off at the sys. admin.’s desk. The experience reminded me of why I don’t use Windows. One of the major annoyances was having to start and stop my resin server with each deployment, even though I had hot deployment turned on. This is more of a deficiency in Resin, I think, than in Windows.

But one of the frustrating aspects of this excercise was that after a resin server was stopped, Windows still hadn’t unlocked the files that the Resin server was using. There was always some indeterminate lag-time between the time the server stopped and the time that the files in its deployment directory would become available again. This is a tiny thing in the scope of an overall operating system, but in iterative development it’s HUGE. Enough to remind a developer like me why I use a *nix environment.

This blog post created on a Mac.