In this lesson, you will:
• Create a Flash Builder project
• Understand the parts of the Flash Builder workbench: editors, views, and perspectives
• Create, save, and run application files
• Use some of the features in Flash Builder that make application development faster and easier, such as code hinting and local history
• Work in both Source view and Design view
• Use various views, such as the Package Explorer
You’re ready to start your adventure of learning Adobe Flex, so the first thing to do is become familiar with the environment in which you will be developing your applications. This environment is Adobe Flash Builder, which is based on the Eclipse platform. The Eclipse platform is an open source integrated development environment (IDE) that can be extended. Flash Builder has extended and customized Eclipse for building Flex applications.
In this lesson, you’ll become familiar with Flash Builder by building the main application files of the FlexGrocer application that you’ll be working on throughout this book. While working on the FlexGrocer application, you’ll learn about the Flash Builder interface and how to create, run, and save application files. You’ll also discover some of the many features Flash Builder offers to make application development easier.
Before you can build a building, you must lay the foundation. This lesson is the foundation for further Flex development. You will finish this lesson knowing how to manipulate Flash Builder in ways that make the process of Flex development easier and faster. Along the way, you will create the main application file that defines the FlexGrocer application.
Part of the study of any new body of knowledge is learning a basic vocabulary, and in this lesson you will learn the basic vocabulary of both Flex development and Flash Builder. You’ll understand terms such as view, perspective, and editor in relationship to the Flash Builder workbench. Also, you’ll understand the terms describing the processes that transform the text you enter in Flash Builder into the type of file you can view with your browser using Flash Player.
In this first exercise, you will create a Flex application. To do so, you must first create a project in Flash Builder. A project is nothing more than a collection of files and folders that help you organize your work. All the files you create for the FlexGrocer application will be in this project. You’ll also see that you have two choices when working with an application file: You can work in either Source view or Design view. In most cases, the view you choose will be a personal preference, but at times some functionality will be available in only one view.
Also in this exercise, you will run the Flex application. You’ll discover how the code you write is turned into a SWF file that is viewed in a browser.
This is most likely the way you will start Flash Builder. You may have already installed Eclipse on your computer and added the Flex functionality using the plug-in configuration. In that case, you need to open Eclipse as you have before, and switch to the Flash perspective.
Driveroot is a placeholder for the name of the root drive of the operating system you are using, either Windows or Mac. Replace driveroot with the appropriate path. Also, note that the directory name is case sensitive.
The project name should reflect the files contained in the project. As you continue your work with Flash Builder, you’ll soon have many projects, and the project names will help remind you which files are in each project.
Do not accept the default location entry. The default uses your Documents directory and places files very deep in the directory structure. For simplicity’s sake in this project, you are putting your work files right on the root drive.
Flash Builder lets you choose whether to use the most recent compiler (the default choice) or one from a previous version, by selecting the appropriate “Flex SDK version” radio button. For this application, you should use the Flex 4.5 SDK and compiler.
Flash Builder 4.5 allows you to work with either an older style set of components named mx, the newer style components named spark, or a hybrid of the two. In this book, you will work with the latest components from the spark set only. The mx components are described thoroughly in a variety of materials including the “Flex 3 Training from the Source” series.
By default, Flash Builder gives the main application file the same name as your project name. Flash Builder automatically creates the main application file for you and includes the basic structure of a Flex application file.
Here you see your first Flex application. Currently the application is displayed in Source view. In later lessons, you will also look at this application in Design view.
The default application file contains some basic elements. The first line of code
<?xml version="1.0" encoding="utf-8"?>
is an XML document-type declaration. Because MXML is an XML standard language, the document declaration should be included in the code.
Starting with the second line of code,
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
minWidth="955" minHeight="600">
you will see definitions for a Flex main application and their associated namespaces. A minimum height and width for the application are also defined. The <s:Application>
tag represents the outside container, the holder of all the content in the Flex application. You can have only one <s:Application>
tag per Flex application.
Inside the <s:Application>
tag are two attribute/value pairs that refer to URLs, such as xmlns:fx="http://ns.adobe.com/mxml/2009".
These declarations are XML namespaces: They say where the definitions for the classes you will use in your application are and how you refer to those classes. In Flex 4.5 applications, it is common to have the two namespaces provided, as you are likely to reference three particular libraries of classes: Flex language tags, represented by the fx
namespace and Flex Spark components, represented by the s
namespace.
The Flex language tags represent elements that are needed for Flex 4.5 applications, but these elements are not actually classes within the Flex 4.5 SDK. You will find the <fx:Declarations>
tag one of the more frequently encountered language tags. Declarations will be explained in more detail when events are discussed. The Spark classes represent the set of components, Buttons, Checkboxes, and so on used in Flex 4.5.
In XML nomenclature, the part of the attribute between the colon ( : ) and the equal sign ( = ) is known as the prefix, and the quoted string after the equal sign is known as the Universal Resource Identifier (URI). So, given xmlns:s="library://ns.adobe.com/flex/spark", s
is the prefix, and library://ns.adobe.com/flex/spark
is a URI.
In a configuration file called flex-config.xml, an association is made between these URIs and an associated manifest file. Each manifest file contains a delineation of all the legal tags that can be used with that particular prefix and of the location of the class to which each tag will refer. In a standard installation of Flash Builder on a PC, the manifest files are located in installationdirectory/Adobe/Adobe Flash Builder 4.5/sdks/4.5.0/frameworks. On a Mac, the manifest files are found at installationdirectory/Adobe Flash Builder 4.5/sdks/4.5.0/frameworks. The fx
namespace is pointing to the mxml-2009-manifest.xml, the s
namespace points to the spark-manifest.xml, and the mx
namespace points at the mx-manifest.xml.
If you look in the manifest file for the fx
namespace (mxml-2009-manifest.xml), you’ll notice the conspicuous absence of Declarations as one of the listed classes. In fact fx:Declarations
is not a reference to a class, so much as it is a compiler directive, instructing the compiler how to associate metadata with the ActionScript class created from the MXML. It’s more important to note that the other two manifest files do indeed contain references to all the classes you’ll make use of when using their namespaces.
Part of the spark-manifest.xml file is shown here.
Finally, a minimum height and width are defined for the application. By specifying these, Flash Player will know whether the browser that the application is running in is large enough to fit the application. If the browser is not large enough, scroll bars need to be added to allow the user to access the rest of the application.
Before you do any more work on your application file, you need to become more familiar with the Flash Builder workbench, which is everything you see in Flash Builder. In this exercise you’ll learn what views, editors, and perspectives mean in the workbench.
X
on the right side of the FlexGrocer.mxml editor tab. All editors have a tab at the top left of the editor area.
Whenever you open a file, it is opened in the workbench in what is called an editor. You just closed the editor containing the FlexGrocer.mxml file. You can have many editors open at once in the workbench, and each will contain a file with code in it.
You can also open the file by right-clicking the filename and choosing Open.
Sometimes you’ll want to see as much of your code as possible, especially because Flash Builder does not wrap text. Simply double-clicking, the editor tab expands (maximizes) the editor in both width and height, showing as much code as possible.
As you see, you can easily switch between expanded and non-expanded editors.
The workbench looks radically different in Design view, which allows you to drag user interface controls into the application. You will also be able to set property values in Design view.
Most frequently, you will be using Source view in this book, but some tasks are better performed in Design view.
X
on the Package Explorer tab. Just like editors, views have tabs at their top left.
In Flash Builder, the sections displaying content are called views.
After you close a view, you can reopen it from the Window menu. There are many views; in fact, if you choose Window > Show View > Other, you’ll see a window listing all the views.
A perspective is nothing more than a layout of views that you want to use repeatedly. Flash Builder comes with built-in Flash and Flash Debug perspectives. You can adjust the layout of views in Flash Builder in any way that works best for you, and save it as a perspective by choosing Window > Save Perspective As. Once it’s saved, you can switch to that perspective from the Open Perspective menu at any time.
As you can see, it’s easy to switch between perspectives. Later in the lesson, you’ll use the Debug perspective and discover its many helpful options.
Line numbers are useful because Flash Builder reports errors using line numbers.
In the first exercise, you created your project and an application page. Before you had a chance to run the application, you took a tour of the Flash Builder workbench. You will now get back to your application. You will run it, add code to it, and learn the basics of file manipulation.
When Build Automatically is selected, Flex continuously checks for saved files, compiles them upon saving, and prepares them to run. Even before you run your application, syntax errors are flagged, which does not occur if Build Automatically is not selected.
You have now run your first Flex application, and it wasn’t that interesting. In this case, the skeleton application contained no tags to display anything in the browser. But you did see the application run, and you saw the default browser open and display the results, uninteresting as it was.
What exactly happened when you clicked the Run button? A number of processes occurred. First, the MXML tags in the application file were translated to ActionScript. ActionScript was then used to generate a SWF file, which is the format Flash Player understands. The SWF file was then sent to Flash Player in the browser.
<s:Label>
tag by placing the cursor after the closing </fx:Declarations>
tag; press Enter/Return; enter the less-than sign (<). You will see a long list of tags. Press the letter L (upper- or lowercase) and select the Label tag by highlighting it and pressing Enter or by double-clicking it.
This is an example of code hinting, which is a very helpful feature of Flash Builder of which you should take advantage.
<s:Label>
tag. Press the letter t and then the letter e; then select the text
property.
Code hinting shows only the elements that relate to the selected tag. So, seeing the text
element appear in this list indicates that it is a valid attribute for this tag. Not only can you select tags via code hinting, but you can also choose attributes that belong to those tags.
text
property. Be sure that the text is in the quotes supplied by code hinting.
Given that MXML is an XML language, it is required to follow all XML rules and standards. Proper XML formatting dictates that the value of any attribute be placed in quotes.
Check to be sure that your code appears as follows:
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
minWidth="955" minHeight="600">
<fx:Declarations>
<!-- Place non-visual elements (e.g., services, value objects) here -->
</fx:Declarations>
<s:Label text="My First Flex Application"/>
</s:Application>
The code in this example places the minWidth
and minHeight
attribute/value pairs of the Application tag on a separate indented line. The entire Application tag could have been on one line; whether or not to add line breaks to code is a matter of personal preference. Some developers like the look of placing each attribute/value pair on a separate indented line.
Proper XML syntax gives you two ways to terminate a tag. You just used one of them—to place a slash at the end of the tag, which is called a self-closing tag. The other option is to use the slash in front of the tag name, which is completely typed out again, as follows:
<s:Label text="My First Flex Application">
</s:Label>
You usually use the self-closing tag, unless there is a reason to place something inside a tag block. For example, if you want to place the <s:Label/>
tag inside the <s:Application>
tag block, you have to terminate the </s:Application>
tag on a separate line.
Finally, you get to see something displayed in your new Flex application.
The <s:Application>
tag comes with a default background color of white (#FFFFFF
). You will learn more about adjusting styles in Lesson 16, “Customizing a Flex Application with Styles.”
text
property from “My First Flex Application” to New Text. Save the file and run it.
The next step shows another helpful feature of Flash Builder, but to see this feature you must have at least two saved versions of the file, which is why you changed the text and saved another version of the file.
A large dialog box appears.
You will find this feature very helpful when you want to roll back to a previous version of code.
<s:Label>
tag to <s:Labe>
, and save the file. This will cause an error, because the compiler can find the Label class in the s namespace, but not a Labe class.
After you save the file, the compiler checks your code. The error is found and reported in two ways. First, a small white X
in a red circle will appear next to the line of code in which the coding mistake is located. Also, a description of the error appears in the Problems view.
You can place the pointer over the Red circle by the line number to see the complete description. You can also double-click the error listed in the Problems view, and the pointer will then appear at the appropriate line of code in the editor.
Because of the compile-time error, Flash Builder will not be able to compile the application with the latest change. If you click Proceed in this dialog box, Flash Builder will run the last successfully compiled version of your application.
As you build applications, things will sometimes not work properly or will perhaps throw errors. To help you understand what is causing these problems, Flash Builder has an interactive debugger. The debugger lets you set breakpoints in the code and inspect various property and variable values at the point where the execution of the code stops. You can also use the debugger to step through the code, so you can see how those values change over time.
If you haven’t done so already, please follow the instruction in the appendix on Installing Lesson Files.
If the DebugTest directory does not exist (and it probably doesn’t, unless you have done these steps before), it will be created for you. If it does exist, and you want to replace the previous version, be sure to select the “Overwrite existing project” radio button in the “Import method” section of the dialog box. If you are overwriting an existing version, you will be prompted to confirm that the previous version is to be replaced. At this prompt, you will need to click OK to continue.
When you clicked the button, the event handler defined on line 26 was executed, calling the button_clickHandler()
method. This method defines two integer variables (numTwo
and numFour
) and passes them to a function that adds the integers together and then displays the results in a label. The ActionScript syntax, event handlers, and datatyping variables will all be covered in detail in the next few chapters.
Flash Builder may move your break point to line 26. Flash Builder will always look for the next executable line of code. In this case, that is line 26 where the click occurs.
When the application runs in Debug view, and a user clicks the button, the application will stop executing at the line with the breakpoint. You will be able to debug from that point in the application. You can set breakpoints at any line of executable code in an application, such as an event handler in MXML, or a line of ActionScript in the Script block.
As you learned earlier in this chapter, Eclipse (and therefore Flash Builder) uses perspectives to group together sets of views. By default, the Debug perspective adds four views above the code. To the left is the Debug view, which shows where the application encountered the breakpoint. This view also has buttons to continue running the application, to stop debugging, and to step into the code, step over a line in the code, or return to the place that called the current function.
To the right of the Debug perspective are three tabbed views. The Variables view shows the current state of the variables, the Breakpoints view shows all the breakpoints, and the Expressions view shows any watch expressions you have added. You will explore these views and buttons in the next few steps.
button_clickHandler()
method.
The Debug view is showing you that you’re looking at the button_clickHandler()
method. The Variables view will still show this event, as it did initially, but three new items are visible there as well, representing the three variables defined locally to the function. Since you have not yet executed the line of code that instantiates and sets the values of those variables, they currently have a value of undefined
.
numTwo
and assigns it a value of 2
.
Now that the numTwo
variable has a value, you can see the value in the Variables view.
numTwo
, and change it from 2
to 3.
The Variables view lets you change the values of variables and see what effect the change has on the application. Changing this value won’t change the underlying code that set the value, but it will let you see what happens if the value is different.
This time, the label reads “3 + 4 = 7”, as we changed the value of the numTwo
variable from 2
to 3
.
You now have breakpoints set at lines 14 and 24.
Deselecting the check box leaves the breakpoint in place but instructs Flash Builder to ignore it for now. You’ll notice that the icon on that line of the code has changed from a blue circle to a white circle. If you want to completely remove a breakpoint, you can either double-click its line number again, or right-click the breakpoint in the Breakpoints view and choose Remove.
Notice that this time, the execution stops at the breakpoint on line 14, and that the numTwo
and numFour
variables are already populated.
addInts()
function.
Notice that the Debug view shows a click on the button called the button_clickHandler()
, which in turn has now called addInts()
. Also notice that the Variables view is showing another set of variables instead of numTwo
and numFour
, which were variables local to the button_clickHandler()
method. It is now showing value1
and value2
, the arguments to the method.
As it did the previous times you used Step Over, the debugger executes the next line, this time populating the sumInts
variable with the value 6
.
Notice that control returns to the button_clickHandler()
method, and that the sumInts
variable is now properly populated with the value 6
, as it was computed in the addInts()
method.
Congratulations! You know how to use the debugger. This will be extremely useful as you work through the exercises in this book and as you develop real-world Flex applications.
There’s one more interesting feature available with breakpoints in Flash Builder: conditional breakpoints. You can enable conditional breakpoints by right-clicking a breakpoint (either next to the line numbers, or in the Breakpoints view), and choosing Breakpoint Properties. From the Breakpoint Properties view, you can enable or disable breakpoints. You can also set conditions. For example, you can set a breakpoint to fire only if a variable has a certain value, or when a potential breakpoint is encountered a certain number of times. While this feature may not be terribly useful as you first start your explorations in Flex, you’ll find it invaluable as you build more complex applications.
Teaching object-oriented programming is not the focus of this book, but to be an effective Flex developer you must have at least a basic understanding of object-oriented terminology and concepts. For instance, the tags you’ve seen—such as <s:Application>
, <s:Label>
, and <s:Text>
—actually refer to classes. The Adobe Flex 4.5 MXML and ActionScript Language Reference (sometimes referred to as ASDoc) is the document that lists these classes, their properties, their methods, and much more.
As you go forward though the rest of the book, you’ll need certain files, such as graphics, to complete the rest of the application. In the same way you imported a project from an FXP file to learn about debugging, you’ll also import an FXP file that will be the basis for the application you work on throughout this book.
When you import a project into Flash Builder, the IDE makes a determination if you already have a project with the same unique identifier (UUID). If you do, it will allow you to overwrite the existing project with the newly imported one. If not, and you already have a project of the same name as the one you are importing, it will ask you to rename the newly imported project. To avoid any confusion, you’re going to completely delete the project you had created previously in this lesson, and then import a nearly identical project, which includes some graphics that will be used throughout the rest of the book.
The project and related files will be removed from the file system.
You are now ready to continue through the rest of the book. If you care to verify that the project imported properly, look in the Project Explorer and confirm that there is now an assets directory in your project.
In this lesson, you have:
• Created a project to organize your application files (pages 18–24)
• Toured the pieces of the Flash Builder workbench (views, editors, and perspectives) used to create application files (pages 24–28)
• Run and modified application files while using code hinting and local history to produce the code for those files (pages 28–33)
• Learned about debugging an application with the Flash Builder debugger (pages 34–41)