Joeflash’s Enigmacopaedia

The Perfect Flex Workflow: Flex Builder 3 with FDT 3.2, Part 1

Posted in Tutorials, Flex, Workflow, Flex 3, Flex Builder 3, Eclipse, FDT by Joeflash on the June 27th, 2009

I’ve long wanted to use FDT to turbocharge my ActionScript coding, but without Flex MXML support I couldn’t justify the cost of getting both Flex Builder and FDT. Then FDT 3.2 came out this past May — finally I had an answer to my prayers with FDT’s new MXML support. And I actually won a copy of FDT Enterprise at 360|Flex Indy: total awesomeness! Now I could decide if once and for all I could get rid of Flex Builder in favour of FDT.

So I tinkered with FDT, converting some of my old projects and seeing how they compiled and ran. And for the most part it all went off without a hitch. I was really quite impressed with FDT’s new Flex capabilities. Also, I had been using Flex Builder for the occasional Flash Professional project for code editing, and FDT now makes that sooo much easier, much like SEPY used to do back in the day.

But it was not to be. Shortly after porting over a Flex project I’m working on, I realize I’d gotten used to having aspects of Flex Builder available in my workflow. Like certain Flex project settings, and the Profiler. Maybe later on I’ll explore the enterprise features of FDT like the Debugger or the SoS logger, but for now all I want FDT to do is gimme that sweet coding savvy which Flex Builder sorely lacks. I mean, there isn’t a single Eclipse-based IDE or plugin I’ve seen which comes anywhere close to the sheer overwhelmingly awesome coding intelligence and snippet templates of FDT.

So what I’d like to be able to do is use FDT for coding both AS and MXML files, and use Flex Builder for the actual compilation, debugging and profiling. And of course the faster compiler and the Network Monitor in Flash Builder 4, when it’s released.

So how do I get the best of both worlds? They’re both available as plugins, so I should be able to install and use them both, right?

Don’t Panic: The Rebranding of Flex Builder

Posted in Flash, Flex, Adobe, Workflow, Flash Builder 4, Flash Platform Community by Joeflash on the May 24th, 2009

I’m going to throw my hat in the ring here: I think naming Flex Builder as Flash Builder is a good thing overall. Part of the challenge for developers today is that there are now so many interconnecting technologies under the umbrella of the Flash Platform, that some of the naming needs to catch up with technology, and I believe that’s what’s happening here.

The Flash Platform now consists of a technological system comprised of multiple runtimes, tools, frameworks, and languages, so that simple words such as “Flash” and “Flex” no longer suffice to differentiate what we’re talking about anymore. In fact, I personally wrote an entire chapter in our book Professional Flex 3 on describing the Flash Platform and the “Flex ecosystem of technologies” just to clear the matter up.

Personally, associating the word “Flex” with an SDK (consisting of a framework and a compiler), a development tool, a framework and an overall development methodology, in my experience has led to a lot of confusion. Using the word “Flash” generically has also lead to a lot of confusion — is it a runtime, an IDE, the file you run in the browser, or an approach to rich media development? What is Flash? What is Flex?

I think the time has come to drop the generic use of the words “Flash” and “Flex”. Or at the very least, for the sake of tech pundits and journalists who may not have the in-depth knowledge of us designers and developers, to assign the word “Flash” as meaning “the Flash Platform” or “the Flash Player”, and have “Flex” mean either “the Flex framework” or “Flash Platform enterprise/RIA development.” That would be my vote, and how I have come to think of those two words in generic terms.

In rebranding Flex Builder to Flash Builder, what we are seeing here is a move away from using the word “Flex” as describing “enterprise or RIA development in the Adobe technology space” (amongst its other uses) toward using the word to describe simply the Flex framework and associated tools. By moving back toward the use of the term “Flash,” Adobe is slowly rebranding Flex as being a subset of the Flash Platform, not a complete technological ecosystem in and of itself, which on the whole is a lot clearer and more balanced. And I’m all for making things simpler and clearer for clients to understand and adopt the technology.

Converting Flash Projects into Flex

When converting from a Flash CS3/4-based project, to a Flex-based project, there are not just one or two conversion paths to consider, there are many, all of which depends on the Flash project in question.

I’m on a discussion on LinkedIn, in which one guy asks if we know anyone who can do a Flash-to-Flex conversion project, which evolved into a discussion on techniques. Rather than post a pages-long reply, I thought I’d post it here instead:

First, for any Flash-to-Flex conversion to go smoothly, you’ll need at least one person on your team with a good dose of real-world experience with both Flash and Flex-based RIA projects (Flash banners do not qualify ;)), to guide the conversion process and make sure the best deployment strategies are implemented.

As far as the conversion path, there are several possibilities. Depending on the kind of project, you may want to migrate some, most or all of the project to Flex. When migrating from Flash to Flex, you’re not just migrating code, you’re migrating from a visual asset instantiation and state management environment to a purely coding-based methodology (if we forget for a second about Design View in Flex Builder).

Indentation Guides in Flex Builder

Posted in Usability, Flex, Workflow, Eclipse, Flash Builder 4 by Joeflash on the March 17th, 2009

When I am coding a large class file with several nested code blocks such as methods, try/catch statements, if statements, for loops, I have to use Notepad++ to have access to Indentation Guides, because this feature is not built into Flex Builder. Indentation guides are vertical lines in the editor that follow the tab stops in the document so that code blocks can be visually tracked.

To me this is an essential feature: it is a crucial element of code assist, enabling me to keep track of all the open and closed blocks. I wish Flex Builder had this feature, which is found in several other code editors. If you want to see this feature in Flex Builder, please go vote for Feature Request #17634 on Adobe JIRA:
[#FB-17634] Indentation Guides in Flex Builder

Help me speak at 360|Flex (and kick some ass in Flex Builder)

Posted in Flex, Workflow, Flex Builder 3, Conferences by Joeflash on the January 17th, 2009

John Wilker, one of the organizers of 360|Flex, has put up a voting system to help decide from 124 speaker submissions which 40 make the cut. If you wanna find out how to kick some ass in Flex Builder, like how to tweak the Eclipse JVM to speed up compile times, use Subclipse for subversion, or code like a mad dog, go vote for my talk. Full description as follows:

Kicking Ass and Taking Names: Optimizing Flex Builder Performance and Workflow

Flex Builder is a great tool. There are times when using this tool is great, grand, works like a charm. And other times it’s an excruciating experience akin to waiting for paint to dry while a crack team of ninja monkeys shove bamboo under your finger nails. This session will show you how to kick some serious ass in Flex Builder: speed up the IDE, code faster, leap tall buildings in a single bound and shoot lasers out of your eyes. (Okay, maybe not the lasers part, but still.) In this session we’ll be talking about:

  1. Optimizing Flex Builder Performance
    • Project Development Best Practises
    • Speeding up Eclipse
    • The Heap Status Indicator
    • Why Compilation Slows Down
    • Command-line Startup Options
    • JVM Memory Tuning,
  2. Using Language Intelligence
    • Code Assist, Syntax Highlighting, Mark Occurrences, Go to Defintion, etc.
    • Code Preferences
    • The Class Outline View & Sort Options
  3. Managing Workflow
    • Useful Keyboard Shortcuts
    • Search & Refactoring
    • The Diff Tool
    • Layouts for Productivity
  4. Customizing The Workbench
    • Custom Shortcuts
    • Customizing the Editor (Syntax Colouring, Changing the Editor Font Size, Bookmarks, etc.)
    • Editing the Workspaces List
    • Migrating a Workspace without getting an ulcer
  5. Code Versioning in Flex Builder
    • The Built-in Eclipse History / CVS
    • installing and using the subclipse subversion plugin
  6. Assorted Plugins (a melee of Eclipse plugins that’ll make your life easier)

Vote Now!! : )

And here’s my official conference bio (in case you’re wondering who the hell this guy is):

Joseph Balderson (aka “Joeflash”) is a freelance Flex and Flash Platform Developer living in central Ontario, Canada. He spends most of his time in his home studio mainlining code like a junkie on a binge tripped out on trance music, surrounded by three loving cats whom he’s training to meou on cue so they can answer the phones for him (but so far no success). In his spare time he… wait, what spare time?? Joseph is a staff writer at CommununityMX, and lead author on the upcoming book
Professional Flex 3 by Wrox/Wiley Publishing.

Moving a Flex Builder/Eclipse Workspace Without Importing Anything (Update)

Posted in Flex, Workflow, Flex 3, Flex Builder 3, Eclipse by Joeflash on the November 27th, 2008

In the last post, I examined how to move a Flex Builder/Eclipse workspace to a different directory location without re-importing all your projects. Only it didn’t work as well as expected. I finally figured it out, but use at your own risk, since this involves editing Eclipse binary metadata files.

Currently there is no user-friendly technique for moving an entire Eclipse workspace folder to a different directory. This I most wanted to do because the current technique involves the painstaking task of creating a new workspace, then reimporting all projects, reconfiguring all compiler settings, and then re-imputing all the SVN location data for Subclipse. Blech!!

I wanted to move all my workspaces from my C:\ drive to a C:\_fx3\ directory to get them off the root drive. But I don’t have whole days to mess around with importing projects and making sure all the settings have been imported faithfully. I just wanted to move entire workspace folders to the new directory, make a few metadata file hacks, and be done with it.

Well, as it turns out, it’s not that easy. What makes all the difference for most workspaces are not the XML metadata, which seems to be mostly for caching, but the .location files in the metadata project directories, which is where the absolute directory location for each project folder is referenced. Problem is they’re not meant to be user-edited. So use this technique at your own risk, as other absolute directory dependencies may exist that I’m not aware of. For now consider this an experiment in progress.

1. Copy your workspace to the new directory location.

2. Edit the XML metadata files in the workspace folder as detailed in this last post.

Now here’s where it gets interesting.

3. Find the .location files in the workspace metadata. They are located in the

\{workspace dir}\.metadata\.plugins\org.eclipse.core.resources\.projects\{project folder}


3. Open up each .location file in a Hex Editor application. I’m using the free Hex Workshop utility from pbsoft.

Now let’s take a look at the process for editing one of those files.

4. Edit the URI in the binary data. In the Hex for each file you will see the characters “URI” followed by the absolute directory path for the project folder in question. Edit the path, making sure to add or delete bytes as required.

In my .location file, the old path is:


editing the .location file - start

I edit the new path to be


5. Edit the byte before the “URI” to be the new character length of the path.

If your code editor has hex-to-dec conversion, as mine does, you can see that the character length of my old path, which includes “URI”, is hex 2C or 44 characters (see image above).

Select that byte value, and replace it with the character length of the new path. I got the character length by using word count in MS Word (Tools > Word Count…).

URI word count

The length is 49 characters, which is hex 31.

editing the .location file

5. Save the file.

6. Repeat for each .location file.

Now when load up Flex Builder and point to the new workspace location, I verify that the project does indeed point to where I told it to in the .location file. And my SVN locations are conserved, as are all my preferences. YAY!! :)

verifying the successful workspace move

Unfortunately, although this hack works, it’s a lot more trouble (or at the very least the same) as making a whole new workspace and importing each project one by one. I had to Hex edit over 20 files to move the entire workspace — which could hardly be considered a time-effective solution. I can make things easier on myself my copying the entire workspace to my new directory, but I still have to delete and recreate the workspace metadata by pointing to that new workspace folder, and then re-import every project in that workspace. Still, I learned quite a few things about Eclipse in the process, which was partly the goal of the exercise for me anyways.

Although I’ve used it for a few days now and I have not seen any compile or file referencing problems, and it seems like a sound solution, this technique has not been battle-tested, and I’m not an Eclipse developer by any stretch, so I’ll say it again:
use this technique at your own risk. Don’t come crying to me if this hack corrupts or messes up your Flex Builder or Eclipse workspace in any way.

If indeed this hack proves to be stable, as it seems to be, the next step would be to create a batch file or something that could at once copy the complete workspace directory to a new location, seek out and edit all the required XML metadata files with the correct path references, and hex edit all the .location files with the changed URI and adjust the length byte accordingly. Maybe even a custom eclipse plugin written in Java? Hmmm… But that task lies beyond my time and current programming abilities at present, so I will leave you with that final tantalizing thought.

(maybe some enterprising Eclipse developer will read this and decide to surprise us with a plugin, hint hint ;) )

Flex Builder Tip: Moving an Entire Workspace in One Step Without Importing Anything

Posted in Flex, Workflow, Flex 3, Flex Builder 3 by Joeflash on the November 24th, 2008

I had a situation recently where I had way too many workspaces sitting in my root C: drive folder, so I decided I wanted to move them to a subfolder with a very short name like “_fx” just so all my Flex workspaces are all in the same place, and to make backup archiving easier.

If you’re wondering, I have dozens of workspaces, one for each client and/or writing project, each of which has an average of 20+ projects.

Problem is, the conventional way is slow. Really slow. I’d have to create a new workspaces directory location (C:\_fx in my case), and import every single project into every new workspace. And even with saving preferences, I’d lose things like Subversion site locations in the Subclipse perspective. And with over 20 workspaces,. each with an average of 20 projects… I’d be at it for weeks. So I needed a shortcut.

So I dug around in the workspace metadata files, and eventually found where the directory locations reside for each project in that workspace. Luckily, it’s all in one file, so the hack is relatively simple.

Correction: unfortunately it’s not one file you have to edit, it could be a few XML files. And unfortunately this hack doesn’t work with all workspaces unfortunately. See below.

1. Make a copy of your workspace folder to the new location. Don’t move it, in case anything goes wrong. I found this out the hard way by wiping out the metadata for a workspace with over 30 projects — ouch!

2. Find the .metadata folder for the workspace.

3. Find the following files and open them in a text editor:





4. Find & Replace all instances of the old directory location with the new one.

For example, for my \profx3book workspace, I replaced all instances of “C:\profx3book\” with “C:\_fx\profx3book\“.

5. Save the file, and point Flex Builder to the new workspace. Once you’re sure everything is where it should be, delete the files in the old location.

Et voila!

PS: Yes, I know, the above lists five steps, not one — but really it’s only one step: replacing the location string in the workbench.xml file.

PPS: Important Caveat: Search for all .location files in the workspace .metadata folder. If there any files found, this technique might not work, since the directory location for that project is stored in .location files as binary data, and cannot simply be edited with a text editor. So use this technique at your own risk.

Flex Skin Design Extension for Flash CS3 ReferenceError 1056 Workaround

Posted in Flash, ActionScript 3.0, Flex, Workflow, Flex 3, Flash CS3 by Joeflash on the April 12th, 2008

This week while writing a tutorial for the Flash-Flex Integration series, I came across this very strange error whenever I tried compiling my Flex project using a skin which had a boundingBox clip on the timeline, using a Button skin template in the Flex Skin Design Extension for Flash CS3:

ReferenceError: Error #1056: Cannot create property boundingBox on Main_01__embed_css__1922336847.
at flash.display::Sprite/constructChildren()
at flash.display::Sprite()
at flash.display::MovieClip()
at mx.flash::UIMovieClip()[E:\dev\trunk\frameworks\projects\flash-integration\src\mx\flash\]

Unfortunately this error occurs whenever you place any kind of MovieClip (and I suspect any non-drawing object as well) on the timeline.

The solution, it would seem, is to simply declare the object on the skin timeline:

var boundingBox:MovieClip;

Which seems very odd to me, given that UIMovieClip is a dynamic class.

Just to verify for myself that this was true, I placed the following code on the timeline:

  1. import flash.utils.*;
  2. trace("class: "+describeType(this).@name+"\nextends: "+describeType(this).@base+"\nis dynamic: "+describeType(this).@isDynamic);

Which, sure enough, returned

class: Custom_button_skin
extends: mx.flash::UIMovieClip
is dynamic: true

This is very puzzling to me. I’ve logged a bug on the Adobe JIRA bugbase. I’m hoping they patch it soon or release a technote; people using the extension should be aware of this issue, or much tearing-out-of-hair may ensue.

Update 2008-04-18: Just discovered that Jesse has found the same bug, and it’s not really a bug but a quirk of the Flash compiler not automatically declaring class instances on the stage.

My guess is that this error is appearing because normally when you associate a class linkage with a MovieClip in the library, you need to declare your stage instances, as automatic stage object declaration is turned off. Same here, except the class associated with that container is UIMovieClip, which is not a custom class where you can place your object definitions. I still think there needs to be a mention in the FCK documentation about this.

As soon as I saw Jesse’s post I smacked myself in the head proclaiming “Of course!”

Some weeks are just like that.

Flash-Flex Integration: New Article Series on Community MX

Posted in Flash, Flex, Community MX, Workflow, Flex 3, Flash CS3 by Joeflash on the March 26th, 2008

I’ve just started a new article series on Community MX all about strategies and techniques for implementing an integrated Flash-Flex workflow. Which is to say, using Flash objects and classes to be compiled into a Flex SWF application, or Flex objects and classes compiled into a Flash SWF application.

Despite some very excellent articles on Adobe Devnet, the information that’s out there can be a little confusing, and there are a lot of niggly things to keep track of, and many possibilities to explore regarding integrating Flash assets into a Flex application, or Flex assets into a Flash application. So I started this new series as a way of exploring that seldom ventured “grey zone” between the Flash and Flex development workflows.

The series kicks off with a high-level discussion on workflows, to be followed in the coming months with tutorials for implementing specific techniques.

a bird's eye view of the Flash-Flex workflow
A bird’s eye view of the Flash-Flex workflow

Like all my series on Community MX, the first one is free, and the rest are available for a pittance or at a subscription rate.

Business Tips For Freelancers

Posted in Business, Workflow by Joeflash on the March 18th, 2008

Recently I was asked for some advice from a developer on how to manage her first big client. Here’s what I told her:

  1. Take care of the business side of things before the work is done. Which means:
  2. No spec work, no freebies. If they like your portfolio and your references enough to hire you, you should get paid for all the work you do for them.
  3. Get something in writing about what your rate is, what you agree to do for them, and how much you charge, per hour or per project. That can mean a contract signed by both parties, or an email which both parties have confirmed.
  4. State in your contract/agreement when you expect to get paid, and in what format: 50% up front, the rest upon delivery, or 15, 30 days after? Billable weekly? (for longer projects, if charging an hourly rate) Bi-weekly? By cheque, credit card, interac email transfer? (my favourite)
  5. Charge more if the deadline is tight, which means high pressure, possibly requiring you to pull an allnighter or two. And if this is the case, tell them your rate is slightly higher for short deadlines. More stress for you means more money from them. As a rule of thumb.
  6. During the work, get their feedback a little more that you think you need to, but not so much that it encourages scope creep. Clients like to be involved in the process, but you need to know when enough communication has been had. Typically a check-in once per week if the project is a few months long, once every day or every few days if it’s got a crunch deadline attached to it.
  7. Try to never miss a deadline you’ve committed to.
  8. But shit happens. If you commit to a deadline, and you think you can miss it by a margin without breaking the project (or the client), advise the client well ahead of time, communicate. And offer them a discount on the final fee if it keeps them in your good graces. And then make your renegotiated deadline, no ifs ands or buts, or your word will mean nothing from then on.
  9. If you placed yourself in a corner, and you absolutely cannot end-of-the-freakin-world miss the deadline, and you don’t think you’ll make it, tough. Don’t sleep. Or you’ll never see that client again, and most likely your fee either. The trick is to never place yourself in that position in the first place.
  10. Don’t do it alone. If you encounter a problem, a technical issue you cannot solve, seek support from newsgroups, lists and friends. Because it will save your bacon one day, I guarantee you. But don’t expect a fast reply from lists and groups. And Google is your friend (like, duh.)
  11. Create a support group for yourself, composed of mentors, teachers, colleagues, people whom you have enrolled to help you with a quick email or IM now and then to save your bacon spur-of-the moment in a real tough spot.
  12. And when they do, thank them. Show gratitude. It’s all about relationships. Send them passes to a movie, or help them out in turn. Nobody likes a taker.
  13. Put together a deliverables document to be submitted when you hand over the project, or add these as line-items in your invoice (which should be simple but well-designed), which shows professionalism and attention to detail.
  14. If you’re required to put together documentation for the work, make sure you charge for the time it took to research and/or put it together.
  15. As a courtesy, only charge for phone calls or meetings if it’s a consultation type meeting, not a project briefing, and it goes longer than 1 hour.
  16. Develop lasting long-term relationships with your good clients. Send them a Christmas or Hanukkah card, and a thank you postcard (a real snail mail one!) after a successful project. It’s the little things that get you noticed, that get them to be return customers.
Next Page »