ActionScript3

I found an interesting trick with embedding fonts today while working with the Text Flow engine in Flex 4.  What I found out is that you can embed multiple fonts under the same font family name, but set the properties such as font weight or font style to different settings based on the font source you are using.  This may be an obvious thing to a lot of people, and the property name ‘font-family’ makes a lot more sense now, but for me it was a real ‘ah-ha’ moment.  By the way, this isn’t just a Flex 4 thing, you can do this with Flex 3 and probably AS3 only projects (haven’t tried that yet) but the issue became more apparent in Flex 4’s new TLF enabled components.

The problem came about because we have a set of fonts that provide each style type in a unique OTF file, i.e. Font-Regular.otf, Font-Bold.otf, Font-Italic.otf, and Font-BoldItalic.otf.  In the past, we just embedded this with unique font-family ids (font-family: “Font-Regular”) and then just bound them via CSS.  This approach becomes a significant problem when starting to work with TLF’s selection management and Text Format.  We are building a simple Rich Text Editor in Flex 4 (since its not available yet in Beta 2) to allow a user to set their text to bold, italic or underline.  Simple enough, right?

Well, its not so simple when you have your font styles spread across font identifiers. The way we started to handle this is that when the user selected some text and applied Bold, we would set the text format’s font family for the selection to “Font-Bold”. To enable the ability to toggle the style, we would ask for the selection ranges format, look to see what the font family is and then toggle it to either bold or normal.  Now, let’s say that the user selects a section of text that mixes bold and normal text.  When you get the text format back, the font family property is set to undefined, letting you know that you have a mixed set.

In the bold/normal case this is easy to solve, but let’s say that you have bold, normal and italic text in the selection.  Because the property is undefined we can’t determine this nor can we just apply the new style across the entire selection because you would remove the italic (in the case of applying bold).  At this point I was getting kind of upset because the solution wasn’t sounding pretty.  We were looking at having to loop through the selection, grabbing the leafs and then looking at the format to determine the correct selection.  I was going to punt on it as a bug for now and move on.

This morning, while making coffee I thought about the fact that the key for the CSS font embed is font-family, and that when using @font-face that you can actually set things such as font-weight.  What I found out is that you can embed different sources under the same name as long as they have different style properties:

@font-face {

    src: url("./assets/fonts/Font-Regular.otf");

    font-family: MyFont;

}

@font-face {

    src: url("./assets/fonts/Font-Bold.otf");

    font-family: MyFont;

    font-weight: bold;

}

@font-face {

    src: url("./assets/fonts/Clean UI/Font-Italic.otf");

    font-family: MyFont;

    font-style: italic;

}

@font-face {

    src: url("./assets/fonts/Font-BoldItalic.otf");

    font-family: MyFont;

    font-weight: bold;

    font-style: italic;

}

Now I can treat the font as the same family and then toggle the style properties, such as font-weight or font-style without having any font conflict.  This fixes the Text Format issue and also allows for a much cleaner/consistent CSS file.  I am sure this is explained somewhere (probably in the documents, clear as day), but I never knew that you could do this… hope it helps!

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.

Yet, even with this kind of coverage, the topic is so broad and deep that many of these sessions have to skim over some of the more minuet details for brevity’s sake. Our own curiosity had been peaked and we decided to pull back the covers of the Flex SDK and take a look for ourselves. Over the last two months we have spent hundreds of hours working on a white-paper (research, discussion, writing and editing) that explores the Flex Component and Application lifecycle. We are proud to announce the release of new DevelopmentArc™ Article section and the white-paper “Understanding the Adobe Flex® 3 Component and Framework Lifecycle“.

This article is a living document, one that we hope to grow and expand over time. We are always looking for feedback and questions about the content of the article. As you read the document and you find yourself with a question or idea to improve upon let us know! We hope that reading this article is as enlightening to you as it was to us…

[Read The Article]

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.”

Recently I was asked to debug a client application (we did not initially develop this app), that was throwing this error intermittently.  I struggled for about two hours before I found a pattern in the application and sub-application code base.  The pattern was a common package naming structure.  Each sub-application had the same package structure and some of its classes were named the same. However, the same named classes had a different set of public methods (API).  Now, these same named classes were internal to the sub-application (not declared on the parent app) but this error was still being thrown intermittently at runtime.

Here is an example of the two matching packages with different APIs:

Project A

Project B

The problem was, when a  sub-application was loaded into the application, the previous sup-application was not fully unloaded and it’s BaseComponet class was being retrieved from memory instead of the new BaseComponent that was just loaded. At this point the new app is expecting a certain API yet it’s not there, causing the error I outlined above.  This only happens in certain cases (I can’t explicitly define the load order, it just happened when rapidly clicking around loading and unloading applications). But, if the main application also has a BaseComponent declared under the same package structure, this problem will be visible every time. The sub-application’s version is ignored and the error above will happen the first time the sub-application is loaded because the parent instance will always be used.

Main Application

Solution

The solution is simple.  Make sure each project has a unique package structure or define a standard Interface that is used across the entire application and sub-applications. To solve this problem in an existing application is just add the project name after “developmentarc” making the structure unique per application.

Project A

Project B

Main Application

The hard part about the solution is communication. On large teams, this is a topic that needs to be tackled during the planning or architecture phase of a project, not post-development.  Try coming up with a standard package pattern that all members can follow. This can be included with Coding Standards or with other development team guidelines as a project kicks off.   The longer a team waits to tackle collaboration issues like this, the harder it is to change. Refactoring a 100+ projects can be very time consuming and at the end of a project, developers have more important issues to resolve other than a large scale refactor.