The Joy of Flex

10 am. Topics this talk will cover: SystemManager and FocusManager, Accessibility, Localizing Flex Apps, Functional Testing, Deep Linking, Performance, and Random Thoughts.

The framework is the set of class libraries that Adobe provides to Flex developers. UI Components, Media Components, Layout Management, Charting Components, Expressiveness, and Data. As the framework evolves, this list will grow. We try to focus on making the framework extensible rather than trying to build every possible component into the framework. Read the code in the framework!

The display list. The player maintains a tree of all visible or potentially visible components. That’s the display list. At the root of the tree is the application, and everything else is a leaf or branch in that tree. All the addChild, removeChild calls are manipulating the display list. The SystemManager is the way to access fonts, styles, etc. on the display list.

The SystemManager is at the root of the Flex SWF, it’s one of the first classes that is instantiated. The most important job of the SystemManager is actually creating the application and adding it to the display list. The first few bytes of the SWF are enough to instantiate the SystemManager, which tells the player to stop executing after frame 1. (A Flex app is a two-frame movie; the first frame has the SystemManager, the preloader, and a few other things; the second frame has all your code, the Flex framework, etc.) The SystemManager then creates the preloader, which creates the progress bar. Then the SystemManager creates the app instance and sets Application.systemManager to itself. Then the application starts creating itself, creating all of its children, then emits the CREATION_COMPLETE event. That’s when the app is added to the display list by the SystemManager. Then the APPLICATION_COMPLETE event is emitted.

The SystemManager also manages layers of children for popups, cursors, and tooltips. You can access these top-level objects through the SystemManager.

The FocusManager manages focus on components in response to mouse or keyboard activity from the component level (vs. the player level). An application can actually have multiple instances of FocusManager, because it governs a tab loop, and you might want to have more than one tab loop. The player has a fair amount of focus management built into it, but we override a lot of that in the framework in order to manage it at the component level rather than the player level. So there are the concepts of player level focus and component level focus, and FocusManager manages component level focus.

As an application developer you may not need to worry about FocusManager related interfaces, but if you are a component developer, you will. Basic keyboard and focus handling is as simple as implementing IFocusManagerComponent and writing a UIComponent.keyDownHandler. Also there is a property on UIComponent called focusEnabled which says that your component can receive focus. For example, a Label will have focusEnabled set to false. All the controls in the framework can be operated with the keyboard. They all implement a keyDownHandler function.

It is an application developer’s responsibility to think about accessibility. Consider how users will interact with content. The Flash Player is already compliant, so you get a lot for free: you can use the player API (flash.accessibility package) to handle screen reader interaction And there is a lot of accessibility built into the framework as well.

To compile an accessible SWF, you have to enable it. That’s because we don’t compile the accessibility classes in by default, in order to save space. So we make it opt-in so you know you’re making things bigger.

Localization in Flex is similar to Java: properties files with key-value pairs. They are called resource bundles. You can do this in ActionScript or in MXML. In ActionScript you decorate your variable declarations with [ResourceBundle]. In MXML you use the @Resource directive. Properties files have to be in UTF-8 format.

In Flex 2 you need to do the work yourself to request the right locale SWF based on the browser’s preferred language. In Flex 3 there is more support for this but there is still work you have to do to load the right locale SWFs, and you can switch locale at runtime (which you can’t do in Flex 2).

Different languages take up different amounts of space because the text may be bigger or smaller depending on the language As a rule, the application will resize and reflow containers to handle these differences automatically, assuming you use constraint-based layout.

In Moxie, we added the ability to do runtime localization. You no longer have to compile the resources into the SWF, you can put them in a separate SWF, you can compile multiple languages into a single SWF and change on the fly. You access all resources through a new manager, the ResourceManager. Binding expressions that reference resources will automatically update when the language changes. You can localize non-string assets, and you can programmatically create resources at runtime and use them just like they were compiled in.

There is an Automation framework in Flex (mx.automation) that allows you to automate user level interactions, and verify that the application state is expected before and after each interaction. All the Flex framework components implement the automation interfaces. As an application developer you need to use human readable unique identifiers for each object in the app (the defaults work but are ugly), you need to remove unused containers from the automation hierarchy (showInAutomationHierarchy=false), and you need to link in the required automation libraries (not included by default because it increases the SWF size). There are other test tool vendors besides Mercury who are working on support for the Flex automation framework, but no news right now on who they are or when they might be available.

Flex 3 adds support for deep linking, where the URL changes according to the state of the application. There is a new BrowserManager that keeps track of anchors and fragments. The anchor is the part before the # sign in the URL, and the fragment is the part after the # sign. The fragments get stored in the browser history so you can use the back and forward buttons. The HistoryManager from Flex 2 is still there for backward compatibility but is turned off.

Improving Startup Performance. Watch what you do at startup. Don’t call setStyle() if you can avoid it, it’s one of the most expensive calls in the framework since it can trigger reloading styles in every component on the display list. If you have to call setStyle(), do it in the INITIALIZE event handler instead of the CREATION_COMPLETE handler. Use deferred instantiation when possible (leave creationPolicy=”auto”). Avoid unneccessary nesting of containers. You can use the Canvas container for absolute positioning which reduces layout and measurement. Also, In Moxie, you can set sibling-relative constraints and partition components into columns and rows.

Playing complex effects smoothly. Try increasing the duration of the effect with the duration property. And the less there is for the Flash Player to redraw, the smoother the effect plays. Avoid bitmap-based backgrounds. And try Effect.suspendBackgroundProcessing=true, but be careful to start it back up again. You can also improve things by temporarily hiding the background under which the effect is playing so it doesn’t have to redraw on every frame; hook into the EFFECT_START and EFFECT_END events to do this.

Access modifiers. Typically you see public, private, protected, and mx_internal. When we were porting the framework to AS3, anything we knew you would need access to we made public, anything in a derived class we made protected, anything we thought you would not need access to, we made private. We made mistakes there! File a bug! It’s easy for us to make something protected instead of private. If something is mx_internal, we are saying this might change. If you are accessing an mx_internal property, maybe it’s a bug, and it should be promoted to protected or public, so file a bug. If you use mx_internal you sign up to do maintenance later.

We have an open bug base now at http://bugs.adobe.com/flex. Please file bugs! The better your bug description, the better the chances are that it will get fixed. We thrive on feedback from the community. Also please search for bugs, and if you find it’s already logged, vote for it so we know that it’s important to many people.

Flex engineer blogs:

• Ely Greenfield: quietlyscheming.com

• Alex Harui blogs.adobe.com/aharui

• Gordon Smith: blogs.adobe.com/gosmith

Technorati Tags: 360Flex