We are proud to announce that we are beginning work on a new book for Adobe Press that focuses on Flash Catalyst, Flash Builder and Creative Suite based projects and the development workflows these tools enable.  Our good friend, Doug Winnie (Group Project Manager at Adobe and web workflow expert), will be co-authoring the book with Aaron and myself.  As we write the book we will be making updates here on our blog about our progress and research. In the meantime, Peachpit.com asked us to guest author a weekly series on Flash Catalyst.  Our first post, Adobe Flash Catalyst: Under the Hood—Part 1 Introduction is now on their site.  Make sure to subscribe, because each Monday a new post will be available.

With the release of Adobe's Flash Catalyst and Flash Builder public betas the Twitter-realm and Blog-o-sphere have been all a buzz with excitement, skepticism and of course questions, questions, questions.  One issue that seems to be the hot topic for the day is the idea that Fireworks CS4 is being treated as a second-class citizen in the new Flash Catalyst world.  The root of this assumption starts with first screen you see in Catalyst, note that Fireworks is no where to be seen:

Tomorrow (May 29th 2009), Adobe is holding their sold-out FlashCamp event at their headquarters in San Francisco.  Aaron and I are both going to be attendence and we are really looking forward to catching up with everyone there.  If you are going to be there, let us know so that we can meet up!

For the last few projects, we have found ourselves creating more custom ActionScript based Flex components then MXML based components. One of the challenges with this kind of development in the Flex Framework is understanding where and when to handle component configuration. When should we set styles? How do we update children components? How can I improve performance and scalability of my application? Trying to define the best answers for these questions have been rolling around in our heads for a while, and we are not the only people asking them.

We felt that the best way to approach solving this issue was to first understand the Flex Framework lifecycle. The lifecyle provides four main stages: creation, growth, maturity and destruction. Adobe has talked about this since the launch Flex but not all developers are familiar with the actual process. Even if you are familiar with the lifecycle, understanding the intricacies and what is available to you as a developer is not well documented or easily digestible. We are seeing a movement of Flex experts researching the topic and trying to provide better insight into the overall process. At Flex|360, RJ Owen and Brad Umbaugh did entire presentation on the subject. At Adobe MAX, there were multiple sessions that covered these concepts.

Problem

In many large projects Flex applications are broken into sub-components to help manage size, loading, content updates, etc. The are multiple ways of breaking a project into sub-components such as using  Flex modules,  building sub-Flex applications that are loaded by the parent application, creating external ActionScript 3 only projects or they may be developed using Flash Professional.   The reason for this architectural decision is based on the nature of the project at hand and the experience of the team building the application.

In large projects, breaking the application into testable parts might be wise.  It also can allow for distributed teams participating in the development process to work together.  Also, if a project is animation and graphical rich, Flash Professional is likely the creation tool for those parts of the application.  To integrate these sub-components into the Flex application, they are most likely loaded via SWFLoaders.  Once loaded into the application domain, the assets can be controlled by the main application.  This is where problems can begin.

Since these sub-application and assets were tested outside of the main application conflict issues do not arise until all of the final pieces are integrated together.  One such problem is the dreaded runtime error “Property [property name] not found on [Class] and there is no default value.”

Starting back in June of 2008, I became a regular contributor to the Adobe Edge Newsletter. My most recent article, "The Future of Flex Components" was just published in the February 2009 edition. In this article, I explore the upcoming Flex 4 (codename Gubmo) component architecture and how it will change Flex develop in the future. Understanding how the new components are designed is critical both from a developers perspective but also a designers perspective so that they can best apply their design in a functional and consistent manner within the technology.

In the same edition, our good friend Doug Winnie also has a new article. In "An iterative approach to the designer-developer workflow", Doug discusses how designers and developer work using an iterative process and how this process can be applied to make a more cohesive team and product. Doug's insights are always spot on and once again his detailed research into workflows is shown in this piece.

The newest release of DevelopmentArc Core is now available on the Google Code Repository.  This release is the first release of the library under the new Core moniker.  Previously the library was released under the Vivisecting Media Code Library, which has been now been deprecated since Core is publicly available.  All updates and new features will be added to the Core system moving forward.

From the code depot you can download a compiled SWC or a ZIP file that contains all the source and ASDoc generated files.  We have posted the ADoc files on-line so that you can easily access them if you do not download them.  Currently, we have 219 unit tests running and passing for the library, which are all available from the source tree if you wish to access them.