June 23, 2008

Flex Application Debugger

Posted by Jeremy Mitchell
A familiar activity to all developers involves the undesirable but necessary task of application debugging. Fortunately, Flex Builder provides the tools necessary to easily inspect your code and pinpoint logical or potentially fatal run-time errors.

Successful debugging hinges on the debugging skills of the developer and the debugging tools available to the developer. The former can be acquired only through experience and education while the latter is both a product of the development platform and the community and / or corporate tooling support.

Common debugging techniques include tracing (or printing), breakpoint debugging, step-through debugging and watch expressions. Each of these debugging techniques is supported by Flex Builder.

The Flex Builder Debugging perspective contains a code editor and a set of views designed to aid Flex developers in the debugging process. Flex Builder debugging views include Debug view, Console view, Variables view, Breakpoints view and Expressions view.

Flex Builder Debug View

Outlines the application call stack. Each function is displayed in order of execution (with the bottom of the list being the first function called). The Debug view serves as the control center of the Flex debugger. It allows a developer to start / stop application execution and step over lines of code and step into and out of functions.

Flex Builder Console View

Outputs the results of any trace statements added to your code. Also known as "poor man debugging", trace statements are synonymous with print statements or alert statements. Most developers are very familiar with this debugging technique.

Flex Builder Variables View

Displays variables (simple and complex), their value and data type. By selecting a function in the Debug view, you can inspect the current value of the function's local variables (variables limited in scope to the selected function). Variables outside of the function's scope are also available in the Variables view and are labeled as 'This'. Variable values are also configurable allowing developers to test alternate scenarios in hope of obtaining the desired outcome.

Flex Builder Breakpoints View

Displays a list of application breakpoints. Breakpoints allow developers to inspect the state of an application during execution. Breakpoints can be enabled, disabled or removed in the Breakpoints view.

Flex Builder Expressions View

Allows developers to "watch" specific variables through the life cycle of an application. Variables can be added to the Expressions view by selecting 'Create Watch Expression' in the Variables view for a specific variable.

A Debug session is initiated by clicking the Debug icon found on the Flex Builder toolbar and (by default) runs against the HTML wrapper of a Flex application. Therefore, a debug session requires the use of a web browser. (Change the default web browser by selecting Window > Preferences, then General > Web Browser.) Once a breakpoint is encountered, execution is halted and focus is returned to Flex Builder. At this point a developer can analyze the state of the application and make any necessary changes. Changes may include code changes in the code editor, variable changes in the Variables view, adding new breakpoints, etc. Execution is resumed by clicking 'Continue' in the Debug view. When another breakpoint is encountered, execution is halted once again. In the interim, developers may choose to step over each line of code, step into or out of a function. As this is done, variable values change accordingly. This process continues until the application has run its course or the developer terminates the Debug session.

The Flex debugger is not intended to highlight syntax or data type errors. ActionScript is a compiled language (versus interpreted) and those errors are caught by the compiler at compile time. Rather, the Flex debugger provides valuable insight into a Flex application. Debugging is part of the development process and application transparency is necessary to attain project success. The Flex Builder Application Debugger is a vital part of a successful development life cycle.

June 14, 2008

Flex Builder Basics

Posted by Jeremy Mitchell
A Flex application is the result of one or more MXML and / or ActionScript files compiled into a SWF and delivered via HTTP to the client's browser. The Flex SDK provides everything you need to create Flex applications and is available at no cost to you. Armed with a text editor and the Flex SDK, developers can create simple to complex Flex applications.

The process includes the following steps:
  1. Download the Flex SDK
  2. Create a text file with a .MXML extension to serve as your application root file
  3. Create one or more files with a .MXML extension to dictate your application structure and layout
  4. Create one or more files with a .AS extension to encompass your application functionality
  5. From a command line, launch the Flex compiler to convert your MXML and ActionScript files into a published SWF file
More detailed instructions on command line Flex development can be found at Adobe - Flex Developer Center.

Another more practical option available to Flex developers includes the use of Adobe's Flex Builder. Flex Builder is a fully-functional IDE (Integrated Development Environment) available as a plugin for the Eclipse open-source platform. A stand-alone version of Flex Builder is also available and includes a customized distribution of Eclipse coupled with the Flex Builder plugin.

Priced from $250, Flex Builder 3 provides a host of features designed to improve developer productivity and application quality. Features include:
  1. Coding tools (syntax coloring, code completion, code collapse, code refactoring)
  2. Debugging tools (step-through debugger)
  3. WYSIWYG design tools (prebuilt UI components, drag-and-drop layout manager, application transitions (view states), component property inspector)
  4. Styling / skinning tools (CSS design manager, skin manipulation)
  5. Charting tools
  6. Testing tools
  7. Performance monitoring (profiling) tools
The Flex Builder IDE is organized into three perspectives:
  1. Flex Development perspective
  2. Flex Debugging perspective
  3. Flex Profiling perspective
A Flex Builder perspective is a collection of views and editors utilized to perform a group of related tasks (i.e. development tasks, debugging tasks & performance monitoring (profiling) tasks).

Editors are provided for MXML, ActionScript & CSS code authoring and editing. The MXML & CSS editors operate in two modes - source mode & design mode. The ActionScript editor operates in source mode only. Most developers feel comfortable working with the source code of an application, and therefore, spend a lot of time in source mode. Certain tasks (i.e. web service consumption) require the use of Flex Builder's source mode while other tasks encourage the use of Flex Builder's design mode (i.e. UI layout). However, in many cases the choice is a matter of preference as many tasks can be accomplished in either mode (i.e. UI controls instantiation).

Views encapsulate related functionality required of productive developers. Examples include the ability to visually navigate your application hierarchy (Outline View), display properties for a selected element (Flex Properties View), instantiate containers and controls on-the-fly (Components View), or define application states (States View). Views are also used to organize attributes of a Flex application (i.e. problems, breakpoints, variables, expressions, etc.)

As an Eclipse plugin, Flex Builder integrates seamlessly with other complimentary development tools including Subversion and CVS (source control), ANT (automated build tool), FTP (file transfer), unit testing and more.

With Eclipse and Flex Builder 3, developers have the tools necessary to build high quality, robust business applications.

June 7, 2008

ActionScript Basics

Posted by Jeremy Mitchell
The backbone of the Flex Framework is ActionScript 3.0. An object-oriented scripting language based on the ECMAScript standard, ActionScript defines all of the structure / layout and most of the behavior of your Flex application. (CSS is responsible for the formatting / style and a host of server-side scripting languages (ColdFusion, PHP, JSP, .NET, etc) may contribute to your application's behavior.)

The Flex Framework (or SDK) ships with a library of prebuilt ActionScript classes. These prebuilt classes are organized into packages. A package is a mechanism for organizing ActionScript classes. Each package provides two important benefits:

1. A logical grouping of related functionality. For example, the package labeled mx.controls.listClasses contains the classes responsible for providing list-based control functionality.

2. A namespace for an ActionScript class. Without packages, every class name would have to be unique to avoid ambiguity. If every class name must be unique, a developer must know the name of every prebuilt class to avoid naming conflicts when creating custom classes. With packages, a developer is free to name custom classes as he / she likes as long as the name is unique to the package (namespace).

In most cases your use of prebuilt ActionScript classes will be limited to those found in the mx top level package (i.e. mx.charts.effects or mx.controls.menuClasses). These classes (mx) are specific to Flex applications. However, you'll find that since Flex is a subset of Flash, the ActionScript classes found in the 'flash' top level package can also be leveraged in your Flex application (i.e.

If you have any experience with JavaScript, you'll find ActionScript to be pleasantly familiar. After all, JavaScript and ActionScript are based on the same standard, ECMAScript. Outside of using MXML tags (an abstraction layer for ActionScript), the following techniques are used to include ActionScript into a Flex application:

1. Inline ActionScript – typically limited to property assignment or method calls triggered by an event rather than complex business logic, ActionScript can live within an MXML attribute.

<mx:Button id="myButton" click="eventHandler()" />
2. Nested ActionScript – The text node of an MXML element may contain ActionScript. To avoid the parsing of ActionScript in the text node as XML, place the ActionScript within a CDATA block.

<mx:Button label="click me">
myFunction('hi there')
3. MXML Script Tags – As your ActionScript becomes more complex and verbose, an MXML Script tag may be warranted. Again, a CDATA block must be used to prevent parsing of ActionScript as XML.

import mx.controls.Alert;

public function myFunction(message:String):void {;
4. Adhering to object-oriented principles and guidelines often involves the creation of custom ActionScript classes for use in your Flex application. Custom classes are typically an extension of a prebuilt class and occupy their own file with an .AS extension. Like prebuilt classes, custom classes reside in a package. For custom classes, packages are synonymous with directories. Therefore, a custom class file (i.e. found in wwwroot/com/flexdevelopers/view could be referenced from your Flex application as:
The property / methods of a prebuilt or custom class can be utilized by simply importing the class into your application for use:

import com.flexdeveloper.view.MyClass

var myObject:MyClass = new MyClass();
var myVariable:String = myObject.myMethod();
or, by providing a fully-qualified class path in an ActionScript expression / statement:

if (1==1) { com.flexdeveloper.view.MyClass.myStaticMethod(); }