To expand our Flash Platform team, we are now looking for an experienced Action Script developer.

We require:

• experience in creating Flash applications / games
• strong knowledge of Action Script 3.0
• knowledge of Flash Builder and Flash Professional
• understanding of OOP and basic design patterns
• willingness to develop one’s skills
• motivated approach to work 

 We prefer:

• knowledge of Flex / AIR technologies
• knowledge of AS physics or 3D engines (such as Box 2D or Away 3D)
• knowledge of areas such as video- and audio-streaming or 3D
• experience in web technologies (HTML, CSS a Ajax) and graphics tools
• experience in development for mobile and devices

We offer:

• exciting work on online community games for millions of users
• work with new technologies
• new experiences, professional growth
• work in a fast developing perspective company
• attractive salary
• floating work hours
• work in a young team with informal atmosphere

If you are interested in the above position, please send us your CV and portfolio / examples of your work to jobs@geewa.com. 

Have you ever run your swf in other wmode than window? If so, you might have experienced the same troubles as we did in our Virtual elections Facebook application. All the problems arose from the seemingly unimportant decision – as we needed to pop up Facebook dialogs (such as Invite Friends or Publish to Wall) over the Flash movie, we decided to switch the swf’s wmode parameter to opaque. While testing the application, we then came across the following two (and pretty annoying) bugs:

Corrupted local characters in text inputs

This an old and well known bug. In the demo above, try to type a Czech word “žluťoučký” (you need a Czech keyboard for it). What you get (or at least what I get) is “~lueouký” in Firefox 3.5 / IE 8 and žlu´toučký” in Chrome 3 / Safari 4 / Opera 10 (I’m testing on Windows XP). There are several workarounds for this bug:

• swfInputs displays an overlaying HTML input field above the Flash text field and passes the captured key strokes to the Flash movie via JavaScript.
• JSTextReader is another JavaScript-based solution – the difference is that JavaScript is only used for listening to the keystroke events and transferring the correct chars into Flash (i.e. no overlaying HTML input filed is used).
• Nicolas Cynober’s workaround is in my opinion the most decent one. It’s almost a pure ActionScript solution – the keystrokes are captured directly on the Flex TextInput / TextArea components through the TextEvent.TEXT_INPUT event. Using the event.preventDefault()method, the event handler “swallows” the corrupted characters and replaces them by the correct ones. Of course, for this solution to work, you have to provide it with a class that maps the wrong characters (or their codes) to the right ones. JavaScritpt is in this case only used to detect client’s browser.

For our purposes, the last mentioned approach was the most suitable, although not perfect (some characters may still be corrupted based on browser and platform). I had to create the Czech keyboard mapping and it was a tricky task because unlike other languages, the Czech keyboard does not work even in MSIE. So I’ve written two mapping classes: PTCzechKeyboard_MSIE_Firefox (supports MSIE + FIrefox) and PTCzechKeyboard (supports all other browsers). You can check the result here (feel free to use the source code attached to the demo):

Mouse wheel not working (Firefox / Chrome / Safari / Opera)

Maybe not that critical as the text inputs bug but still quite unpleasant, as it significantly reduces usability of Flash applications. In the opaque / transparent wmode movies, the MouseEvent.MOUSE_WHEEL event not dispatched (except for Internet Explorer). As the result, all the scroll bars can only be controlled by dragging the thumb or pressing the arrow buttons, which is not really comfortable. Although there is a workaround available for this bug too, in our Virtual elections project we decided to ignore this issue because of the budget constraints.

Let’s hope Adobe is going to address both bugs in the future Flash Player releases. In the days of hybrid AJAX – Flash applications, using opaque or transparent wmode becomes a necessity, so if you find the described bugs as serious as we do, please vote for them (FP-501 and FP-289) in the Adobe Bug System.

When working on our avatar project, I recently faced a tricky problem: since we use some Flash Player 10 features (such as PixelBender filters), we had to target our swf to Flash Player 10. On the other hand, we still do not want to force our users to install Flash Player 10. The decision was obvious: to make our application backward compatible – wherever we use a FP10 feature, we would also provide a simplified FP9 workaround.

My first approach to handle this backward compatibility issue was quite straightforward. I simply created a method that tests if the movie runs in Flash Player 10:

public static function isFlashPlayer10(): Boolean

{

      var regExp: RegExp = /( )(?P<fpVersion>\d*)(,)/;

      var fpVersion: int = int(regExp.exec(Capabilities.version).fpVersion);

      return fpVersion >= 10;

}

And then I assumed, that the following code would solve my problem:

if (Utils.isFlashPlayer10())

{

//fp10 implementation goes here …

var shader: Shader = new Shader(new BendShader());

}    

else

{

//fp9 workaround goes here …

}

However, when I ran this movie in Flash Player 9, the player has thrown this exception:

VerifyError: Error #1014: Classflash.display::Shader could not be found.

After some research I’ve found the solution: if you don’t want your FP10 movie to crash in Flash Player 9, you have to put to all the FP10 functionality into a separate class, e.g. UtilsFp10(), so that no references to FP10 classes (such as Shader or ShaderFilter) occur anywhere else in your code. Referencing the UtilsFp10() class itself then causes no problems (although just for sure it’s wise to wrap the UtilsFp10() method calls into a try-catch block).

if (Utils.isFlashPlayer10())

{

//fp10 implementation goes here …

try

{

UtilsFp10.playPixelBenderEffect();

      }

catch (err: Error) {};

}    

else

{

//fp9 workaround goes here …

}

Part 1: ActionScript projects

When developing graphic intensive applications, many Flash developers combine the two main Flash Platform building tools – Flash Pro and Flex Builder. As the artwork or animations reach a certain level of complexity, it’s usually more efficient and flexible to prepare the visual assets in Flash rather than writing them in ActionScript using the drawing API or a tweening library.

This series is not going to be a how-to-do tutorial, I’d rather like to share with you some of the experiences we’ve gathered in Geewa over the years by developing our games and other applications for our game portal. In the first part of the series, we’ll focus on ActionScript projects (i.e. projects that do not use the Flex framework).

SWC vs. Embed vs. Runtime Loading

Before we dive into the SWC world, let me just quickly compare this technique to the other two options we have when want to deliver Flash assets into Flex Builder – embed and runtime loading.

I should say I can only think of disadvantages when thinking about embed:

·        Above all, the embedded assets can not contain any ActionScript – so it’s not even possible to stop a timeline animation or dispatch an event from the asset.

·        There is no code hinting for the embedded assets. With the SWCs you can by contrast use code hinting not only when instantiating the classes associated with the graphic assets, but also to reference the asset’s first-level children, as long as you have the “Automatically declare stage instances” option in the Flash Pro’s Advanced ActionScript Settings checked.

For highly expressive RIAs, runtime loading of graphic assets may be necessary, since the application would be too large if all the graphics was compiled into one swf. However, even in this case I recommend to use an externally linked SWC. Letting the compiler know about the classes you work with will surely save you from many typos.

Ways to Implement SWC  Assets

Although they seem to be identical, the buttons in the above demo demonstrate three different approaches to create ActionScript components based on the SWC assets. Consider these methods just as model samples – in a real world application you can of course arbitrarily combine the described techniques.You can download the demo source files here.

Method 1 (Green) – Asset Class Extends Component Class

This approach uses inheritance to combine the asset class (i.e. the class associated with the graphic asset) with the component class (i.e. the scripted class that implements the actual logic of the button). It basically consists of the following three steps:

1. In Flex Builder, write your component class (ButtonV1Base) as a subclass of either MovieClip or Sprite.

2. Switch to Flash CS4 and create the corresponding movie clip symbol, associate it with the asset class (ButtonV1) while setting the component class (ButtonV1Base) as the base class.

3. Return to Flex Builder and you are ready to use the button by instantiating the ButtonV1 class.

Method 1 does not use any drawing API, all the graphics is created in Flash. The timeline of the button asset has three frames that represent states of the button (up, over and down). And here is where the things get complicated. In the ActionScript 2 the gotoAndStop()method was perfectly synchronous – after you’ve called it, you got immediate access to the children defined on the target frame. Unfortunately, this is no more true in AS3. In my sample, the movie clip called “pattern” only exists on frames “over” and “down”. The problem is that after you move the playhead from the “up” state to the “over” state, you need to apply color to the pattern clip. However, after calling the gotoAndStop() method, the reference to the pattern clip is not yet available. I’ve tried several workarounds including the ADDED, ENTER_FRAME or RENDER events, but none of these really helped. Try to move the mouse quickly over the green button and you’ll notice that the ADED event (that I eventually used) sometimes comes too late and the  pattern clip thus retains its original black color. The only hack that works (see the blue button) is to hide the pattern clip in Flash authoring by setting its alpha to 0 and then make it visible by ActionScript only after the appropriate color has been applied.

Method 2 (Blue) – Component Class Extends Asset Class

Method 2 is almost the same as Method 1, only the inheritance relationship is reversed:

1. We first create the movie clip symbol in Flash and associate with the asset class  ButtonV2Asset.

2. In Flex Builder, we write the component class ButtonV2 that extends ButtonV2Asset.

3. The ButtonV2 classis ready to be instantiated by ActionScript.

Depending on the specific needs of your project, both methods have their pros and cons:

·        Method 2 is easier to set up – Flash Pro does not have to know the source path of your project since your asset class only extends MovieClip or Sprite.

·        With Method 2, you can rely on code hinting when referencing your component’s first level children, because the asset class automatically generates public properties referencing each named child.

·        On the other hand, by using Method 1 you can instantiate your components not only programmatically but also graphically, which allows you to create containers or even the whole UI of your application in Flash (see the Panel class in the attached demo).

Method 3 (Orange) –Asset Classes Used via Composition

In this method, the component is rather scripted than drawn. Only those assets, that are easier to design in Flash (such as the Pattern and TextFieldContainer in our sample) are created there and then programmatically instantiated by the component class ButtonV3. Other button assets, such as the background or pattern clip mask, are written in ActionScript. The states of the button are based on adding or removing children and redrawing the background. This enables us to elegantly work around the asynchronous gotoAndStop() problem.

Summary

Methods 1 and 2 are better suited to smaller applications or prototypes – components made using these methods are generally less optimized than components based on Method 3, because they usually compose of MovieClips instead of much lighter Shapes. By contrast, Methods 1 and 2 may be more effective, as designing a component in Flash (assumed that you are familiar with it) is often quicker than writing it in ActionScript.

FlexFlashIntegration_AS.zip (146.25 kb)