23
Feb

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: "<sup>1</sup> The client wants a disclaimer here." looks like:

1 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

Looking around I found two solutions. The first is fairly old (2007/2008) and uses a combination of some regular expression magic to convert <sup> and <sub> tags into HTML <font> tags. The solution next used an extra set of embedded fonts that were created for superscirpt and subscript. Here is the  blog post for reference. 

This solution is a reasonable but requires the process of embedding two extra fonts into the application to get the desired result. 

The second approach was to use the Text Layout Framework (TLF) in Flex 4 and take advantage of the baselineShift property to create subscript and superscript text. See this Adobe blog for reference. 

read more...
22
Nov

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():

read more...
28
Sep

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.

read more...
24
Nov

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?

read more...
23
Oct

In part one of the Flash Player Internals recap we covered how the player is built, in part two we talked about how the player infrastructure works, in part three we examined how ActionScript and the Virtual Machine (VM) are improving in Flash Player 10.1.  Now, in the final segment (looking at my notes this will be the longest segment) we will look at how the Flash Player rendering system is being improved and how you can leverage it for multiple devices.

Shake Your Movie-maker

One of the biggest changes in player 10.1 is that all video will now be GPU decoded.  This is huge for you video buffs out there because GPU decoding is sick fast and allows lower power devices, like netbooks, to play 1080p video smoothly and efficiently.  In the current player, video is decoded using a software based decoder (except in fullscreen, when GPU may be used, but not guaranteed) which is fine when you are on a big 8 core beast, but little machines just can't handle the data.

Now, with a change this big there has to be a few caveats.  Well, there is.  First, your GPU has to support H.264 decoding in the chipset.  If your GPU (ex: video card) doesn't support that, then you are out of luck and the Player will fall back to software decoding.  Next, your GPU and GPU drivers have to be certified for the Player to use it.  If you have an older driver that is not certified it won't matter if your chipset supports H.264 or not, the Player won't leverage it.

read more...
22
Oct

In part one of the Flash Player Internals recap we covered how the player is built, for part two we talked about how the player infrastructure works.  In part three, we will examine how ActionScript and the Virtual Machine (VM) are improving in Flash Player 10.1.

What's New, Player-cat?

First off, Lee announced that the ActionScript VM has been updated to use the newest version of nanojit, which is the same VM backend that is used by Firefox 3.5.  This is an important update not only for performance, but because it supports many different processors.  Processor support is critical when you are looking to run the VM on as many devices and platforms as possible and nanojit helps the Player team do this.

The Player now has a much improved internal String class.  Strings have always been a bit of a bottle neck in Flash and the player team has updated the new class to allow better caching, faster string comparison, and most importantly lower memory usage.  This kind of low level update is great because it improves how our applications run without having to change a line of code.  Of course, you need to republish existing applications for 10.1 when it comes out (recall how the player versions SWFs), but the gains should be worth it.

On the memory front, the Player team has spent a lot of time focusing on how to use less of it more efficiently.  The first step they took is to have the VM take up less of a memory footprint.  Lee didn't get into any details but I would assume nanojit helped with this.  The other area they looked at was Garbage Collection (GC) and how it could be tuned for mobile devices.  What they have found is that memory usage has dropped anywhere from 10-50% for existing applications.  The GC tuning wasn't the sole update for this huge improvement, we will look at some other updates in part four, but this was a big one.

read more...
21
Oct

In the first part of our series we discussed how the player code base is being unified and how that will impact future development on the Flash platform.  In part two, we will dive into the infrastructure of the Flash Player and how this affects us as developers.

Understanding The Execution Model

The execution model is all about how the Flash player performs its actions every cycle (i.e. frame).  The first thing is that the Flash Player is actually extremely multi-threaded under the hood, its just not exposed to developers.  This means that conceptually we have to look at the player as single-threaded.  There is a huge debate about the benefits/limitations of this concept, one that I am not going to even try to comment on in this post.  For now, this is the way the player works... 'nuff said.

Lee's explanation of the execution model is pretty much a recap of what has been said in the past, so read up on the 2007 presentation here and also check out how the elastic racetrack model works.

read more...
20
Oct

For the last three years I have attended the Adobe MAX session put on by Lee Thomason and Jim Corbett called "Flash Player Internals".  This is by far my favorite MAX session, because its extremely advanced, fast paced and they cover as much of the player's architecture as possible.  This year at the Adobe MAX 2009 conference, Jim was not able to join Lee for the session.  Its unfortunate because Jim and Lee's interplay is half the fun, but Lee is a great speaker and he handled covering the entire session like pro.

For the 2007 session, I wrote a huge recap article because they covered the first version of the player to support ActionScript 3.  This player changed how the virtual machine (VM) worked and they showed all kinds of tips and tricks based on the VM's architecture. You can read my previous posts over at my personal blog, VivisectingMedia. The write-up is a multi-part series that starts off covering the player teams motto about not breaking the web.  I skipped writing about 2008, mainly because we where just too busy starting DevelopmentArc, prepping for MAX Europe and the impeding holidays.

Now that MAX 2009 is all wrapped up its time to write up a multi-part series that recaps all the new topics that Lee delved into.  This round, Lee looked at all the upcoming changes in Flash Player 10.1 and I feel taking the time to research and write the posts are worth the effort.  You can watch Lee's session over at the MAX video site and if you have any questions or comments please send them our way.

read more...
21
May

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.

read more...
27
Apr

Package Name Conflicts

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.

read more...