A Flex application is software that you create using the various pieces of the Adobe Flex 3 product line, which includes the following:

One major difference between the SDK and Flex Builder is that the SDK is free, while Flex Builder is available only through a license that you purchase from Adobe Systems. But in addition to the Flex SDK that's at the core of Flex Builder, the complete development environment includes many tools that will make your application development more productive and less error-prone than working with the SDK and another editing environment.

Flex Builder 3 Professional (the more complete and expensive of the available Flex Builder licenses) also includes a set of components known as the Data Visualization Toolkit that aren't included in the SDK. The Data Visualization Toolkit includes the Flex Charting components for presenting data as interactive visual charts and a new component called the AdvancedDataGrid that presents relational data with groups, summaries, multi-column sorting, and other advanced features.

Flex programming languages

Flex 3 applications are written using two programming languages — ActionScript 3 and MXML:

When you compile a Flex application, your MXML code is rewritten in the background into pure ActionScript 3. MXML can be described as a "convenience language" for Action Script 3 that makes it easier and faster to write your applications than if you had to code completely in Action Script.

The diagram in Figure 1.1 describes the relationship between the Flex SDK's command-line compiler, Flex Builder, the MXML and Action Script programming languages, and the Flash Player and Adobe Integrated Runtime.

MXML versus Action Script 3

MXML and Action Script can be used interchangeably in many situations. MXML is commonly used to declare visual layout of an application and many objects, but it's usually your choice as a developer as to when to use each language.

Figure 1.1. The Flex SDK and Flex Builder both compile source code in MXML and Action Script, producing executable applications that are hosted by the Flash Player on the Web or the Adobe Integrated Runtime ("AIR") on the desktop.

In these examples, I'm declaring an instance of an Action Script class named Label. The Label class is part of the Flex class library that's included with both the Flex SDK and Flex Builder 3. Its purpose is to present a single line of text in a Flex application.

Declaring objects in MXML

The Label class is represented in MXML as a tag named <mx: Label/>. To create an instance of the Label class using MXML and set its text property to a value of Hello World, declare the tag and set the property as an XML attribute:

<mx:Label id="my Label"  text="Hello World"/>

This results in creating an instance of the Label class that is displayed in the application.

Declaring objects in Action Script 3

The Label class also can be instantiated using Action Script 3. When using the Action Script 3 coding model, you first create the object using the class's constructor method and then add the object to the application's display list so it becomes visible. You can set the text property anytime after creating the object:

import mx.controls.Label;
var myLabel:Label = new Label();
myLabel.text = "Hello World";
this.addChild(myLabel);

This Action Script code accomplishes exactly the same steps as the MXML code in the first example. Notice that it takes four lines of Action Script instead of the single line of MXML code. The amount of code needed to accomplish any particular task is a common difference and one of the reasons MXML exists. MXML can significantly reduce the amount of code in your application without compromising its features or performance.

Developers tend to use Flex instead of Flash when they want to create software applications that have these characteristics:

In contrast, developers tend to use Flash when they are creating documents with these characteristics:

Many applications that are built in Flash CS3 could be built in Flex, and vice versa. The selection of development environment, then, is frequently driven by a developers background and existing skill set.

Developing in Flash

As described above, developers who use Flash are frequently focused on presenting animation, hosting video, and the like. Flash is generally considered superior for animation work because of its use of a timeline to control presentations over a designated period of time. Flash supports a variety of animation techniques that make use of the timeline, including these:

Flash also allows you to create animations using pure Action Script code, but that approach also can be used in Flex. Developers who come from a graphic design background and are used to thinking visually appreciate the precision and visual feedback that the Flash development environment provides.

One drawback that application developers encounter with Flash is that the primary source document used in Flash, the .fla file format, is binary. As a result, it doesn't work well with the source control systems that application developers commonly use to manage their development projects, because you can't easily "diff," or discover differences between, different versions of a binary file.

Developing in Flex

Developers who use Flex to build their applications commonly have a background in some other programming language. Documents can be created and made useful in Flash without any programming, but a Flex application is almost entirely code-based. Animations are handled entirely through Action Script, because Flex doesn't have a timeline as part of its development toolkit.

Flex also has superior tools for handling large-scale applications that have dozens or hundreds of views, or screens. Although Flash CS3 has a screen document feature, this feature hasn't received the development attention from Adobe that would make it a compelling architectural choice for these "enterprise" applications.

Finally, Flex applications are built in source code, which is stored in text files. These text files are easy to manage in source-code control applications such as CVS and Subversion. As a result, multi-developer teams who are dependent on these management tools find Flex development to be a natural fit to the way they already work.

The Flex Builder 3 design view feature has become more friendly and useful to graphic designers than in previous versions, but it isn't always intuitive to a designer who's used to "real" graphic design tools like Adobe's own Photoshop, Illustrator, and Fireworks.

Table 1.1 describes some of the core differences between Flex and Flash development.

Flex application development is especially compelling for developers who are already acquainted with object-oriented programming (OOP) methodologies. Object-oriented programming is a set of software development techniques that involve the use of software "objects" to control the behavior of a software application.

Object-oriented programming brings many benefits to software development projects, including these:

You'll find no magic bullets in software development: You can create an application that's difficult to maintain and at risk of collapsing under its own weight in an OOP language just as easily as you can create one that primarily uses procedural programming. But a good understanding of OOP principles can contribute enormously to a successful software development project.

And because Action Script 3 is a completely object-oriented language, it serves Flex developers well to understand the basic concepts of OOP and how they're implemented in Flex development.

Object-oriented programming is commonly supported by use techniques known as modularity, encapsulation, inheritance, and polymorphism.

Modularity

Modularity means that an application should be built in small pieces, or modules. For example, an application that collects data from a user should be broken into modules, each of which has a particular purpose. The code that presents a data entry form, and the code that processes the data after it has been collected, should be stored in distinct and separate code modules. This results in highly maintainable and robust applications, where changes in one module don't automatically affect behavior in another module.

The opposite of modularity is monolithic. In monolithic applications such as the example in Listing 1.1, all the code and behavior of an application are defined in a single source-code file. These applications tend to be highly "brittle," meaning that changes in one section of the application run a high risk of breaking functionality in other areas. Such applications are sometimes referred to as spaghetti code because they tend to have code of very different purposes all wrapped around each other.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Model>
    ...data representation...
    </mx:Model>
    <mx:Script>
    ...ActionScript...
    </mx:Script>
    <mx:HBox>
    <mx:DataGrid>
     <mx:columns>
        <mx:DataGridColumn .../>
        <mx:DataGridColumn .../>
        <mx:DataGridColumn .../>
      </mx:columns>
    </mx:DataGrid>
    <mx:Form>
      <mx:FormItem label="First Name:">
        <TextInput id="fnameInput"/>
      </mx:FormItem>
      <mx:FormItem label="Last Name:">
        <TextInput id="lnameInput"/>
      </mx:FormItem>
      <mx:FormItem label="Address:">
        <TextInput id="addressInput"/>
      </mx:FormItem>
    </mx:Form>
    </mx:HBox>
</mx:Application>

In the above application, all the applications functionality is mixed together: data modeling, data collection, and logical scripting. Although the application might work, making changes without introducing bugs will be difficult, especially for a multi-developer team trying to work together on the application without constantly disrupting each other's work.

A modular application such as the version in Listing 1.2 breaks up functionality into modules that each handle one part of the applications requirement's. This architecture is easier to maintain because the programmer knows immediately which module requires changes for any particular feature.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
  <mx:Script source="scriptFunctions.as"/>
  <valueObjects:AValueObject id="vo"/>
  <views:ADataGrid id="grid"/>
  <forms:AForm id="form"/>
</mx:Application>

Flex implements modularity through the use of MXML components and Action Script classes that together implement the bulk of an application's functionality.

Encapsulation

Encapsulation means that a software object should hide as much of its internal implementation from the rest of the application as possible, and should expose its functionality only through publicly documented "members" of the object. A class definition that's properly encapsulated exposes and documents these object members to allow the application to set properties, call methods, handle events, and refer to constants. The documentation of the object members is known as the application programming interface (API) of the class.

In the Flex class library, class members include:

In Flex, encapsulation is fully implemented in Action Script 3. Each member that you define in a class can be marked using an access modifier to indicate whether the particular method or property is public, private, protected, or internal. A public method, for example, allows the application to execute functionality that's encapsulated within the class, without the programmer who's calling the method having to know the details of how the action is actually executed.

For example, imagine a class that knows how to display a video in the Flash Player and allows the developer to start, stop, and pause the video, and control the video's audio volume. The code that executes these functions would have to know lots about how video is handled in Flash and the particular calls that would need to be made to make the audio louder or softer. The API of the class, however, could be extremely simple, including methods to execute each of these actions.

public class VideoPlayer()
   {

    public function VideoPlayer(video:String):null
    { ... call video libraries to load a video ... }

    public function start()
    { ... call video libraries to play the video ... }

    public function stop()
    { ... call video libraries to stop the video ... }

    public function setVolume(volume:int):null
    { ... call video libraries to reset the volume ... }

   }

The application that instantiates and uses the class wouldn't need to know any of the details; it just needs to know how to call the methods:

var myVideoPlayer:VideoPlayer = new      VideoPlayer("myvideo.flv");
myVideoPlayer.start();
myVideoPlayer.setVolume(1);

We say, then, that the VideoPlayer class encapsulates complex behavior, hiding the details of the implementation from the rest of the application.

Inheritance

Inheritance refers to the ability of any class to extend any other class and thereby inherit that class's properties, methods, and so on. An inheritance model allows the developer to define classes with certain members (properties, methods, and so on) and then to share those members with the classes that extend them.

In an inheritance relationship, the class that already has the capabilities you want to inherit is called the superclass, or base class, or parent class. The class that extends that class is known as the subclass, or derived class, or child class. Unified Modeling Language (UML) is a standardized visual language for visually describing class relationships and structures. In this book, I frequently use UML diagrams such as the example in Figure 1.2 to describe how a class is built or its relationship to other classes.

Figure 1.2. This is an example of a UML diagram that describes a relationship between a base and a derived class.

One class can extend a class that in turn extends another. UML diagrams can be extended to describe these relationships as well. The UML diagram in Figure 1.3 describes a three-tier inheritance relationship between a super class named Animal and subclasses named Dog and Poodle.

Figure 1.3. This diagram describes a three-part inheritance relationship.

In Figure 1.2, methods of the super class Animal are inherited by the subclass Dog. Dog has additional methods and properties that aren't shared with its superclass and that can override the superclass's existing methods with its own implementations. The same relationship exists between Dog and Poodle.

Because all versions of Animal sleep in the same way, calling Dog. sleep () or Poodle . sleep () actually calls the version of the method implemented in Animal. But because Dog has its own run () method, calling Dog. run () or Poodle . run () calls that version of the method. And finally, because all dogs bark in a different way, calling Poodle . bark () calls a unique version of the bark () method that's implemented in that particular class.

Inheritance allows you to grow an application over time, creating new subclasses as the need for differing functionality becomes apparent.

In Flex, the Action Script inheritance model allows you to create extended versions of the components included in the Flex class library without modifying the original versions. Then, if an upgraded version of the original class is delivered by Adobe, a simple recompilation of the application that uses the extended class will automatically receive the upgraded features.

Polymorphism

Polymorphism means that you can write methods that accept arguments, or parameters, data typed as instances of a superclass, but then pass an instance of a subclass to the same method. Because all subclasses that extend a particular superclass share the same set of methods, properties, and other object members, the method that expects an instance of the super class also can accept instances of the subclass and know that those methods can be called safely.

Polymorphism also can be used with a programming model known as an interface. An interface is essentially an abstract class that can't be directly instantiated. Its purpose is to define a set of methods and other object members and to describe how those methods should be written. But in an interface such as the one described in Figure 1.4, the method isn't actually implemented; it only describes the arguments and return data types that any particular method should have.

A class "implements" an interface by creating concrete versions of the interface's methods that actually do something. As with the relationship between super and subclasses, a method might be written that accepts an instance of the interface as an argument. At runtime, you actually pass an instance of the implementing class.

For example, you might decide that Animal should be abstract; that is, you would never create an instance of an Animal, only of a particular species. The following code describes the interface:

public interface Animal
{
  public function sleep()
  {}
}

Figure 1.4. This UML diagram describes the relationship between an interface and an implementing class.

The interface doesn't actually implement these methods. Its purpose is to define the method names and structures. A class that implements the interface might look like this:

public class Dog implements Animal
{
  public function sleep()
  { ... actual code to make the dog sleep ... }
  public function bark()
  { ... actual code to make the dog bark ... }
}

Notice that a class that implements an interface can add other methods that the interface doesn't require. This approach is sometimes known as contract-based programming. The interface constitutes a contract between the method that expects a particular set of methods and the object that implements those methods.

Flex supports polymorphism both through the relationship between super classes and subclasses and through creation and implementation of interfaces in Action Script 3.

FutureWave Software originally created a product called Future Splash Animator, which in turn evolved from a product called SmartSketch. The player for the animations was Java-based and was the ancestor of the current Adobe Flash Player. After its purchase by Macromedia, the product was renamed and released in 1996 as Macromedia Flash 1.0.

The product went through a steady evolution, starting with basic Web animation and eventually becoming a full-featured programming environment with rich media (video and audio) hosting capabilities.

During its time with Macromedia, Flash (the IDE) was packaged as part the Studio bundle and was integrated with other Studio products such as Dreamweaver and Fireworks. Macromedia positioned Flash MX and MX 2004 as development environments for what the company began to call rich internet applications(RIAs). Although the development environment that was Flash never fully satisfied the requirements of application developers (see the discussion in the section "Flex versus Flash development" of issues that are commonly encountered in Flash when developing true applications), the Flash Player continued to grow in its ability to host the finished applications, however they were built.

After Adobe Systems purchased Macromedia, Flash became a part of the Adobe Creative Suite 3 (CS3) product bundles. Along with this rebundling came increased integration with other CS3 products such as Illustrator and Photoshop. Other Adobe products such as AfterEffects and Premiere received new export features that allow their video-based output files to be integrated into Flash-based presentations.

Table 1.2 describes the major milestones in the history of the Flash Player.

Each new product bundling and relationship has increased the requirements for the Flash Player. As a result, the most recent version of the Player (version 9) has all the features I've described:

One of the attractions of the Flash Player is its nearly ubiquitous penetration rate in the Web. Each new version of the Player has achieved a faster rate of installation growth than each version before it; version 9 is no different. As of December 2007 (according to statistics published on Adobes Web site), the penetration rate for Flash Player 7 was 99% or greater, Flash Player 8 was at 98% or greater, and Flash Player 9 already had a penetration rate of 93% or greater. Of course, these rates change regularly; for the most recent information on Flash Player penetration rates, visit:

http://www.adobe.com/products/player_census/flashplayer/

Penetration rates are very important to organizations that are deciding whether to build applications in Flex, because the availability of Flash Player 9 (required to run both Flex applications and Flash documents built with Action Script 3) determines whether a Flex application will open cleanly or require the user to install or upgrade the Player prior to running the application. If a user needs to install the Flash Player, however, many ways exist to get the job done.

The Debug version of the Flash Player differs from the production version in a number of ways. As described in detail below, you can install the debug version of the Flash Player from installers that are provided with Flex Builder 3 and the Flex 3 SDK.

The Debug version of the Player includes these features:

To ensure that you're running the Debug player, navigate to this Web page in any browser that you think has the Player installed:

http://kb.adobe.com/selfservice/viewContent.do?externalld=tn_19245

As shown in Figure 1.6, you should see a Flash document that tells you which version of the Player is currently installed. When you load this document with the Debug Player, it displays a message indicating that you have the Content Debugger Player. This tool also tells you whether you're running the ActiveX or plug-in Player and what version.

Figure 1.6. Discovering your Flash Player version

As of this writing, Flash Player 9 is available for these operating systems:

For up-to-date information about current operating system support, including minimum browser and hardware requirements, visit this Web page:

http://www.adobe.com/products/flashplayer/productinfo/systemreqs/

The Flash Player can be installed on a user's computer system in a variety of ways:

Uninstalling the Flash Player

Before installing the Flash Player, make sure any existing installations have been removed. The process for uninstalling the Flash Player differs from one operating system to another, but in all cases you must close any browser windows before trying to uninstall the Player

On Windows XP, use the Control Panel's Add or Remove Programs feature, shown in Figure 1.7, and uninstall whatever versions of the Flash Player you find.

Figure 1.7. Windows XP's Add or Remove Programs feature, listing both the plug-in and ActiveX versions of the Flash Player

On Mac OS X, use the uninstaller application that's available for download from this Web page:

www.adobe.com/go/tn_14157

Installation with Flex Builder

As shown in Figure 1.8, when you install Flex Builder 3, you're prompted to install the debug version of the Flash Player as one of the last steps in configuring the installation. You should always accept this part of the installation, because it ensures that your system is equipped with the most recent version of the Player that you need for building, debugging, and testing your Flex applications.

Figure 1.8. The Flex Builder installer prompts you to install the Flash Player plug-in or ActiveX control on currently installed browsers.

Before installing Flex Builder, make sure that you've closed any browser windows. If the installation detects open browser windows, it prompts you to close those windows before continuing the installation process.

Using Flex Builder installation files

If you need to reinstall the debug version of the Flash Player, you should use the version that's included with Flex Builder 3 or the Flex SDK. If you've installed Flex Builder, you can find the installation files in a subfolder within the Flex Builder installation folder. On Windows, this folder is named:

C:Program FilesAdobeFlex Builder 3PlayerWin

This folder has three files:

Before running any of the installers, be sure to close any open browser windows.

Installing the Flash Player from the Web

You also can get the Flash Player from the Adobe Web site. Select a download location depending on whether you want the production or debug version of the Player.

Downloading the production Flash Player

End users who want to run Flex applications and other Flash-based content can download the Flash Player installer from this Web page:

http://www.adobe.com/go/getflashplayer

When you see the page shown in Figure 1.9, you should see a link to download the Flash Player that's appropriate for your operating system and browser.

Figure 1.9. Downloading the Flash Player from Adobe.com

Downloading the debug Flash Player

To download the debug version of the Flash Player, visit this Web page:

http://www.adobe.com/support/flashplayer/downloads.html

As shown in Figure 1.10, you should see links for all versions of the Player, including both debug and production versions for a variety of operating systems and browsers.

Figure 1.10. This is the Adobe Flash Player Support Center.

Flex developers have two sets of development tools: Flex Builder 3 and the Flex 3 SDK.

Flex Builder 3

Flex Builder 3 is an integrated development environment (IDE) for building Flex applications. This is the tool that most developers use to build Flex applications. I describe Flex Builder 3 in detail in Chapter 2.

The Flex Software Developers Kit (SDK)

The Flex class library and command-line tools you need to build Flex applications are completely free. As long as you don't need to use Flex Builder or certain components that require a license, you can download the Flex SDK from Adobe and build and deploy as many applications as you want. The obvious benefit is the cost. The drawback to this approach is that you'll have to select a text editor such Eclipse that doesn't have the specific support for Flex application development that you get with Flex Builder.

If you decide to use the Flex 3 SDK, download the most recent version from Adobe at www.adobe.com/go/flex. The SDK is delivered in a zipped archive file that can be extracted to any platform.

The SDK includes most of the class library you use to build Flex applications. The following components, however, require a license for deployment:

As shown in Figure 1.11, if you decide to use these features without a license, any instances of the charting components or AdvancedDataGrid component are displayed in your application with a watermark indicating that you are using an evaluation version of the component.

In addition to the Flex class library, the Flex 3 SDK includes these command-line tools:

Detailed information about how to use each of these command-line tools is available in the Adobe publication Building and Deploying Flex Applications.

Figure 1.11. A watermarked charting component

Using MXMLC, the command-line compiler

To compile a Flex application with mxmlc, the command-line compiler, it's a good idea to add the location of the Flex 3 SDK bin directory to your system's path. This allows you to run the compiler and other tools from any folder without having to include the entire path in each command. Figure 1.12 shows the command-line compiler.

To compile an application from the command line, switch to the folder that contains your main application file. If you want to try this using the exercise files that are available for download with this book, switch to the chapter01 directory:

cd /flex3bible/chapter01

This directory contains a file called HelloWorld.mxml, a simple Flex application. To compile the application, run this command:

mxmlc HelloWorld.mxml

Figure 1.12. The command-line compiler at work

After the compilation is complete, your directory will contain a new file called Hello World. swf. This is the compiled application that you deploy to your Web server.