Joeflash’s Enigmacopaedia

In the last article on Community MX, we looked at how to use Flex Builder as the ActionScript 3 editor for a Flash-compiled project. But if you are using any Flash CS3 components, Flex Builder is unable to recognize those classes. In this article, we will take a look at how to get Flex Builder to recognize the Flash CS3 Component classes for editing ActionScript 3 files in Flash CS3 projects.

How do we get Flex Builder’s code assist to recognize Flash CS3 Component classes?

( I’ll give you a hint: you find all the fl.* class locations in the Flash CS3 installation directory, and reference them as external source paths in Flex Builder )

For the full, step-by-step explanation, the tutorial is available here on Community MX.

If anyone has tried to use System.showSettings() and wondered why it wasn’t working, I noticed that in all three reference manuals — AS3 ref, Flex 2 Lang ref, Flex 3 Lang ref — the Camera class has contradictory information about which class the showSettings method belongs. Must have been a typo left over from the AS2 days, and accidentally got duplicated. All three pages say the same thing:

Note: The attachCamera() method will not invoke the dialog box to Allow or Deny access to the camera if the user has denied access by selecting Remember in the Flash Player Settings dialog box. In this case, you can prompt the user to change the Allow or Deny setting by displaying the Flash Player Privacy panel for the user using Security.showSettings(SecurityPanel.PRIVACY).

If getCamera() returns null, either the camera is in use by another application, or there are no cameras installed on the system. To determine whether any cameras are installed, use the names.length property. To display the Flash Player Camera Settings panel, which lets the user choose the camera to be referenced by getCamera(), use System.showSettings(SecurityPanel.CAMERA).

The first reference is correct: the showSettings method belongs to the Security class in AS3.

Logged a bug here as well.

The latest in the Flash-Flex Integration series on Community MX, this tutorial shows you how to use Flex Builder as an ActionScript 3.0 editor for Flash-compiled projects. It also delves into techniques, best practises and caveats in using Flash and Flex Builder together in the same editing workflow.

This one was just too good to keep to ourselves, so we made this tutorial available free to the community. You can read the tutorial and download the PDF and all source files here.

The Flash CS3-Flex Builder 3 Workflow

Flash Actions panel or Flex Builder: for code editing, there is no contest.

In part 3, part 4, and part 5 of the Flash-Flex Integration Series on Community MX, we show you how to build a scale-9 skin in Flash, apply it to a custom Flex component, and build a draggable, resizable “panel” component application in Flex. You can see the finished demo for this tutorial trilogy below.

The skin was designed in Flash CS3, and implemented in Flex Builder 3. To find out how this was done, you can purchase these tutorials at the links below.

Flash-Flex Integration - Part 3: Flex Component Skinning with Scale-9
Flash-Flex Integration - Part 4: Skinning the Scale-9 Flex Component
Flash-Flex Integration - Part 5: Building the DragPanel Component

I’ve a few new articles on the Flash-Flex Integration series on Community MX. This latest article is part one of two about creating a custom Flex component skin using Flash CS3 along with some deft scale-9 techniques and gotchas.

In this first article, we will design a skin in Flash CS3 for a Flex component, which is able stretch intelligently using a concept known as scale-9. We will look at several techniques for designing assets in Flash using scale-9 effectively, avoiding certain important gotchas along the way. We will also demonstrate how one Flash skin file may be applicable to multiple Flex components. In the following article we will implement this skin for a Flex custom panel component with drag and resize handles.

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:

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:

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:

Which, sure enough, returned

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.

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

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.

As both a Flash and a Flex developer, I can say that designing and developing a highly visual experience such as a promotional website for an automaker like this recent Volkswagen site seems to me like putting a round peg in a square hole.

One of the main roadblocks to building highly visual experiences in Flex, as Yacov Fain mentions, is that performance, particularly load times, can suffer dramatically.

Up until recently this was thought to be due primarily to the weight of the Flex framework itself, adding at least another 150-250K onto your SWF file size. Thinking that the weight of the Flex framework is the only performance bottleneck in this regard, people are looking to have Flex do what Flash does — “Now that we have persistent framework caching, we don’t have to worry about SWF filesize anymore, right?” Wrong.

This assumption highlights a growing attitude that Flash-built applications are somehow “less sophisticated or evolved,” which tends to result in the shoehorning of all Flash Platform Development though the Flex framework. Wrong again.

Just because an application does not use the Flex framework or MXML, does not mean developers need to resort to the pathetically inadequate Flash IDE code editor. One can very easily lay out the application and its animations in Flash, use Flex Builder, FDT or FlashDevelop as the coding environment, and back to Flash for compilation.

As Flex developers we are spoiled. We have layout managers, GUI interaction managers, a component framework and a whole host of RPC communications tools that really make our lives a whole lot easier, to name a few. But that ease of use comes at a cost, and it isn’t just filesize. It comes with a programming mindset that encourages one to find the solution to a problem in the Flex framework first, and in the core ActionScript API second. This can lead to over-architecting simple applications.

Flash projects which enable more visually-engaging than data-oriented experiences are usually built under tighter deadlines which don’t lend themselves well to planning of architectural frameworks. But this doesn’t mean that they are not sophisticated. You can’t possibly look at the class structure of an open source library like Papervision 3D and say it’s unsophisticated. And yet there is a perception that projects of a certain complexity need to be developed in Flex. Which is simply not true.

As a Flash ActionScript 2 developer, before AS3 came out, I remember we had to build almost everything from scratch, as compared to the toolsets we have in Flex. Macromedia had a component architecture and data components, but to me they seemed bloated and sometimes even buggy compared to what could be done from a custom implementation. Every Flash developer had their own personal class library built up over the duration of their career, cobbled together from bits of open source code, personal experiments, and blood sweat and tears pored over late night projects. And the measure of how good you were as a Flash developer was not how many blog posts per day or twitters per minute you published, but the strength of your personal coding library, giving you the ability to whip out a manager or a utility class to suit almost any need. Every Flash development firm also had their own custom class libraries, sometimes jealously guarded under pain of legal action. A few brave souls and companies even shared their discoveries and their code base with the rest of the community, and a few key open source libraries were available to do common tasks like bitmap effects, tweening and data communications. The trend continues to this day.

As an aside, having to maintain your own private coding libraries as a matter of survival, and learning to adapt to any possible combination of coding techniques of other developers, from the ridiculously procedural spaghetti code to the rube-goldberg-esque constructs of some over-zealous patterns fanatics, really forces you to grow as a programmer. So I don’t care what anyone says: Flex developers are not necessarily better programmers just because they know Java or can use J2EE patterns which have never seen the light of day in a SWF before Flex. Flash developers who have been in the trenches and sweat blood to help the Flash Platform evolve into the ActionScript 3.0 powerhouse of today are just as good. So don’t give me any of this Flash versus Flex crap. Just Stop it. Flash dudes, you’re just as good as the Flex guys. And Java-come-lately Flex developers, stop looking down your nose at the Flash guys. As a Flash-turned-Flex developer, I have a great respect for both kinds of developers.
Can’t we all just get along?

(and now, back to our regularly scheduled blog post)

The problem with the coding library diversity present in ActionScript 2.0 development was that, as a Flash developer, very rarely would I come to a Flash project and see the same coding libraries, or even coding methodologies, used to build a project. There were virtually no standards IMO apart from a few well-used Macromedia components and popular open source class libraries like Fuse or MCTween. So literally half the Flash projects I worked on involved fixing or updating someone else’s code. This is where Flex shines as opposed to Flash, I think, because it gives the developer the safety of a standard toolset and class library to work with.

But today in the world of Flash development, there is a much richer base of open source libraries available for the ActionScript 3 developer, thanks in part to the growing popularity of the Flex platform, and the rest thanks to the increased power of the new ActionScript 3.0 API and virtual machine. Some that come to mind are Sandy, PaperVision3D, Pure MVC, Alive PDF and Degrafa.

But there is still the perception remaining from the ActionScript 2.0 days that coding standards and libraries are not as abundant for Flash/ActionScript 3.0 projects as opposed to Flex projects. Again this is simply not true.

Working with the Flash IDE as the “layout editor and compiler,” along with one’s choice of coding editor, assumes a certain coding methodology, and that is that most of the functionality will be done from scratch (i.e. build on the core AS3 API), or rely on a patchwork of custom and/or open source libraries, including the lightweight CS3 components.

In Flex, one also assumes a certain coding methodology. This means working with the Flex Framework first, and getting down and dirty with the AS3 API second. In the case of loaders, this means that most Flex applications rely on the creation policies of ViewStacks and States, and the default behaviours of Module loaders or the Loader class for external assets.

The first and most important rule of web usability for RIAs, in my book, is that the loader is the very first thing a user will see, therefore it must be the most optimized and streamlined part of the entire application. In the words of Chris Tucker, a loader must Pop! Pop! Pop! :)

It was Bad sound bite  Chris Tucker sound bites

The problem is that, for all the ease of use and capability of the Flex framework, the loading of assets and modules leaves much to be desired. I have yet to see a loader in Flex which utilizes load queue prioritization, an essential feature to any intelligent loading strategy. Whereas loading queue classes have existed in the Flash coding world since 2003 and earlier.

By using Flex, one adds the architectural weight necessary to build a solid application, with none of the loading intelligence. And this can cause critical performance issues.

Now, I am not saying that all these assumptions were present in the creation of the WV website, and in all fairness they did a fantastic job, but was Flex really the appropriate thing to use? Perhaps.

When you’re thinking about designing a website with a highly visual experience, think of developing it without the Flex framework first. In this I agree entirely with Ryan Stewart’s sentiments. And if you find you need the data components, or you absolutely need to have certain utility classes, or part of the experience is very component driven, then think about using Flex. But don’t assume you automatically need Flex simply because you’re publishing for the Flash runtime, because that assumption may cost you in performance, and ultimately, in eyeballs to your site, as it no doubt will for the newest poster child for Flex website development.

A Plea To Adobe: Open Source The v2 Architecture!

Flash and Math AS3 Tutorials