First, let us look at the catalyst workflow that’s been all the rage in the demos online that introduce catalyst (like this one).  Refer to the diagram below.

Pros:

• Super simple

Cons:

• Limited to one designer and one developer
• Limited to a single catalyst project
• Developer can’t start until designer is finished
• Once the designer has handed off the file, they can’t make edits.

If your software development process can handle those cons, this “super simple” option will rock for you.  But for anything beyond the most trivial of projects, those restrictions will be a deal breaker.  I consider this workflow similar to editing Actionscript in keyframes on the timeline in Flash.  It works, it’s simple, sometimes it might be the right way of doing things, but most of the time it’s like shooting yourself in the foot.

Something that hasn’t been as widely discussed, but that is still part of the official offering from Adobe goes something like this diagram:

In this scenario, the developer creates a plain old Flash Builder project.  While he’s doing that, the designer creates a .FXPL file.  The developer takes that .FXPL and imports it as a Flex Library project, which he then references from his main project.  (Just import the .fxpl like a .fxp, the correct type of project is auto-created) Later, the designer can make changes in Catalyst.  Then the designer exports a new .FXPL file and the developer can re-import it (re-import steps below).

Optionally, the developer can move the classes into a package structure inside Flash Builder.  If there will be more than a single .fxpl imported, this is required since there will be name conflicts.  Currently, the refactor in Flash Builder doesn’t work 100% for this as the skin references aren’t updated, hopefully that’s just a beta-bug and will be fixed.

This is a huge improvement over the previous workflow and will probably work out great for most people.

Pros:

• Developer and Designer time can overlap
• You can have multiple designers and developers (by repeating that middle bit in the diagram
• Can use a package structure
• An “official” Adobe method

Cons:

• Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project.
• Every time a new .FXPL comes out, the developer must (I bet some of this could be automated!):
  1. Delete the current Flex Library project
  2. Import the new .FXPL
  3. Modify the main project to reference this newly imported project
  4. Move the classes in the Flex Library project into a new package structure
  5. Rebuild the swc
  6. Rebuild the app
• Does not retain the Main class from catalyst, so all work must be done in sub-components

That’s doing a lot better in the scalability department.  It’s doing a bit worse in the complexity department.

What if we could automate some of the process of turning a .FXPL into a .swc?  Or even better, what if we could turn a .FXP into a .swc?  Then we’d have something that looks very similar to the previous workflow, but with one important difference:

Pros:

• Developer and Designer time can overlap
• You can have multiple designers and developers
• The script automatically converts the Main catalyst component from an Application object to a Group object so you can use it in your project.  (Coming Soon!  The next version of my script will)
• Automatically uses a package structure

Cons:

• Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project. (But he only ever sees a swc now, so no worries)
• Every time a new .FXP comes out, the developer must somehow get the new .swc (more on this below)
• Requires a script to run (requiring whatever environment that script was written in)

That may seem like a fairly minor difference, but imagine how much better it scales.

Instead of a single developer and a single designer, picture a whole team of them.  If every developer needs to go modify their workspace every time any designer makes a new .FXPL, they’ll end up spending too much of their time just managing their build environment.  The more people you add, the worse it gets.

If that script can be run through a command line script, it can be automated.

Most teams that consisting of more than a couple people use a version control system.  That system can be used to distribute .swcs that are generated from the catalyst projects.  Many version control systems have hooks integrated into them so they run a script whenever a certain file or directory is modified.  If yours doesn’t have than a simple scheduled job could do it.  This can simplify the process even further to:

1. Designer checks .FXP into version control
2. Script runs, automatically generating the .swc
3. Developers sync up, getting the new .swc

That means, once it’s set up there is no additional work that needs to be done.  The designer works in his tool.  The developer works in his.  Assets are magically propogated.

If you don’t use a version control system, scheduled jobs and a shared network folder could do the same thing.

This solves the scalability problem.

All that is good-and-well, but that script to generate the .swcs must be awfully hard to do, right? Wrong. It was easy. It’s done. Go give it a try.

Blog post describing the script.
Download: fxp2swc.rb

Any windows based Ruby developers want to take a crack at updating the script to work correctly on windows?

1. Let me select a package that components get created in.
2. Export a swc with everything in it so we don’t have to go through most of this.

Last night I wrote a ruby script capable of doing exactly those two things.  I call it fxp2swc.rb.

Using the script is simple.  First open it up and set the two variables at the top.

The flex_dir just tells the script where your Flex SDK is. The default_package tells it what package you want your catalyst based components made in.

After you edit that, put the script in the same directory as your .fxp files. Run the script and you should see output like this:

$ ./fxp2swc.rb
=== FCTest.fxp
 Extracting to FCTest.fxp.tmp
 Creating directory FCTest.fxp.tmp/src/com
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment/catalyst
 Creating directory FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying Main.mxml
 Copying FCTest.fxp.tmp/src/components/Background.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/CustomComponent1.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/LoginButton.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/LoginForm.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Copying FCTest.fxp.tmp/src/components/TextInput1.mxml -> FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest
 Removing old source locations
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/Background.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/CustomComponent1.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/LoginButton.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/LoginForm.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/Main.mxml
 Fixing package names in FCTest.fxp.tmp/src/com/roguedevelopment/catalyst/FCTest/TextInput1.mxml
 Creating swcconfig.xml
 Invoking compc -load-config+=swcconfig.xml
Loading configuration file /Applications/Adobe Flash Builder Beta/sdks/4.0.0/frameworks/flex-config.xml
Loading configuration file /Users/mhughes/Dropbox/fxg2swc/swcconfig.xml
/Users/mhughes/Dropbox/fxp2swc/FCTest.swc (1463574 bytes)
Deleting temp dir
Done!

You now have a one .swc for every .fxp file! As easy as that!

Take the swc, and plop it into the “libs” folder of you Flash Builder project, and you can start using the components from it. They’ll be in a package that starts with your default_package variable and ends with the name of the .fxp you compiled. So for my example FCTest.fxp, the package is: com.roguedevelopment.catalyst.FCTest

Here’s a quick example of what it looks like to use one of those components:

You can still use the composition or inheritance methods of using those components that I blogged about the other day. Here’s an example showing that with view-source enabled.

I’m on OSX using Ruby v1.8.6 with this script. Your mileage may vary on other platforms. Two things that will likely need to change for Windows users:

• The compc call should use compc.exe
• It uses the unzip command line utility, not sure if that’s a standard tool on Windows

I’ve been playing around with the Flash Catalyst and Builder betas today and one thing that scares me a little is the built-in designer/developer workflow that’s implied.  From what I can gather, a designer uses a design tool, imports that into Catalyst, and then hands of a .FXP file that a developer then imports into Builder to work on.  Then the developer jumps into the files generated by Catalyst, and modifies them.

For smallish projects, that’s a slam-dunk.  If you don’t work on large projects, stop reading here and just stick with that.

But there’s a number of reasons I really don’t like this intended workflow for larger projects.

First, it’s not scaleable.  One catalyst file -> one Flash Builder project.  It’s awefully hard for a team of 5 designers to work on a single catalyst file.

It implies some exclusivity.  If the designer hands off the .FXP file, they really shouldn’t continue working on it because the developer will start modifying it.  It’s kind of like having a Word document that you pass back and forth between the designer and the developer.  If they both want to work on it at the same exact time, you’ll get race conditions.

Second, I don’t trust anybody to get a perfect Generated Code <-> User Edited Code tool to work perfectly all the time.  If Catalyst generates some code, I edit that, and then we bring it back into Catalyst, I just know that will break at some point.  (Sorry Adobe guys, I know you’ll do a rocking job with it, and I know it will almost always work, but it’s just too hard a problem)

So here’s a solution I’ve been playing with:

Step 1: Create your design comp

Here’s a Photoshop file I created with a pretty simple login form.  Make sure to name your layers so they’re easy to find later.

Step 2: Import it into Flash Catalyst just like you’re supposed to.  Edit it to your heart’s content.

There’s a bunch of tutorials out there (great one from Lee Brimlow here) that show how to actually use Catalyst.  But one difference from all those tutorials.  We won’t be using the Main root level item.  So don’t go crazy adding states to your base stage.  But DO go crazy creating sub-components and adding states and behaviors to those.

Here’s a screenshot of my Catalyst project.  This is showing off a LoginForm component that I created.  Notice it has a few states with transitions set up between those states.

Step 3: Save it as a .FXP

File->Save from Flash Catalyst.

For my example, I used FCTest.fxp as the name.

Step 4: Create an empty Flash Builder project (not importing anything here)

Just create a plain old Flash Builder project with a Flex based application in it.  (Make sure you’re using a Flex 4 SDK!)

Step 5: Take your .FXP from above, and unzip it somewhere

Here’s the sneaky part.  That .fxp file is really just a zip file that contains a Flash Builder project.  You can unzip it with any standard zip tool.  In OSX I just open a terminal and did a:

unzip FCTest.fxp

It creates a directory structure that looks something like this:

Notice the two folders with arrows pointing to them, they’re important in the next step.

Step 6: Take the components and assets folders from that unzipping and put them in a brand new folder.

We can take those two folders and use them in our Flash Builder project to get access to all of our custom components that we made in Flash Catalyst.  I’m planning ahead a little bit so I created a “CatalystAssets” folder, and a “FCTest.fxp” folder inside that, and placed them there.  This will allow me to have assets from many different catalyst files in the future someday.

Step 7: Link to that folder from your Flash Builder project

Flash Builder can link to source directories outside of the project.  To do that go to Project->Properties->Flex Build Path.  Click the “Add Folder…” button and add the FCTest.fxp folder (the folder we created, not the file Catalyst made).

In Flash Builder’s Package Explorer you’ll see something like this after you do that:

The developer should NEVER EDIT anything in the FCTest folder.  Consider that all auto-generated stuff that will wipe out anything you do in there.

The developer can and should work in the normal Flash Builder src folder, likely importing classes and assets from the FCTest folder and using them.

Step 8: Use the Flash Catalyst based assets!

For simple components that you don’t need to add any functionality to, you can just use them in your MXML.  For example, I created a component called Background in my Catalyst file.  To use it in the Flex application you just do something like this:

Notice the components namespace with the Background component name.

Adding non-interactive components isn’t all that interesting.  So what happens if you want to add functionality to components created in catalyst?  There’s two options here, either use the assets from the .FXP through composition or inheritance.  Here are two examples that show how to do them both:

Extending a Catalyst component through inheritance:

Or, if you want to use composition instead of inheritance you could do something like this:

Now that you have your components with some added functionality, you can use them in your main application like you would any other Flex based component. You can see a working demo, with view-source enabled here:

http://rogue-development.com/uploads/catalystWorkflow/FCTest.html

As you can tell, that seems like a LOT of extra work. But here’s the payoff:

1. The designer is free to continue working in Flash Catalyst while the developer works in Flash builder.  Whenever he has changes, he just hands off a brand new .FXP, and the developer repeats steps 5 and 6 to replace some files and then refreshes the Flash Builder workspace.
2. You can create multiple folders inside that “CatalystAssets” folder, and then use assets from multiple FlashCatalyst projects in a single Flash Builder project.
3. You can add those Flash Catalyst assets to version control and easily distribute them to multiple developers. (Not to mention track changes!)

I did up a quick shell-script to unzip the .fxp file, make some directories, and copy the files to the appropriate place.  I can run this whenever the designer gives me a new .fxp. I think with a little work we could create a Eclipse “Builder” (that’s unrelated to the product name “Flash Builder”) that would completely automate this entire process.

Some things I wish Flash Catalyst did:

1. Let me select a package that components get created in. (maybe there’s a way to do that?)
2. Make it easier to intelligently name the classes and property names that get generated
3. Export a swc with everything in it so we don’t have to go through most of this.

Well anyways, I give Catalyst 2 thumbs up and even if we have to go through this process for a sane workflow it will save huge amounts of time in our shop.

P.S. I’m no Catalyst expert so maybe there IS a better workflow that I just haven’t seen yet.

• You no longer have to re-parent your components.
• What and where handles appear is now completely configurable
• ObjectHandles modifies your data object instead of moving a component around (there’s 3 example visual components / data models in the source)
• Optionally, object handles won’t swallow all of your mouse events.
• Will now work with non-flex components (still requires Flex SDK to compile, I have to look into that)
• Rotation support is completely smooth
• Configurable constraints/rules system
• Smaller, cleaner code base!

Scroll down for demo.

Click to see the early proof of concept of it working within Mocassin.

ObjectHandles is a library to easily add graphical move/resize user gestures to a Flex based application.

[kml_flashembed fversion="8.0.0" movie="/uploads/ohv2/ObjectHandles2Example.swf" targetclass="flashmovie" publishmethod="static" width="700" height="700" fvars="undefined"]

[/kml_flashembed]

Let’s look at a very simplified example that illustrates the general idea (actual mocasin implementation varies quite a bit from this).  Imagine this code…

We have some kind of model object, let’s call it the PizzaModel.

That model has a property, that itself is some kind of complex object.  Lets call that property sauce, and the type will be called PizzaSauce

Now, we have some kind of view object.  Let’s call it the PizzaView.

A normal way to implement something like this would be to have the pizza view listen to events on both the pizza object and it’s sauce object. Or it could manually set up some change-watchers that watched the hierarchy to the required properties.

That’s all fine and dandy until we get to more complex object hierarchies. What if we had an arraycollection of toppings and we needed to know when individual properties of those toppings changed? Now, we’d have to listen to yet another type of event.

And what happens of those toppings themselves had lists of ingredients we wanted to listen to, suddenly the event chain is getting pretty gnarly to manage.

If we had some kind of magical bubbling model event, we’d only have to listen at a single location, as shown above. Especially if there was an expressive way of identifying what changed.

How might something like this be implemented?

Mocassin does it by having a meta-data model that wraps the actual data model and provides this extra functionality.

Another way would be to force the data model objects to all extend from a common superclass (I believe earlier versions of Moccasin did just that)

Someday, I’d like to explore either creating a general purpose framework for this or extracting it from Moccasin. I’m blogging about it hoping someone might do it before I get a chance

A little digging, and I figured out why.

If you have a component inside a flex container like a Canvas.  And the container is resized and all of a sudden it requires a scrollbar to fit everything you will get an extra ADDED_TO_STAGE event.  Internally the container removes the component, creates a content pane to scroll around, and moves all of it’s children from the base container object onto this content pane.  That removal/addition causes the ADDED_TO_STAGE events to fire and caused my bug.

We’re working on an educational application made up of a series of lessons.  The general flow of our app is:

1. Start Up
2. Login
3. Request what the next lesson is from the server.
4. Do the lesson
5. Send results
6. Goto #3

To do #3 we have a service object that knows how to make that request to the server and handle the response.

But…

We don’t want to have to deal with having a server running all of the time during development of the client.  So we created a brand new class that implements the same interface as that service.  However, instead of asking the server what the next lesson should be, it displays a UI that lets the developer/qa person select a lesson.  With IoC we simply changed the configuration that instantiated that object to use this new class and bamn, it works throughout the application.

Now, I’m working on a demo of the software for management.  We want it to go through a predefined, fixed, list of lessons for the demo.  I created a new service object that maintains a list of lessons to go through sequentially, updated the config, and bamn… our demo is ready.

So now, the exact same application code can be run three different ways depending on what configuration we give it.

Now, it’s certainly easy to do a similar thing using other non-IoC approaches.  Maybe you’d need a recompile for those (but is that all that bad?).  The benefit with IoC is that it tends to make developing like this automatic.  It pushes developers to code to interfaces and create modules that can be easily replaced with others.  It’s a developer “state of mind” benefit.

In case you’re curious, we use Parsley as our IoC container.

If you’re not familiar with how OpenID works, here’s a quick summary.

1. User goes to an application (Usually a web-app)
2. User types in their OpenID URL to that app
3. They get forwarded to their OpenID page where they can either grant or deny access.
4. That page then forwards them back to the original web app with an authentication token set.

Obviously, it’s kind of hard to redirect back to a desktop application.  I was thinking up some wacky work-a-rounds for this but then it hit me.

In the AIR app I can just use the HTML component and point it towards the login form of the web services.  The user can then log in using either username/password or OpenID just like they do on the website.  Now, here’s the cool part…  The AIR HTML component shares a network stack with the AIR/Flex NetConnection object.  That means any session/cookies/whatever opened in the HTML component carry through to the remoting calls I want to make from Actionscript. So I can authenticate using a web form, but then consume BlazeDS/LiveCycleDS/AMFPHP/Red5 services using AMF over Netconnection.

I did up a quick proof of concept and it works on both Windows and OSX.  I was able to successfully call a remoting service that requires an authenticated session.  So this was actually a much easier problem to figure out than I had feared.

Now, I’ll just need to make the web page that loads after a successful login somehow indicate to the AIR app that the user is successfully logged in.  I’ll probably either use a tiny Flash component that signals over LocalConnection, or I’ll just make the AIR app watch for when the HTML component gets to a specific URL. I’m pretty sure I can get this to be a completely seamless experience for the user.

Oh, and as a bonus… the user can sign up for a new account instead of log into an existing one from "within the app" instead of going to an external website to do that.

If it is ObjectHandles, this would be the second time I just ran into a use of them, that’s pretty cool. Unfortunately, I couldn’t find an email address on that site.

But that aside, the site is neat.  It lets you create some pretty "web 2.0" style buttons with stripes, highlights, etc.

I spent some time on the library yesterday.  I was tyring to get the rotation+resizing thing working better since it’s been somewhat broken for a while.  I’ve never needed that feature so it’s been neglected.  Unfortunately, I’m running into a bit of a brick wall.  I’m still trying to figure out exactly what it should do, nevermind how.  Luckily, most of my Trigonometry from High School is coming back to me since it’s heavy in that department.

The basic idea is you shouldn’t have to modify your data model to use it in a specific view. If you need to filter, sort, or summarize the data for a view you can do that through an Adapter so your model doesn’t need to understand that logic and you’re view isn’t reliant on a specific implementation of your model.

Example: If you had a list of books in an array, and you want to filter by some property of books (say publisher) you shouldn’t apply the filter directly to the model. Instead, create an adapter that can watch that array, and have that adapter apply the filter (or sort, or whatever).

More Examples: Consider Timeliner XE, a product I’ve been working on at my day-job. The main data model is a list of events. There are several views for that data. We have a text based / grid view, and some graphical views. Here’s a couple screenshots:

Each of those screenshots has 2 views active at a time, the grid, and then a seperate graphical view. That makes 3 views that all want to bind to our data model. But, notice the grid has 5 events in it, while the graphical views only have 3. This is because only 3 of those events are valid to plot (they have a date). It’d be nice if we only had to bind to a list of events that actually has the data we want.

Now take a look at these three screenshots from AgileAgenda, my project scheduling application.

In all of these the data we have is a list of tasks. The first two show one view with two different filters applied to the data. The third shows a large grid with all of our tasks, and a much shorter pulldown that only has the tasks that are also milestones. (A milestone is a specific type of task)

To create an adapter:

• Create a new adapter class
• Create a constructor for that class that takes in the “source” data model, and any options that might be specific to the adapter.
• Add event listeners to the “source” model.
• Write event handlers in the adapter to update the adapter’s internal state when the source changes.
• Write accessors in the adapter, so other components can get data from it.

A simple example…

Click here to run a simple example. View-source is enabled in that. Here’s a screenshot of the example:

When you run the example, it creates a simple data model, populates that data model with 4 sample items, and then creates 4 panels. Each of those panels represents a view. The example also creates 4 different model adapters all from the same data model, but with different options set. Then each panel gets a different adapter.

As you add items to the data model, you can see that the 4 views update depending on whether or not they are filtered and sorted.

Our Data Model:

package
{
    public  DataItemExample
    {
        public var name:String;
        public var amount:Number;
        public var active:Boolean;
    }
}

—-

package
{
    import mx.collections.ArrayCollection;

    public  DataModelExample
    {
        [Bindable] public var myDataItems:ArrayCollection = new ArrayCollection();

    }
}

As you can see, it’s a pretty simple data model. There are items with a name, amount and active properties, and then there is DataModelExample class with an array of those. Notice that no view-specific data is in there.

Now, lets create our adapter and name it “AdapterExample”

First, create a constructor and some variables to hold some information about the adapter. We’ll have 2 options. onlyActiveItems and sorted. For sorted, we’ll also create a Sort object to actually do the sort for us. And we’ll also create an array to hold our filtered/sorted list of items. Note that we add an event listener for the COLLECTION_CHANGE event. This is how we’ll propogate changes from the data model to our adapter. We’ll see the handler for that later.

 public  AdapterExample extends EventDispatcher
    {
        protected var model:DataModelExample;
        protected var filteredDataItems:ArrayCollection = new ArrayCollection();
        protected var _onlyActiveItems:Boolean;
        protected var _sorted:Boolean = false;
        protected var sort:Sort;        

        public function AdapterExample(dataModel:DataModelExample, onlyActiveItems:Boolean, sorted:Boolean)
        {
            _sorted = sorted;
            _onlyActiveItems = onlyActiveItems;

            model = dataModel;
            model.myDataItems.addEventListener(CollectionEvent.COLLECTION_CHANGE, onItemsChanged );    

            if(sorted)
            {
                sort = new Sort();
                sort.fields = [new SortField("name",true)];
            }

            rebuildFilteredArray();
        }

Notice that we called rebuildFilteredArray above. Lets write that next. All this method does is loop through our data model and grab all the items from it (respecting our filtering option) and adds them to our internal array. It also applies the sort if neccessary. At the end we dispatch two events which will be used for binding later.

  protected function rebuildFilteredArray() : void
        {
            var tmp:Array = [];
            for each ( var item:DataItemExample in model.myDataItems )
            {
                if( (! _onlyActiveItems ) || (item.active) )
                {
                    tmp.push(item);
                }
            }                        

            filteredDataItems = new ArrayCollection(tmp);

            if( sort )
            {
                filteredDataItems.sort = sort;
                filteredDataItems.refresh();
            }

            dispatchEvent(new Event("dataItemsUpdated") );
            dispatchEvent(new Event("totalChanged") );
        }

So now if we made an adapter it would start up, read in the source data model, and populate our internal array of items. But it wouldn’t respond to changes in the source data model. So lets create the event handler that we set up in the constructor. We’ll also create a couple helper methods

    protected function onItemsChanged(event:CollectionEvent):void
        {
            switch(event.kind)
            {
                case CollectionEventKind.ADD: addItems(event.items); break;
                case CollectionEventKind.REMOVE: removeItems(event.items); break;

                case CollectionEventKind.MOVE:
                case CollectionEventKind.REFRESH:
                case CollectionEventKind.REPLACE:
                case CollectionEventKind.RESET:    rebuildFilteredArray();
                                                break;

                case CollectionEventKind.UPDATE:  

            }

        }

        protected function addItems(items:Array):void
        {
            for each ( var item:DataItemExample in items )
            {
                if( (! _onlyActiveItems ) || (item.active) )
                {
                    filteredDataItems.addItem(item);
                }
            }
            dispatchEvent(new Event("totalChanged") );
        }

        protected function removeItems(items:Array):void
        {
            for each ( var item:DataItemExample in items )
            {
                var index:int = filteredDataItems.getItemIndex(item);
                if( index != -1 )
                {
                    filteredDataItems.removeItemAt(index);
                }
            }
            dispatchEvent(new Event("totalChanged") );
        }

For adding/removing items we’re going to our internal array and manually adding or removing items from it. We’re making sure to account for filtered items, but the sort object is taking care of the sorting for us.

For the other types of events, we’re kind of cheating. We only really care about adding / removing operations so we’ll just rebuild our entire internal array on other types of events. If your application uses those types of events often, you should implement them in the adapter in a more efficient manner.

Exposing data from the Adapter

We now have the internal state of the adapter updating as the model changes. So the only thing left to do in there is expose some properties so we can get at that info from our view. Let’s write two bindable getters. One of them will summarize the data (get total()) the other will give us our filtered list (get dataItems())

Note that we set the event=”" property in the [Bindable] tags so our views can correctly know when these properties change.

  [Bindable(event="dataItemsUpdated")]
        public function get dataItems() : ArrayCollection
        {
            return filteredDataItems;
        }

        [Bindable(event="totalChanged")]
        public function get total() : Number
        {
            var total:Number = 0;
            for each ( var item:DataItemExample in filteredDataItems )
            {
                total += item.amount;
            }    

            return total;
        }

Using the Adapter

Once you’ve done all of that, you can actually use your adapter. So create your data model, create your adapter, and use it!

 [Bindable] protected var dataModel:DataModelExample = new DataModelExample();
 [Bindable] protected var example1:AdapterExample = new AdapterExample( dataModel, true ,true);

…

    <mx:Panel x="10" y="218" width="250" height="200" layout="absolute" title="Filtered, Sorted">
        <mx:Label x="10" y="132" text="Total:"/>
        <mx:Label x="56" y="132" text="{example1.total}"/>
        <mx:List x="10" y="4" width="210" height="120" dataProvider="{example1.dataItems}" labelField="name"></mx:List>
    </mx:Panel>

If you look at the source of the example, we actually create 4 adapters with varying options.

Beyond this basic example

If you want your adapter to respect changes to individual items, your items should implement the IPropertyChangeNotifier interface. So in our example if we edited an item so it’s active flag changed, the views would not update. To make that work we would implement that IPropertyChangeNotifier interface, and then write some code for the CollectionEventKind.UPDATE event.

Often times only one or two views are visible at a time and it’d be nice if all the views in the background weren’t madly updating themselves every change. To accomplish that I often write an enable() disable() method on the adapter. They usually look something like this:

protected function enable() : void

{

model.myDataItems.addEventListener(CollectionEvent.COLLECTION_CHANGE, onItemsChanged );

rebuildFilteredArray();

}

protected function disable() : void

{

model.myDataItems.removeEventListener(CollectionEvent.COLLECTION_CHANGE, onItemsChanged );

}

So What is it about?

The book does a few things.  First, about a third of the book introduces you to some open source tools for doing flash development.  Things like FlashDevelop, MTASC, SwfMill, ANT, and ASDT.  It’ll show you how to create an AS2 and an AS3 based flash application using completely free and open software.  This goes all the way from installing the tools, creating a sample app, writing up some unit tests for it, and then to publishing it to the web.  Along the way it’ll give you a brief introduction to each tool, explain what it does, and then give a quick example of how to use it.  (That’s the 5 chapters I wrote)

The remaining 2/3 of the book dedicates a chapter to various open source projects going into a little more detail about them.  There’s a chapter on Papervision 3D, SWX, FUSE/Go, HAXE, AMFPHP, two for Red5 and a couple more.

This was a lot of fun to work on, and my only regret is not getting to know the other authors better.

If you’re looking for a place to buy it, check out Bookpool.   I worked for them for a year and they’re really stellar guys.  They offer good prices, but more importantly;  as long as the book is in stock, they do their damndest to get it on a truck the day you order it. (Of course, you’re at the mercy of the publisher if it’s out of stock)

• Run the application (Flex application with view-source enabled)
• Creating a simple diagramming application (14 Minute Video)

We added a

var options:Object = canvas.prepareToPrint( canvas );

Before the print and a

canvas.finishPrint( options, canvas);

After the print, and it seems to have solved our problem even though the documentation says we shouldn’t ordinarily need to explicitly call those.

The XRayViewer has been broken for quite some time. I had originally done it with an AIR beta, and that has since stopped working. So there’s now a newly compiled version just waiting for you to grab.

What is the XRayViewer?

So you may be asking yourself What exactly is the XRayViewer?

All this little app does is host the XRay connector and let you load a local swf. Then it displays the swf with some simple controls to play/stop/advance/back. The big benefit is you can then use XRay (By John Grden + Others) to inspect the swf without changing any code around.

There’s three new (very minor) features in this version:

1. There’s a button to launch the XRay interface in your default browser.
2. The path to the loaded swf is displayed in the top toolbar. (You can copy & paste that into Xray so you don’t have to navigate as far into the hierarchy)
3. New logo / icons

Now Open Source!

The entire project is now licensed under the MIT license. If you install the application and then right click on it you can “View Source” to get the source code for it.

The example application has source attached, and is licensed under the MIT license.  I hope someone can take it and make some really great application out of it.  Please drop me an email if you do!

I recorded a practice-run I did, so here it is…

• Run the application (Flex application with view-source enabled)
• Creating a simple diagramming application (14 Minute Video)