Ted Patrick > Flex Evangelist > Adobe Systems

While developing IFBIN - Flash by Example, authors provided a 'Hello World' example as a showcase of their perspective on the age old example. In every case, I learned something new from these examples.&

There are literally thousands of ways to solve a particular problem. None of them are right or wrong, they are all just different. The 'Hello World' case study really changed my perspective on the product we were developing. When you ask 20 or so top quality developers for 'Hello World' examples you get some strange emails in return. I know many on the team thought I was crazy but I wanted to see a common problem solved from independent perspectives. The end result continues to amaze me.

The real difference for me came when I was reviewing the examples for approval. I was really shocked to see such varied perspectives on Flash and to find so many different valid techniques for authoring SWF content. It was as if I was allowed to peer over the shoulder of another developer and see how they work. In every case I walked away looking at Flash differently and adding another tool into my solution set. I thought we were making something great, but this altered perspective really drove the value home.

Then Jon Williams posted his 'Hello World' example. Here is the SWF file:

I have yet to see anything so cool as this example. The math and drawing API driven ToolTip class is simply amazing. The code for this is about 3 pages of rock solid hard core AS. Is it any wonder Jon created one of the first frameworks for Flash development, IOLib? I expected allot of things but having this arrive was a real wake-up call as to the core value of the Flash by Example product. Jon, thanks for this fantastic example!

I just enabled the Hello World examples as free content in IFBIN - Flash by Example. Download the IFBIN Service and install these examples for free. Make sure to set aside some time to review these examples, you will be surprised just how much Flash you will learn in a short period of time. I thought I knew allot about Flash but it seems that I still have allot to learn.

Regards,

Ted Patrick

I started a new company 8 months ago and partnered with the best developers in Flash® and Flex® to create a new class of product. IFBIN is about great software examples and great developers. IFBIN Begins...&

http://www.ifbin.com

IFBIN is a code distribution service that provides example software for learning and reuse. It is a desktop application that provides secure access to an ever growing library of software for use in Macromedia® Flash® and Flex®. The examples within the products range from small usage examples to large development frameworks and servers to complete applications.

I would like to thank everyone who has made IFBIN happen. It is a great honor for me to work with such great partners on a project of this scale. To all of our author partners your support has been invaluable and I look forward to working with you on this marathon of a project. Also special thanks to Macromedia® for the internal support needed to make IFBIN happen. On so many levels Macromedia® has really made a profound difference in this project.

Many many examples to go! :)

Enjoy,

Theodore Patrick
IFBIN Founder and CEO

Having worked with Flash since FutureSplash, I have come to some conclusions about how to think about the player during development. Welcome to the elastic racetrack.&

I think about the Flash Player as a racetrack. There are 2 distinct sections of the racetrack, one for executing ActionScript (subsection for event processing) and one for rendering content to screen. While running, the Flash Player loops around this racetrack at a preset speed designated as FPS in the SWF file. At all times the player will attempt to maintain the speed set regardless of what the player is asked to do. The designated FPS is the maximum speed of the racetrack and processing can never go faster than this limit but can go slower.

Player Racetrack


A SWF file tells the player to do certain things at certain times. As the player processes these instructions, the racetrack is stretched in either the ActionScript section or the Rendering section or both. If you are processing lots of data or rendering lots of clips, either half expands to process everything you add in a single loop of the track. The player will not skip over anything that it is asked to do and will always attempt to finish a loop in the least amount of time possible but never faster than the designated FPS.

ActionScript Heavy


Graphics Heavy


ActionScript and Graphics Heavy


There are several additional aspects that compound this model. First off, the player structures graphical elements into a descending tree. Starting at the base node(_leve0), there can be many branches each with frame content and sub nodes/timelines. With every loop of the player all of the elements on the tree must be processed. In the current F7 player, frame content is swept and processed in depth order as needed from the _level0 node. In terms of graphical performance, the key is to keep the tree shallow combined with making elements as simple as they need to be. The fewer items in the tree and the shallower the tree, the faster the graphics will render.

The tree structure also applies to ActionScript bytecode processing. In the AS phase, the tree is swept for bytecode given the tree's current state. Should any events be designated they will be processed in depth order. ActionScript is stack based and thus all bytecode is pushed onto the stack and processed in a linear fashion down the tree. Depending on the volume of code and events on a given frame, the AS portion of the racetrack elongates. As there is no build-in way to defer code execution, the player will process everything that it is asked to process in a given frame loop. It is interesting to note that even code that uses functions and events can be sequenced into a long line of bytecode to be processed. In a sense the player is never lossless, it will always do all the work you ask of it and never defer to a later frame cycle. The key is to never ask the player to do too much on a given frame and to be able to defer logic and events to later frames optionally.

As for Flash 8, from the looks of the beta player, cacheAsBitmap allows the graphics renderer to cache a MovieClip branch as a Bitmap. In caching vector graphics to an to a Bitmap, the renderer does not need to rerender until the graphics have changed (dirty). Ideally this allows the player to focus rendering on different areas of the player and specialize how the vector renderer is utilized. In a tree based rendering model, assuming some branches of the tree are set to branch.cacheAsBitmap=true, the renderer will create a Bitmap on the first pass and reuse this Bitmap until the vector graphicis of this area are marked as dirty. In the same light, if the cacheAsBitmap branch is dirty every frame(animated), you have forced the player to generate a Bitmap (processing + memory) with every frame cycle. In my testing, optimizing using cacheAsBitmap is not as straightforward as it seems.

In summary, the player performance is a combination of 2 distinctly different elements, graphics processing and ActionScript bytecode processing. If you abuse one or both of these aspects the player will slow down to make sure everything is completed before the next cycle. In development of larger projects, the elastic racetrack has helped me explain the logic behind many seemingly strange performance optimizations for Flex and Flash development.

As it has been said many times before, "Just wait a frame!" :)

Cheers,

ted ;)

Rebecca and I are moving to Ankara, Turkey for 3 years. The movers arrived this morning to pack all our belonging in advance of our departure. I knew this was coming but it feels real now.&

Our bags are ready and movers have been packing boxes for shipping all day long. The office is ready to go, the documents are sorted, and I have a big announcement coming this week with the new company. The new office in Ankara got Internet access yesterday and almost everything is ready for our arrival on August 11th. All of our stuff will arrive in Baltimore, MD tomorrow where it will be packed into a container headed for Istanbul by ship. The car goes later this week heading for Turkey.

I am going to miss DC allot, I had a great time here and made some lifelong friends. Darron, Chafic, D.Wolf, and C.Cantrell special thanks for all the Flash/Flex lunches, I will especially miss the technical talks. Those lunches/dinners were far better than any conference I have attended. I learned allot, thanks guys!

So the new business and products are shaping up nicely and initial reviews are looking very favorable. I cannot wait to show you what the team has been working on for the past 6 months. Having the opportunity to work with a team of this quality alone has been an honor. In 3 days time, you will know what I am talking about. There is nothing like a great example! :)

More to come.

Ted ;)

I wrote this Central app a while ago but never publicly released it. It allows you to edit the SWF version header cross-platform using FileIO. Simply insert a SWF file and change the version number and save the new SWF.


Cheers,

ted ;)

Did anyone else catch the beta installation process? It used the Flash installer technology to upgrade the player within itself. This is a really big deal!&

It looks like for the first time in Flash history, we are going to see the existing 6 & 7 generations players install the Flash 8 player directly. Starting with Flash Player 6, Macromedia included a cross browser/cross platform installation technology with a light ActionScript API in System.product. This API was used to install Central and Breeze to the local machine securely. This process has been battle tested with Central and Breeze and now this technology is turning towards the Flash Player itself.

The question lurking in my mind is how much faster are we going to get to 80% installed? If I had to guess, I believe that combined with player to player installation and the previewed feature set, we could cross 80% in 6 months.

I am really fired up about "The Ocho"!

Cheers,

ted ;)

I have been a huge fan of Alex Bradley's work on KineticFusion. This round trip SWF to XML compiler/decompiler is an amazing product and keeps getting better. Version 3 is worth a deeper look. Actually with this release the product makes the leap to a productive XML development tool. Prior to this the XML was very verbose and supported the entire low level SWF format. With version 3 you can create higher level XML with event support and MXML like functionality.

http://www.kinesissoftware.com/index.php

Nice work Alex, KF has come a long way!

Cheers,

Ted :)

I have had trouble with 'import' with Flash and Flex in larger projects. I have witnessed time and time again small quirks in 'import' that can wreck a project in later development.&

'import' is very useful and in 95% of cases works as intended. The problem is that import changes the compiler scope when classes are imported. If you are not careful about the end class name, your class names can collide with local variables, global classes and other classes. When you are using multiple packages, you must make sure the combined classes do not have naming issues less you instantiate the wrong class or overwrite something unintentional.

So is there another option? YES! There is a very simple way to get classes, subclasses and super classes into your application. The Flash and Flex compiler looks for class paths during compilation. If there is a match to a class, the class will be added into the application automatically.

Example Code

Say I have 3 classes in a package called 'com.dog'. Listing the classes I wanted to import works like so:

com.dog.Frog;
com.dog.Cog;
com.dog.Log;

trace(com.dog.Log.name); //Log
trace(com.dog.Cog.name); //Cog
trace(com.dog.Frog.name); //Frog

//these classes are not used in the compiler scope so they fail as expected.

trace(Log.name); //undefined
trace(Cog.name); //undefined
trace(Frog.name); //undefined

Using import I could do this:

import com.dog.*

trace(com.dog.Log.name); //Log
trace(com.dog.Cog.name); //Cog
trace(com.dog.Frog.name); //Frog

trace(Log.name); // Log
trace(Cog.name); // Cog
trace(Frog.name); // Frog

The real difference is scope pollution. If you use too many imports, you are almost assured to run into problems if you are not careful with class naming.

Another issue here is that Flash MX 2004 has a compiler bug that prevents the automatic import of super classes on occasion. The bug can be easily averted in listing the super class without the import statement.

Just to be clear, I use 'import' in my projects. I understand what it does and know the quirks. That said, simply listing the path to your class is valid and works well too.

Cheers,

ted ;)

I got shared libraries working today with Flex and found some interesting tidbits.&

1. They are very easy to use. Just create a "common.sws" file and denote the tags you want in the shared library. The only change to your MXML file is to denote rsl="common.sws" in the mx:Application tag. Within the common.sws file in the 'library' root tag you can denote the url='/common.swf' as for the runtime location of the shared library. There are also additional options.

2. When you compile your MXML several things happen in regard to RSLs.

a. The RSL URL is embedded into your base SWF. When your MXML SWF file is loaded it will load the URL as a shared library.

b. The Flex server has hooks into compc for creating SWC RSL SWF files on the fly. To create an RSL from an sws file, simply add "swc.swf" to the end of the base name of your .sws file. Here is an example:

common.sws - SWS file denoting Components and RSL URL.
common.swc.swf - Returns the RSL SWF to be saved to the RSL URL location.

3. So if you want to use Shared Libraries without the Flex server, you can simply download the following URLS:

http://myFlexServer/flex/myapp/myapp.mxml.swf
http://myFlexServer/flex/myapp/common.swc.swf

Place these files on any server in the correct path based on the sws url path and you are good to go!

As Darron is sure to post in this entry, you can also use compc to generate RSL SWF files from an SWS file.

Cheers,

ted ;)

When I was exploring MovieClip depth management, I ran into a quirk in the Flash player. It seems that depths are negative for timeline content and positive for assets added dynamically (attachMovie,createChild,etc).&

So how do you remove content added on the timeline?

First you need to move it to a positive depth and then delete it. removeMovieClip only works with positive depth up to a high range.

myTimelineContent.swapDepths(10000) //yes you can pass a # depth ;)
myTimelineContent.removeMovieClip()

What is interesting with Timeline content is that you begin to see how keyframes are actually implemented. A Keyframe at runtime is a unique asset at a negative depth, the stacking order correlates to the layers in the Timeline view in Flash but depths are assigned dynamically from -16383 and higher. When the player overwrites a depth, the content is replaced making what seems to be a seamless transition to the next frame..

What gets really interesting is that you can pop keyframes to a higher depth and the frames are not overwritten by new keyframes. This was very enlightening for me when I first discovered this quirk. Actually in looking at duplicateMovieClip, it makes sense to see that this copies content of one depth to another where attachMovie adds a library asset directly to a depth.

Ahhh low level flash, nothing like understanding what the player is actually doing at runtime.

Cheers and happy 4th!

Ted ;)

HTTPService is a very powerful tag in MXML. I overlooked it for a while until I found some tricks to using it. Here is my list:&

1. HTTPService processes the data returned.

If you load XML using HTTPService, by default it will return an object heirachy even when useProxy='false'. Once the data had returned you can use dot notation to retrieve nodes by name.

myXMLService.result.frog.dog.blog

A handy use of this is to set dataProviders directly. Using any List based control, you can set the dataProvider from an XML file. This is super handy given with one HTTPService XML request and setting one variable you can add complex data into a control.

Warning: There is a gotcha in here. When XML is parsed to Object, similar node names at the same level are turned into an array. To access nodes of a common name you use name[1]. The problem is that names do not become nested unless there is more than one. If you set dataProvider values this way, when 1 element is set, it will mess-up. Although you can filter for this using the length property, it will be undefined when there is only 1 node.

There are some other formats supported but I have yet to explore them. You can set the HTTPService.resultFormat property to either "object" (the default!), "xml" , "flashvars" or "text". Depending on what your doing these can be very useful.

2. Use Databinding with the URL property.

This one is really handy and can dynamically generate GET URLS for you based on local variables.

<mx:HTTPService id="documentService" useProxy="false" url="{ 'http://server/' + docPath + '/data.xml' }" result="documentData=documentService.result" />

This defines the documentService. When documentService.send() is called, the URL is calculated based on the current value of docPath and the request is made. When data returns, the returned object is saved to the variable 'documentData'.

In using this, I would do this a ton:

docPath = "frog/dog"
documentService.send()


3. Caching data between requests.

<mx:HTTPService id="documentService" useProxy="false" url="{ 'http://server/document.cfm?id='+ docID }" result="documentCache[docID]=documentService.result;documentServiceResult()" />

In this case, I use a variable called docID to vary the data returned from the HTTPService. With each request, I save a local copy according to the docID value. When calling this I use the following code:

if( documentCache[docID] == undefined or ){
documentService.send()
}else{
documentServiceResult()
}

Instead of retrieving the data every time from the server, this only fetches the data once and caches it inside the player locally. Subsequent requests are pulled form the local cache.

4. useProxy='false'

This is a big deal since it allows Flash to use the players security model for loading data from another server. Just add a crossdomain.xml security file to the root of all servers you want to access and you can exchange data with another domain. Here is a sample crossdomain.xml file:

http://www.macromedia.com/crossdomain.xml

http://www.yahoo.com/crossdomain.xml

As I dig deeper into the practical side of Flex development, I will post some more.

Using these you can exchange data with the best of them!

Cheers,

ted ;)