For a recent client project, we were having an issue with using superscript to display the number next to a disclaimer information. In HTML this is accomplished by simply wrapping a <sup> tag around the text. For example: "¹ The client wants a disclaimer here." looks like:

¹ The client wants a disclaimer here.

However, Flash does not support superscripts or subscripts in HTML text out of box, so a "hack" of some sort needed to be applied

A while back, a friend of mine and fellow Flex developer was consulting on a Flex 4 based application.  He was having a troublesome issue where in some cases the skin state was not updating in his application when he called invalidateSkinState().  The problem was that when he called invalidateSkinState(), the getCurrentSkinState() was never called during the next commit properties phase (think validation during maturity, eee our whitepaper for more details). It wasn't consistent in the code and it only happened in a few specific cases. 

He asked me if I had ever seen the issue where getCurrentSkinState() is skipped after calling invalidateSkinState(). At that time I had never seen a problem with the Skin state not updating, so I didn't have much guidance for him.  He found a solution which involved making sure to call both invalidateSkinState() and invalidateProperties() at the same time, even though invalidateSkinState() should also invalidate properties for you.

About three weeks later, I stumbled upon the same issue while working on an application.  Inexplicably, one of my components started ignoring invalidateSkinState() and the skin wouldn't change.  After setting some breakpoints and screaming at the code for a while I finally figured out what the cause was.  I had mistakenly used invalidateSkinState() within the commitProperties() after calling super.commitProperties():

At Max one of the most interesting announcements was around the BlackBerry PlayBook.   The new device presents a slick 7'' screen and is packed with a 1GHz dual core processor and 1GB of RAM. The device will run BlackBerry's Tablet OS and come stocked with developer's favorite runtimes. Those include Open GL, WebKit, SMP, Adobe Flash, Java, and Adobe AIR.

For us Flash developers, the most important specs are that the device will ship with Flash 10.1 and with Adobe Air 2.5. This means all Flash content on the web will be viewable via the latest WebKit. And Flash developers can take advantage of the Blackberry Tablet OS SDK and a Flash Builder plugin to create ActionScript based projects. The SDK seems to be a custom version of the Flex 4 SDK, but from what I understand, they do not recommend you use the Flex 4 component set. BlackBerry has created their own core set of ActionScript components for general use and to assist with developing custom components that are performante on the device.  

The SDK does support Flex's resource bundles, which means, your application can take advantage of internationalization. This is an important feature considering  the PlayBook will be released in multiple countries in 2011.

Flex 4 has introduced a new preloader and with it a series of new events that we can leverage.  I am not going to take much time explaining how to build a preloader, there are some solid examples out there to cut your teeth on. The first example is Adobe's official documentation.

We are proud to announce that DevelopmentArc is introducing a new training program focusing on Flex 4 development.  Each training session will be a live seminar hosted online using Adobe Connect.  We will offer our seminars multiple times each month, hopefully providing a good window for anyone who is interested.  Our sessions also include unique training materials that are provided to you after each session.  These materials include the source code we demonstrate with, a PDF copy of the slides and any custom training material we are creating for each series.

With a little less than a month until 360|Flex I thought I would sit down and write a long over due post about the conference.  360|Flex is known in the community as one of those “hard core” conferences where the expectation is to leave sessions with your Flex and Flash IQ increased by a couple digits.

Unfortunately until now, James and I have had to experience the conference through other people’s stories.  For some reason or another the last few years have been pretty hectic, but we made it a mission in 2010 to attend and speak at more events, with 360|Flex being the first on the list.

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?

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.

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