Exploring Flash Catalyst and Flash Builder workflows

As a professional interaction design tool, the addition of Adobe Flash Catalyst to the world of rich Internet application (RIA) development provides designers and developers with an opportunity to collaborate on the production of highly expressive web and desktop applications based upon the Flex framework.

With the introduction of any new tool, there are questions as to who should use it, to what extent will it impact your existing workflow and how can you adapt design and development processes to embrace the opportunities that it provides.

In this article, I'll explore a number of workflows for using Flash Catalyst and Adobe Flash Builder 4 as part of the rich Internet application production process. More specifically, I'll discuss the following workflows:

• Interactive content (no dynamic data)
• RIA, linear design and development
• RIA, iterative development (single project/small team)
• RIA, prototype-lead development
• RIA, iterative development (multi-project/large team)

Any one of these might suit your requirements exactly, but more likely, you'll want to combine, adapt, and customize the workflow depending upon the size of your team, the existing skills within the team and the scope of the project that you're undertaking.

Requirements

To make the most of this article, you may want to download the following software:

Flash Builder 4 beta

• Download
• Learn more

Flash Catalyst beta

• Download

Prerequisite knowledge:

A working knowledge of both Flash Catalyst and Flash Builder 4

 

Understanding typical roles

Before looking at specific workflows, it is important to have context as to the roles identified as being involved in the production of a rich Internet application.

Across a range of projects, the extent to which each of these roles is required will vary, but generally speaking you'll need to create design artwork, consider the layout of the application screens, plan for navigation, movement, and interaction within the application and finally create something that can be deployed to the end user. These are the core roles that I'll discuss when considering workflows in this article.

Of course, there are other roles that you may or may not require depending upon the complexity and scope of your project, including system architecture definition, development of services, or supporting server-side infrastructure, quality assurance, security and project management. I consider these roles to be beyond the scope of this article, since my goal is to focus specifically on the use of Flash Catalyst and Flash Builder for client-side RIA development.

Figure 1. The roles identified on a typical RIA production team

Note that I'm talking about roles here rather than people or job titles. Depending upon the size and complexity of the project, and the skills of those involved in its production, it could be that one person undertakes all of these roles and does everything him- or herself. Likewise, there could be a large team with each of these roles broken down into specific sub-areas that are assigned to individuals.

 

Workflow 1: Interactive content (no dynamic data)

The term rich Internet application encompasses a variety of different use cases, at the more simplistic level, from a development perspective, is the type of application that Flash Catalyst can help produce without the need for coding in either MXML or ActionScript.

Through the use of components, states, the timeline, interactions, and action sequences it is completely possible to create a rich Internet application that can be deployed as a SWF (the Flash Player file format) and viewed using a browser with Flash Player 10 installed.

Note: To learn how to get started with Flash Catalyst you should review the following resources:

• Create your first application with Flash Catalyst
• Start designing in Flash Catalyst

In this workflow you would start by creating the artwork for your application using Adobe Illustrator CS4 or Adobe Photoshop CS4, import that artwork into Flash Catalyst, convert graphics into components, add states to the application, use the timeline to animate transitions between states, and add interactions to allow the user to navigate through your application (and optionally link to external sites/assets).

Figure 2. The interactive content workflow

The major limitation to be aware of with this approach is that it is not possible to incorporate dynamic data into your application. You can create data-aware controls and use the design-time data panel to add data to your application, but this data cannot change when the application is run by the end user. For that, you'll need to consider the other workflows in this article.

To export your Flash Catalyst project so that it can be deployed to Flash Player, go to File > Publish to SWF in the main application menu.

 

Workflow 2: Linear design and development

Flash Catalyst has its limitations as a standalone RIA production tool, and quite rightly so—it is an interaction design tool, not a development environment. To build an application that extends the functionality provided by Flash Catalyst, in which you need to undertake code editing or add new MXML documents or ActionScript classes, you'll need to use Flash Builder.

Flash Builder is a professional integrated development environment (IDE) and provides features that are aimed at those developing rich Internet applications using ActionScript and optionally, the Flex framework.

Further to the limitation noted in workflow 1, a concrete example where you'll need to use Flash Builder during the production process, is when your application needs to retrieve data at runtime from a web server, web service, or third-party API (application programmer interface).

Using the same approach as for workflow 1, you create your artwork in a Creative Suite tool, import it into Flash Catalyst, use the features in Flash Catalyst to add states, animation, and interactivity, and then save your project as an FXP file. To do this, go to File > Save As in the Flash Catalyst main application menu.

Figure 3. The workflow for creating an RIA using a linear design and development approach

You can now provide the FXP file to the person who will be responsible for implementing the additional functionality in the application; this could be yourself (if you are building the entire application) or a developer on the production team.

Within Flash Builder, go to File > Import Flex Project (FXP) from the main application menu, select the FXP file and Flash Builder will create a new project and import the code that Flash Catalyst generated during the interaction design phase of the project (see Figure 4).

Figure 4. The Import Flex Project dialog box in Flash Builder

Within the imported project you will see the Main.mxml document (see Figure 5). This is the main application file, which defines the layout for each of the states, any transitions between those states and any interactions that you defined at the application level. This file does not contain the definition for any components that you defined within Flash Catalyst; these can all be found in the components package.

Figure 5. A project in Flash Builder that has been imported from Flash Catalyst

Note: For information on component skins in Flex 4 see Ryan Frishberg's article Introduction to skinning in Flex 4 beta.

As the person responsible for customizing or extending the application, you can now use the code and design views in Flash Builder or make use of the Data/Services panel to define calls to remote operations that will fetch data at runtime.

Note: For more information, refer to my tutorial on the design and development of a data-centric application using Flash Catalyst, Flash Builder, and ColdFusion can be found here.

The limitation to be aware of with this linear design and development approach is that it does not consider the scenario whereby you need to make changes to the visual design of the application or its components following the export from Flash Catalyst and import into Flash Builder.

It is not possible to re-open a Flex project in Flash Catalyst once you've imported it into Flash Builder. (The product teams will investigate this option for a future release, but it will not be available in the first release of Flash Catalyst.) To overcome this limitation, consider the other workflows in this article, in particular workflow 3, which extends the approach used here to support iterative development.

 

Workflow 3: Iterative development (single project/small team)

If you anticipate the need to make changes to the artwork used in the component skins, or elsewhere in the application user interface, then you'll want to familiarize yourself with this workflow.

Building on workflow 2, after you've imported the FXP into Flash Builder and undertaken custom development work, changes to the visual design now need to be incorporated into the application.

These design changes should be completed in Flash Catalyst by opening up the original FXP file (that is, as saved from Flash Catalyst previously and used with the import into Flash Builder), making the necessary changes and then saving out a new FXP file. It is recommended that you use File > Save As to create a new version of the FXP file, rather than overwrite the previous version.

Figure 6. Iterative development, suitable for a single project and/or a small production team

In Flash Builder you can then import the updated FXP file, using the same File > Import Flex Project (FXP) option as before; this time, however, Flash Builder will offer you the choice of creating a new copy of the project or overwriting the existing project – you should select "Import new copy of project".

Figure 7. Select the Import new copy of project method to incorporate design changes.

A new Flex project will be created in Flash Builder that contains the main application file and all component skins used in the project, regardless of whether they have changed or not since the original project import. Integrating changes that have been made in Flash Catalyst is a manual process that you must undertake in Flash Builder; there is, however, a tool that you can use to help with this task.

Right-click on the newly imported Flex project and select Compare With > [Name of original project] from the context menu. Flash Builder will compare all the files contained within both projects and provide a list of files in which there are differences (see Figure 8).

Figure 8. Comparing two projects within Flash Builder to find the differences

Since you should not need to make significant changes to the component skins yourself (any business logic added to the project should be in the main MXML document, new MXML documents or new ActionScript classes), changes highlighted in the component skins will likely be those made in Flash Catalyst.

The compare tool provides a visual preview of the differences between the original and new file so that you can determine whether a change should be incorporated into the project – use the toolbar to step through the changes and to copy changed code from the left to right window, or from right to left as appropriate.

For an alternative approach to iterative development, for use on more complex projects or where you have a larger production team see workflow #5.

 

Workflow 4: Prototype-lead development

Not every project will start with client-approved or final design artwork that you can import into Flash Catalyst.

In this scenario, an alternative approach is to use the wireframe components in Flash Catalyst to create the scaffold of the application—that is a version of the application that contains placeholder components, with states and interactions defined, such that it represents the basic interaction model of the application, but without the visual design applied (see Figure 9).

Figure 9. The Wireframe Components panel in Flash Catalyst

With this approach, the scaffold project can be opened in Flash Builder and application development work can continue whilst waiting for the design artwork to be completed and approved.

Figure 10. Using a wireframe-based project to expedite development whilst design work continues

To create the component skins for the wireframe components used in the project you can select each component in turn in Flash Catalyst and either "Edit in place", using the Flash Catalyst drawing tools and properties panel to customize the design, or choose "Edit in Illustrator CS4" to launch and edit the artwork in Illustrator.

When design changes are complete, save an updated version of the FXP file and use the approach described in workflow 3 to merge the changes to the component skins into your existing project. Alternatively, you could use the more advanced iterative development workflow described in the next section in conjunction with the wireframe components.

 

Workflow 5: Iterative development (multi-project/large team)

The iterative development approach described in workflow 3 relied upon a manual process of merging in changes after comparing two different versions of the FXP file. In this workflow, you make use of an alternative file type supported by Flash Catalyst, an FXPL or Flash Catalyst Library Package.

An FXPL contains only the component skins, item renderers, custom components and supporting assets that you have defined in your project and not the main application MXML document. This makes the Flash Catalyst Library Package ideal for sharing a set of re-useable component designs across multiple Flash Catalyst projects and makes it possible to deliver updated sets of component skins in a single package for use in Flash Builder.

Figure 11. Iterative development using Flash Catalyst Library Package (FXPL) files

This workflow relies upon your main application document and all other supporting MXML documents and ActionScript classes being defined in a separate Flex project. You may choose to create this project using the prototype workflow described earlier, or you could develop the application from scratch using Flash Builder.

When you import a Flash Catalyst Library Package (FXPL) into Flash Builder using the File > Import Flex Project (FXP) option, a Flex Library project is created. This type of project contains code that has been designed for use with one or more Flex applications, defined in separate projects.

To associate this Flex Library project with your application right-click on the project containing your application code, and select Properties and then Flex Build Path > Library Path, click Add Project, and then select the Library project from the list displayed (see Figure 12). You should see the Library project appear in the list of build path libraries. When you compile the application the relevant code from the Library project will be included automatically in your compiled SWF.

Note: For more information on Flex Library projects see the Flash Builder documentation.

Figure 12. The Flex Build Path settings for a project, showing the use of a Library project

The components package containing all the component skins, as created by Flash Catalyst, is now available for use within your Flex application and you can associate skins with appropriate components using the skinClass attribute on the component tag or in a CSS document, for example:

<s:Button id="myButton" skinClass="components.myButtonSkin" />

As and when additional component skins become available or existing skins are updated you can import a new FXPL, replace the existing Flex Library project, and the new component skins will be available within your Flex application. For this approach to work, avoid making changes to the files within the components package in Flash Builder.

One area that is outside the scope of this article, but which will be important when using this workflow, is the use of custom/generic components created in Flash Catalyst within a Flex project. You might like to consider converting Flash Catalyst generated components into a skins and using them with ActionScript based components that extend from the SkinnableComponent class, so as to clearly separate component design and business logic. It is left as an exercise for the reader to investigate this option further until publication of a future article covering this topic in depth within the Flex Developer Center.

Other workflows

Whilst not an official list of recommended workflows, the approaches described in this article are all supported within the current versions of the Flash Catalyst and Flash Builder.

There are a number of third-party tools and alternative workflows that you might like to consider as you work with Flash Catalyst and Flash Builder; these can often improve productivity further for advanced developers. Note, however, that some of these tools may use unsupported or non-recommended approaches that may not work with future versions of Flash Catalyst and Flash Builder.

 

Where to go from here

To discuss Flash Catalyst and contribute further hints and tips visit the Adobe Forums for Flash Catalyst. To learn to use Flash Catalyst, check out the resources and tutorials on Adobe Labs.