FDB; command line Actionscript debugger.

FDB is the command line debugger that comes bundled in with the Flex SDK. While it's arguably not as quick or easy to use as the debugger supplied with Flash Builder it is free and useful to quickly step through a project that you don't have set up in Flash Builder. It's also very straight forward to use as a remote debugger.

Below I will run through some simple usage with FDB.

The program itself lives in the bin folder of the Flex SDK. Running it provides you with a command prompt from which you can launch an application and begin debugging.

Launching

To launch an application you type run or r followed by a space and the address to the swf or mxml application you wish to launch. If you don't specify anything, then FDB will wait for a debug player to connect. This is the method I usually use and is also the only method available to Mac users.

If you just used run with no address to launch you now have a small amount of time to load up the application to be debugged. All going well you should see a message like the one pictured below.

Just a couple of notes: don't launch an swf through the Flash IDE as this will steal the debug connection, and also make sure the swf is debug enabled.

Setting up

Depending on how you ran FDB up there is a chance you will now need to add source directories. This is achieved by typing directory or dir followed by a ';' delimited list (':' on a Mac) of source paths. You can list current source paths by typing info sources or i so.

Now you can add break points. This is done by typing something like the following: break Main.as:20. This will add a break point at line 20 of the file Main.as. You can also specify method names instead of line numbers, e.g. break Main.as:getSomething. You can review break points by typing info break or i b and delete them by type delete n or d n where n is the number given to the break point when it was created.

Once you have finished setting break points continue the swfs execution by typing continue or c.

 

Stepping through code

Once a break point is encountered execution halts and you will be presented with a screen like this.

From here you can use a number of commands to analyse the situation. You can type step or s to step over a line of code, next or n to step into a line of code or finish (f) to step return to the calling method. You can print variables by typing print varname as well as list all of an object properties with print object. (notice the full stop after the property name).

 

Other useful commands while execution is halted are bt or where to print a backtrace of all stack frames. Print out lines of source code using list either alone or with a line number, method name or file name/line number combination. For more information on these command type help either alone or followed by any other command for general or specific information.

Once you are finished looking at this particular break point type continue to resume execution.

Finishing

To finish either close the Flash Player, or when execution is halted type kill or k followed by y when prompted. From here you can begin another session by typing run, and if it is the same swf then all your previous source paths and break points will still exist.

This covers basic operation. Hopefully I will have time to cover some of FDB's more advanced features in another post.

Deploying Flash / Flex to server using Ant.

This post contains a few simple steps to setting up an Ant target that will deploy a Flash or Flex project ( or anything really ) to a server.

This is a useful addition to an Ant build, saving time copying files manually and preventing potential errors occurring when trying to remember which files to copy.

To begin with it is assumed that you are using Flash/Flex Builder/Eclipse and that Ant is set up for it. If you don't have Ant set up then there are plenty of good tutorials showing how to, such as this one.

The main Ant task used is the SCP task, documentation for which can be found here. This isn't included in the Ant distribution and requires the jsch library. I had problems using the latest version in Flex Builder 3 with Ant 1.7, but found version 0.1.29 to work fine. This version is available here.

To set up the jar file in Eclipse go to the Window menu and select Preferences.... Open Ant in the tree menu on the left and select Runtime. Then under the Classpath tab to the right select Global Entries and click on the Add External JARs... button. Browse to and select the jsch jar file. You should now be set to use the various jsch tasks including the SCP task.

A basic target to copy a bin folder to a folder on a server would look something like this:


<target name="deploy" >
    <scp 
        trust="true"
        password="${password}" 
        todir="${server.user}@${server.address}:${server.loc}">
        <fileset dir="${bindir}" /> 
    </scp> 
</target>

Obviously all the variables are held in a .properties file declared earlier in the build file making the target more reusable, but you could equally hard code the values in.

If you don't want to have a password in a .properties file then you can add a dialog to the task for password entry. Ant offers the input task, but doesn't provide any way of *ing out the text entry. There are several third party tasks that offer this functionality. One good one is the query task from the JeraAntTasks library.

To use this download the jar file from the above link and add it to Ant's Global Entries in Eclipse the same way the jsch jar was added above. Then go to the Types tab and click on the Add Type... button. In the window that opens enter a name ( this is the name that you will use in your build file ), select the JeraAntTasks.jar from the location dropdown. Navigate to the anttasks package in the bottom left tree menu and select Query.class in the bottom right hand menu. Press OK.

You can now add a password dialog box to the target so it looks something like this:


<target name="deploy" > 
    <query name="password" password="true" />
    <scp
        trust="true" 
        password="${password}" 
        todir="${server.user}@${server.address}:${server.loc}"> 
        <fileset dir="${bindir}" /> 
    </scp> 
</target> 

In place of having a password variable in a .properties file, it is now declared by the query task. Remember to replace query with whatever you called it in the previous step.

This is a relatively simple target, but could be expanded to do pretty much whatever you like when combined with other build targets and other tasks, such as the SSHEXEC task for example.

A few notes on Git

I have been using git for a while now on my own projects; largely using github to host them. ( Having lost vpn access to my old firm's svn repository :) )

I recently started to learn more about the system having stumbled across this excellent - and free - online book. It is highly recommended reading for anyone looking to get into, or learn more about git.

Git offers quite a few benefits over centrally managed version control systems. I would definitely recommend checking out the book linked above for a more comprehensive overview, but those features I have found most useful are:

  • Faster. Most operations occur locally, so it is a lot faster to use for most operations.
  • Branching. The branching system is far superior, allowing you to easily switch between different branches of work with very little effort or overhead.
  • Local. I can make commits, branches and do what I like without a network connection. Then once I have one I can push my work back to a remote.

There are quite a few other benefits, but these are the ones that have stood out for me over the last few months. On the downside, compared to svn for example, it does seem a little more complicated and there aren't quite as many good gui tools around. Here are a few worth having a look at:

As a side note, this guy is doing some interesting stuff with git at the moment. I particularly like the idea of his ShowOff project for presentations.

Flash debug player in Chrome.

Because Chrome comes with its own Flash plugin it takes a couple of quick steps to get the debug version of the player working.

Before anything ensure the Plugin content debugger is installed. This is downloadable for here and the currently running version can be checked here.

Next load up Chrome and go to about:plugins from the address bar.

Click on the Details button to show more information about each plugin and scroll down to the Flash plugin section.

There should be two plugins listed. Simply disable the one in the Chrome application data folder (probably the first one) and the debug player will be active.

Stop Firefox killing Flash plugin while debugging.

For quite a long time now I've just allowed Firefox to kill the Flash plugin while I'm debugging. Annoying, but not annoying enough to do anything about it. However, with a quick settings tweak I can now leave Firefox hanging for as long as I like while debugging. Simply navigate to about:config in Firefox, continue past its warnings and then find (for Windows) dom.ipc.plugins.enabled.npswf32.dll in the list. Right-click on it and toggle it to false. For Mac OS/X and Linux the value to toggle is dom.ipc.plugins.enabled.libflashplayer.so. Also check that dom.ipc.plugins.enabled is on its default setting of false. Alternatively, look for dom.ipc.plugins.timeoutSecs and change it to -1. Newer builds of Firefox (3.7a1pre and above) only use the dom.ipc.plugins.enabled value, which is true by default. If you're using one of these versions just change it to false. If you only want to disable crash protection for Flash then manually add in an entry for dom.ipc.plugins.enabled.flash player.plugin. Having just said this about newer build, during a quick test on 4.0b7pre Windows with default settings, the plugin hang for as long as I allowed it without being terminated. For more information, have a look here.

AIR 2 Native Process Example - Mouse Screen Position

I had been wanting to have a play around with the native process classes that were added in AIR 2 for quite some time, but only recently managed to get around to doing so. Something that had always bugged me with AIR (and the Flash platform in general) was the lack of any way of getting the screen mouse position when the application wasn't being interacted with. So as a way of experimenting with the native process feature I wrote a little AIR application that interacts with a c++ process and outputs the mouse position at all times.

Starting and interacting with a native process from AIR is actually pretty straightforward. It is essentially a case of setting up a NativeProcessStartupInfo object, a NativeProcess object and adding event listeners to the NativeProcess. Here is this section in the example application:

This is in fact all the Actionscript code in the example. Application complete calls onAppComplete which checks if native process is supported. If so a NativeProcessStartupInfo is created and a reference to the process file set on it's executable property. This is then passed to a NativeProcess object, which is started and has several listeners added to it.

Of the listeners added the most important to this example is ProgressEvent.STANDARD_OUTPUT_DATA. This listens for updates to the process' standard output, and updates the output variable in the application.

The second part to this example is the c++ application. Before I go into this I'd like to note that I'm no c++ developer, so there are probably faster/cleaner/better ways to go about what I have done. Below is the code for the small application used:

This program takes the current mouse position, converts it to a string of the form 'x : y' and outputs it on the standard output. This is done on an infinite loop every 100 milliseconds. This output is picked up by the AIR application and displayed as described earlier.

This program is built and bundled with the AIR application, which is then built as a native installer for Windows. This is one of the limitations of using native processes. You have to build the application as a native application, which means having to do it for each individual platform you intend it to be deployed on. In this examples case, it will only work on Windows, because the underlying process will only work on Windows. Although it could be built to work on other platforms, doing so would add effort and potential problems.

The c++ element of this example was build using Microsoft Visual c++ 2010 Express as a Win32 console application.

Project Files

Swiz BeanProvider in Actionscript another way.

In my previous post about using Swiz in Actionscript projects I demonstrated one way of implementing a BeanProvider class. This method essentially mimics what Flex does when it compiles an mxml bean provider into actionscript.

This is a somewhat laborious way of doing things, and on bigger projects ends up large and difficult to read. Below is an example of another way to make an actionscript BeanProvider:

 
package 
{ 
    import org.swizframework.core.Bean;
    import org.swizframework.core.BeanProvider; 
    import org.swizframework.core.Prototype; 
 
    public class Beans extends BeanProvider 
    { 
 
        public function Beans(beans:Array=null)
        { 
            beans = createBeans( beans ); 
            super(beans);
        }


        protected function createBeans( beans:Array ):Array 
        { 
            if( !beans ) 
                beans = []; 

            beans.push( new Bean( 
                new SomeController(), "someController"  ) ); 
            beans.push(
                new Bean( new SomeModel(), "someModel" ) ); 



            var prototype:Prototype = new Prototype( SomePresModel ); 
            prototype.singleton = true; 
            prototype.constructorArguments = ["abc", 123, true ]; 
            beans.push( new Bean( prototype ) );	

            return beans;
        }
    } 
}
 

In this example Bean instances are created and passed instances of our controllers/model or prototypes. An Array of these beans is then passed onto the superclass' constructor. It's as simple as that.

I have chosen to move the population of the beans array in to a separate protected method to allow greater control to sub classes, but it's by no means a necessary step.

Loading AS2 swfs as AS3 swf using ForcibleLoader.

This is a quick post to recommend using Spark projects ForcibleLoader (available here) class if you're ever in the situation of needing to load an old AS2 swf (that you probably have no source to) as an AS3 swf within an AS3 project.

You will then end up with a MovieClip rather than an AVM1Movie, and are able to manipulate it as you would a basic MovieClip class.

Unfortunately this won't let you load up scripted AS2 swfs and interact with them as though they were AS3, but in certain circumstances it can be a massive time saver (as I found recently).

Below is a simple use example. It doesn't really need any explanation, as it's all fairly straight forward.

 
package 
 { 
 import flash.display.Loader; 
 import flash.display.Sprite; 
 import flash.events.Event; 
 import flash.events.IOErrorEvent; 
 import flash.events.SecurityErrorEvent; 
 import flash.net.URLRequest; 
 import org.libspark.utils.ForcibleLoader; 
 
public class Main extends Sprite 
 { 
    public var loader:Loader; 
    public var forceLoader:ForcibleLoader; 
 
    public function Main() 
    { 
        loader = new Loader(); 
        forceLoader = new ForcibleLoader( loader ); 
 
        loader.contentLoaderInfo.addEventListener( 
            Event.COMPLETE, loadCompleteHandler ); 
        loader.contentLoaderInfo.addEventListener(     
            IOErrorEvent.IO_ERROR, ioErrorHandler );
        loader.contentLoaderInfo.addEventListener( 
            SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler );
        forceLoader.load( new URLRequest( "anOldAs2Movie.swf" ) );
    } 
 
    private function loadCompleteHandler(e:Event):void 
    { 
        //TODO handle load 
    } 
 
    private function securityErrorHandler(e:SecurityErrorEvent):void 
    { 
        //TODO handle some security errors 
    }


    private function ioErrorHandler(e:IOErrorEvent):void 
    { 
        //TODO handle some IO errors 
    } 
 } 
} 

Swiz in Actionscript Projects (including Flash IDE projects)

I've been spending a bit of time with Swiz 1.0 and thought I would see how easy it was to get it working with actionscript projects. Most of the documentation focuses on how to configure Swiz in Flex 3 and 4, but not how to do so in pure actionscript.

Turns out its actually pretty easy: either in Flex Builder or the Flash IDE. The only caveat to it being truely pure actionscript is that you need to use Flex's framework.swc in order to let Swiz use data binding, and rpc.swc to use some of Swiz's service classes.

The first step is to setup the project. For this you'll need to download a copy of Swiz and a copy of the Flex SDK. Then setup a new project and add the Swiz swc (e.g. swiz-framework-1.0.0-RC1), and Flex's framework.swc (found in flex_sdk_dir/frameworks/libs/) to the project's library path.

By using the Swiz swc there is no need to add the -keep-as3-metadata compiler argument. If you're using the Flash IDE, then you'll need to turn on the 'Export SWC' option in the Publish Settings' flash menu. This is a little workaround that stops Flash stripping the metadata out of your code. ( Thanks to Patrick Mowrer for that ).

Next step is to configure Swiz. This is usually done in MXML in a Flex project, but can just as easily be done in actionscript.

To begin with we create a new SwizConfig instance, and set its eventPackages and viewPackages properties to match our package structure. There are a lot of other properties we could set here, but there's no need for a normal project.

Next we create a Swiz instance, passing it:

  • An EventDispatcher. One high up on the display list to catch views being added, and bubbling events they dispatch.
  • Our config instance.
  • An array of BeanProviders (or BeanLoaders), either as instances or class references. More on this below.
  • We then call init on our Swiz instance, and that's it, we're off.

    Stepping back a second though, we needed a BeanProvider to pass to Swiz in the previous step. An actionscript BeanProvider looks something like this:

    Essentially just defining a getter/setter for each bean is all that's needed. There are other ways to do this, but I won't go into details here.

    That's all there is to it. You're now set to start using Swiz in your project. I've included a very basic skeleton project that has both a Flex Builder and Flash IDE version. To use them you'll need to change the library path locations for framework.swc so they point to wherever you have your flex sdk installed. The project doesn't do very much, just trace out statements showing that Swiz is working the way it should.

    Actionscript Swiz example.

    Swiz, Degrafa and YouTube Demo Application.

    Here's a little demonstration application I recently put together using a combination of Flex, Swiz, Degrafa and the YouTube API.

    You can see the application and view/download the source here: http://www.davespanton.com/demo/TubeDemo.html

    It uses a presentation model pattern to decouple the views from the rest off the application and Swiz to manage dependency injection and event handling.

    The rest of the application speaks for itself, so feel free to dig in and have a look.

    UPDATE : Due to changes in the youtube API the demo no longer works as it once did.