Building Robotlegs SWC Using Maven – Failed to launch Flash Player

First, a little backstory on how I got to this error in the first place (bear with me). I recently start a project using Robotlegs 2.0.0. Since this version was just released, a lot of the extensions are still being ported over. In my case, I had need of the RelaxedEventMap extension, which I had used heavily with RL1. Thankfully, CReynders was kind enough to port the existing RL1 source over to an RL2 extension; however, porting the extension also required a few minor tweaks to the RL framework source. What this meant to me is that if I wanted to use the RelaxedEventMap extension, I would need to download the latest Robotlegs source from GitHub which contained the previously mentioned tweaks (i.e. I could no longer use the latest compiled version of the RL2 SWC). I didn’t assume this would be a big deal, that is, until I tried to compile my application using Flash Pro. The compile-time went from about 2 seconds using the compiled RL2 SWC, to upwards of 30 seconds when including the RL2 framework source. All this led me down the path of compiling the RL2 SWC myself for the first time (see, I told you’d I’d get to the point eventually!).

I won’t go into great detail on how to compile the source here (perhaps in a future article); however, I would like to touch on a very annoying error I ran into during this process. Keep in mind that I am on OSX, so this may or may not be applicable to you Windows users out there, but I think the concepts should still carry over. So after going through the process of getting all the Maven dependencies installed (which is outlined in the file included in the RL2 download), I went ahead and ran “mvn clean install -s settings.xml.” After about 15 seconds I got the following error:

[ERROR] Failed to execute goal org.sonatype.flexmojos:flexmojos-maven-plugin:4.0-RC2:test-run (default-test-run) on project robotlegs-framework: Failed to launch Flash Player. Probably java was not able to find flashplayer.
[ERROR] Make sure flashplayer is available on PATH
[ERROR] or use -DflashPlayer.command=${flashplayer executable}
[ERROR] Read more at: Cannot run program “Flash Player”: error=2, No such file or directory

Without going into too much detail on the extremely frustrating next couple of hours, I will get straight to the fix. On OSX Maven is looking for the flash player executable in your path; the trick is the name of the flash player executable. On OSX it must be “Flash Player”, on Windows it “FlashPlayer.exe”.

So to solve my problem, I downloaded the latest Flash Player (I chose to go with the Projector Content Debugger), unpackaged it, then copied the Flash Player Debugger executable to my /usr/local/bin directory (you can put it wherever you like, you just have to make sure to update and include the path in your PATH variable).

Now the next issue: The Flash Player package that you download is actually called “Flash Player”; however, the executable inside of this package is named Flash Player Debugger (remember how I mentioned it MUST be called Flash Player). To fix this (again Mac only instructions, not sure about Windows for this one, sorry) right-click on the Flash Player package, and select “show package contents.” Next click into “contents”, then “MacOS.” Inside of MacOS you should find the Flash Player Debugger executable (might be called something else depending on which package you downloaded). Whatever the filename is, change it to “Flash Player”.

The last step is to make sure that this file is in your PATH. There are plenty of instructions out there on how to updated your PATH variable, and it’s different on each OS and users system, so I won’t cover that here; however, you will need to make sure that the following path is included in your PATH: “{Path to your flash player installation}/Flash”. So for my setup, it would look like this: /usr/local/bin/Flash

After getting all this corrected, I re-ran the maven build process and everything worked beautifully! One last gotcha, when Maven compiles the Robotlegs 2 SWC, it places it in the “target” directory. This may be logical to people with more Maven experience, but I’m a newb so it’s a gotcha to me! Hope this helps!

How Robotlegs Keeps me Relaxed with the RelaxedEventMap

While implementing the Robotlegs framework into my first application, I came across a rather common issue: How do I properly manage my views? To give you the basic run-down, my application has a number of different views (menus and various other screens) that need to be shown on the display at different times throughout the application lifecycle. What I wanted was a way to store all of my views, and be able to map events to show a specific view at a given time (ex: a user clicks the logout button in some component, I want the login menu to be shown). Add to this situation the fact dependency injection (while wonderful) has one pretty major flaw: If the object that needs to listen for a particular event is created after the event is dispatched, you end up with a race condition, and the object usually loses (and as such could be shown in an invalid state). For the example of the login menu, let’s say that the use clicks the logout button, the event is fired to trigger a logout command, which then tells the application to display the login menu. This is all well and good unless there is some event that the login menu needs to listen for that gets fired before it is created (ex: The logout Command fires an event to tell the app that the user has logged out and this event contains a message “The users has been logged out successfully” that the login menu is supposed to display). If you’re still managing to follow my confusing-ass example, give yourself a high five!

THE SOLUTION: Continue reading

Robotlegs Gotcha #2 – Using Interfaces for your services and models

One of the common practices suggested by the Robotlegs team (and one I have personally grown to love) is the user of Interfaces for your services and data models. What this allows you to do is type-cast all of your injections and other references to these classes using the name of the Interface, then, when mapping these classes, you map the Interace to the either the concrete class or a seperate “mock” class that can be used for testing. This gives you the ability to quickly swap between mock data and live data by simply changing the injection mappings in your context file (or startup command or wherever you handle your mappings).
Continue reading