Exploration

Notice that by selecting an AIR project type the example could be run as a desktop application. Currently there seems to be no facility for re-targeting an application from web to desktop but you can use the import application command to achieve the same result.

You can now explore the range of controls and other classes provided by the framework. You will discover that it has everything you would expect and there are really no big surprises if you have used the .NET framework or Java Swing or whatever. Using Flex from this point on is a matter of exploration and there is very little that is totally new.

Debugging

Another range of facilities that are worth investigating at this stage are the debugging options. You have all of the usual tools to hand. You can set breakpoints, single step, step over and out, and examine and change variables as you inspect the code. There are lots of other useful Eclipse modules installed by default and you can download and install others. In particular you can profile your application and there is a full source control and bug tracking system. All of this is icing on the cake but don't expect them all to work in a way that is familiar - they take time to adapt to.

Code behind

Now we come to a controversial topic in the Flash/Flex world - code behind. It seems that scattering code in code blocks within an MXML file is the way that many Flash applications are written. It has to be admitted that it has a simplicity that is difficult to beat, but most programmers, especially .NET programmers, would find the mix of markup and code difficult to accept.

The solution is to use code behind, i.e. keep the code in one file and the markup in another. This can be done but there are no facilities in FlashBuilder to help you to do this. What is surprising is that nothing in this area has been improved in FlashBuilder 4 and the reasons why aren't entirely obvious. 

For example, there is no way of automatically generating an event handler in a code behind file - you either have to use copy and paste from the MXML file or do the job by hand. It also doesn’t support features like partial classes that make mixing generated and customised code much easier.

This isn’t difficult but it might well be a big enough disadvantage for a .NET programmer to decide that this isn't a well developed system.

If you recall, MXML is essentially a way to instantiate objects and set their properties. As such you really don't need it any more than you actually need HTML or XAML. The entire job can be done in an ActionScript file by creating the objects and setting properties.

Before looking at this approach let's first migrate the Hello World example to a code behind configuration.

First add a new ActionScript class to the project - leave it in the default package and name it MyApp.as. Enter the following code, some of which will have been generated and some can be generated if you use Content Assist to select completions:

package
{
 import flash.events.MouseEvent;
 import mx.controls.Alert;
 import spark.components.Application;
 public class MyApp extends Application
 {
  public function MyApp()
  {
   super();
  }

  public function button1_clickHandler(
                  event:MouseEvent):void
  {
   Alert.show("Hello Flash World");
  }
 }
}

This essentially the same code we had earlier but now it is within a new class that inherits from the Application class complete with a suitable method to act as an event handler. Notice that at this stage the event handler isn't connected to any objects events.

The next task is to modify the MXML file.  This starts off in the usual way but now we need to link the MXML file to the ActionScript file we have just created. As it is in the same "default" package it is in the same namespace and so we can make the connection using xmlns:my="*" which means include everything in the project directory. If you want to be selective about what is imported you need to store the class in a subdirectory and specify it in the xmlns attribute.

The whole MXML file is:

<?xml version="1.0" encoding="utf-8"?>
 <my:MyApp 
  xmlns:fx="http://ns.adobe.com/mxml/2009" 
  xmlns:s="library://ns.adobe.com/flex/spark" 
  xmlns:mx="library://ns.adobe.com/flex/mx"
  minWidth="955" minHeight="600"
  xmlns:my="*">
 <s:Button x="45" y="33" label="Button" 
  click="button1_clickHandler(event)"/>    
</my:MyApp>

Notice that now the application is actually an instance of MyApp which includes the event handler we want to use.

This is the general principle of code behind - create new classes and instantiate them using MXML. If you run the project you should find that it produces the same result.

<ASIN:0321564251>

<ASIN:0596522509>