Event handler in code

The event handler is associated with the button in exactly the same way that it was in the inline code example.

Many programmers are of the opinion that this should be done in code. This too is easy and allows us to examine how to access more generally the objects that MXML creates. The basic idea is that the link is via the id you assign to the component and a public variable of the same name in the action script.

So if we give the button in the MXML an id of MyButton:

<s:Button x="45" y="33" 
     id="MyButton" label="Button" />

We need to create a public variable of the same name in the ActionScript file:

public var MyButton:Button;

It also needs to be declared as "bindable" but for the moment let's keep things simple.

We can't simply start using the object because we can’t be sure that the MXML has been processed and the objects created. The solution is to override the initialise method and explicitly call the base class initialise - which ensures that all objects defined in the MXML have been instantiated and their properties set to the appropriate values.

Following this we can be sure that all the objects exist and continue to customise them in code. In this case we simply use the addEventListener method to add the click event handler:

override public function 
            initialize():void
{
 super.initialize();
 MyButton.addEventListener(
  MouseEvent.CLICK,button1_clickHandler);
}

If you now run the program again the result should be the same.

Creating objects in ActionScript

At this point you might think why bother with the MXML at all?

The final example demonstrates that you can do the entire job in ActionScript if you want to:

override public function 
                   initialize():void
{
 super.initialize();
 MyButton=new Button;
 MyButton.addEventListener(
   MouseEvent.CLICK,button1_clickHandler);
 MyButton.label="Hello";
 addElement(MyButton);
}

In this case we create the button object, customise it and add it to the containers display list, all in the initialise function. We are still using an MXML file to create the application but we don't even have to do this but removing it entirely would be some additional work and wouldn't illustrate any new ideas. The commplete MXML file is just:

<?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="*">
</my:MyApp>

Notice that now the MXML file only creates the MyApp object.

More ActionScript

It is worth looking at ActionScript a little more as it is more or less the only language that you can use to develop Flash/Flex/AIR applications.

While being closely modelled on JavaScript it is optionally strongly typed. Of course the paradox here is the use of the words "optionally" and "strongly".

For example, this is legal ActionScript:

var i=32;
Alert.show(i);

and so is this:

var i:Number;
i=32;
Alert.show(i.toString());

Notice that if you declare a variable to have a type then explicit type conversion doesn't happen so you need the toString call in the Alert.show method.

Also it is worth saying that "Number" is something of a generality as far as typing goes! It is also a reflection of the fact that ActionScript doesn't have very many numeric types - and in particular it lacks a decimal type which makes financial calculations difficult.

If you don't want to declare the type of every variable you don't have to and but this might create problems in using the strongly typed framework. On the other hand dynamic typing is popular at the moment and this might make an alternative untyped approach more attractive.

ActionScript is also fully object oriented. It has classes, methods, get and set properties and inheritance. You have already seen the syntax for defining a class and inheriting from another, for example:

public class MyApp extends Application
{

and creating instances is just a matter of using "new".

However, ActionScript is still a dynamic interpreted language and this allows classes to have methods and properties added at run time - something that is only just becoming possible in .NET languages with the help of the dynamic language SDK.

Finally it’s also worth mentioning that there is no credible threading support in ActionScript. It does support and treat asynchronous calls as the norm but you can't do manual threading. How important this is depends on the complexity, interactivity and size of your project.

Many would consider ActionScript to be superior to JavaScript while retaining many of its key advantages - it is also very possibly the future of JavaScript as it evolves towards the same ECMA standard. The big disadvantage of the entire Flex framework is that it is a single language framework. If for any reason you don't like ActionScript then unless you are prepared to create another language to run alongside ActionScript using the same VM there is nothing you can do about it. You can use Javascript with the help of an intermediate script library but this is little different from ActionScript and not really well supported.

Flash or Silverlight?

As Flash/Flex seem to offer the same range of facilities as Silverlight it is worth spending some space on comparing them in detail.

Perhaps the biggest problem with Flash is that it has developed from a designer-oriented special effects platform. It is very usable as a general development environment but it still lags behind .NET in its range of support.

For example there are few, compared to .NET, third party libraries for Flex. It also suffers from not really being understood by Adobe which still seems to think that FlashBuilder is targeted at the designer who has managed to learn to code. However, the one thing that Flash has in its favour, and its not a small consideration, is that it is found on most web browsers almost as standard and it is well accepted by end users. The same cannot be said for Silverlight which, even though it has been downloaded an impressive number of times, is still not commonplace. It is true that most uses of Flash are trivial animations or special effects but it all contributes to its acceptance.

Looking beyond the browser you also have to take into account that a Flex AIR application can work on Windows, Linux and Mac platforms without modification. A Silverlight application, isn't quite so cross platform with Linux support being weak.

<ASIN:059652787X>