FlashBuilder and PureMVC Part I
This is the first in a series of posts on using PureMVC with FlashBuilder. I’m getting back into PureMVC for some client work, so I thought it might be useful to discuss PureMVC in terms of migrating to FlashBuilder and mixing Spark/Halo components instead of yet another how-to-use-PureMVC tutorial.
Instead of starting from scratch, I decided to perform a ‘FlashBuilder makeover’ of an existing tutorial. Ahmed Nuaman has a very solid tutorial at this site. The explanation of PureMVC is very thorough. The application loads and displays a small set of images from Flickr. In order to keep the scope reasonable for a tutorial, the application only displays a subset of the images in a non-scrolling container.
For purposes of the current series, Ahmed’s tutorial was redone in FlashBuilder using a small number of Flex components. To illustrate some migration issues, a mix of Spark and Halo components are used. Each part of the tutorial discusses how the code is constructed and how it differs from the original tutorial. I’ll provide a .zip of each file at the end of the tutorial with the exception of the data.xml file as that requires your own Flicker API key as discussed in the original tutorial.
I will point out here that this is not a PureMVC tutorial in the sense that I won’t be explaining PureMVC concepts from scratch. That’s why I started with an existing tutorial in which those concepts are well covered. I’ll be discussing how to use PureMVC in a FlashBuilder environment.
With that in mind, let’s start with setup. The original tutorial created an Actionscript project. Mine is a Flex project linking against the PureMVC .swc. The following diagram illustrates the project folders.
There is nothing special in setting up a project with this directory structure, although I do tend to always use model, view, and controller folders in a PureMVC project. For a larger project, I would probably also add value-object folders and separate mediator folders for the views. If there are a lot of commands and MacroCommands, those might also be further separated into specific folders.
When I present examples such as Degrafa capability, there is a limited amount of layout and a lot of logic. It’s often easier for both to be present in the same file for people to deconstruct. For actual client projects, I prefer to separate layout and logic as much as possible. For this reason, I tend to use a code-behind pattern for Flex apps. I also use a custom preloader since designers always like to customize that part of an application
Custom preloaders have not changed in Flex 4 (I’m still going to call it that whether Adobe likes it or not) and were discussed in this post. This is the first major change from the original tutorial, which used PureMVC to monitor application loading. That tutorial also used the stage as the core viewComponent. For this tutorial, a Spark component will serve as the core viewComponent.
The layout of the Flex application in this tutorial is shown below (PureMVC1.mxml).
<?xml version=”1.0″ encoding=”utf-8″?>
xmlns:mx=”library://ns.adobe.com/flex/mx” minWidth=”700″ minHeight=”500″
@namespace s “library://ns.adobe.com/flex/spark”;
@namespace mx “library://ns.adobe.com/flex/mx”;
@namespace views “view.*”;
src: url(“/Library/Fonts/Arial Bold.ttf”);
<comp:PureMVCLayout id=”App” />
Not much to it
The custom preloader does it’s job, then the rest is left up to the PureMVC application itself which is implemented in components.PureMVCLayout.mxml . I like to have application styling up-front and in one centralized location. That makes it easy to locate and change. In tomorrow’s installment, we will discuss the styling and PureMVC layout in more detail.