Archive for the 'Flex' Category

Introduction to MXML

If you’re here because you’ve just heard about MXML for the first time and have NO clue what it is, you should start by reading Wikipedia’s MXML article.

Some Background
MXML is an XML-based language that is functionally equivalent to ActionScript. When MXMLC compiles MXML, first it translates it to ActionScript, then compiles that ActionScript into bytecode. In fact, if you pass the -compiler.keep-generated-actionscript argument to MXMLC, you can actually see the ActionScript that is generated from your MXML class. There’s a common misconception that using MXML requires using the Flex Framework, or that Flex is MXML and vice versa. Those are not true. MXML is a declarative language, like HTML. Flex is Adobe’s UI component framework. The two are not dependent on each other, which the South Park project demonstrates.
MXML in a Nutshell

Here’s an example of a default MXML file, which we’ll examine below:

<?xml version=”1.0″ encoding=”utf-8″?>

<s:Application

xmlns:fx=”http://ns.adobe.com/mxml/2009 xmlns:s=”library://ns.adobe.com/flex/spark

xmlns:mx=”library://ns.adobe.com/flex/mx

minWidth=”955” minHeight=”600>

<fx:Declarations>

<!– Place non-visual elements (e.g., services, value objects) here –>

</fx:Declarations>

</s:Application>

Doctype Declaration

<?xml version=”1.0″ encoding=”utf-8″?>

The first line is required for all XML documents. It’s not unique to MXML and is essentially telling any parsers that read this file what to expect. You can basically take it for granted and not have to worry about it as long as you’re creating and working with MXML files within Flash Builder. If you’re using another editor, just make sure that you’re saving your files using utf-8 or you’ll run into nasty compilation problems.

Root Node

<s:Application minWidth="955" minHeight="600">

...

</s:Application>

There can only be 1 root node of any MXML document, and all other nodes must be contained by the root node. You can’t have 2 top level nodes in an MXML file, just like you can’t have 2 public classes in a single ActionScript class file. Also, the root node is normally a DisplayObjectContainer so you can place DisplayObjects within it. You could potentially create non-visual classes/components in MXML, but MXML’s strengths are laying out UI elements and rigging up event handling, so you would probably be better off using ActionScript in that case.

Namespace Declarations

xmlns:fx="http://ns.adobe.com/mxml/2009"

xmlns:bd="com.bdement.*"

Namespace declarations are equivalent to import statements in ActionScript, but they are a special attribute that must be present in the root node. The default namespace is http://ns.adobe.com/mxml/2009, which is required to make MXML “work,” regardless of whether you’re using the Flex Framework or not. xmlns:fx means “use a namespace called ‘fx,’” which lets you write tags that begin with <fx: and gives you access to all of the classes within that namespace. You can also import any package as a namespace by specifying it like the 2nd example.

The actual namespace (fx or mtvn, in the above lines) is arbitrary. For example, in the 2nd line I used “bd” as my namespace, but I could name it anything. Namespaces aren’t globally defined, so you can change them from class to class, although as a best practice you should name them consistently throughout your project.

Nodes

Every element within an (M)XML document is known as a node. Nodes are equivalent to declarations in ActionScript. Every time you specify a node like <ns:Object />, the resulting ActionScript will look like “new Object().”
Attributes

MXML gives you access to all of the public attributes exposed by a class. They’re set by declaring a value for them in MXML, like this:

<s:Application width="955" height="600">


This is the functional equivalent to the following ActionScript:
var myApp:Application = new Application();
myApp.width = 955;
myApp.height = 600;

Even in this simple example you can already see how MXML’s declarative structure is well-suited for “declaring” UI layouts.

Dynamic Attributes

Often you’ll want a particular value to change at runtime, and for that change to have some kind of effect on your UI. For example, a label that changes text when you click something.
To specify a dynamic attribute, wrap a reference to it in curly braces, as shown here:
<fx:Declarations> <fx:String id=”labelText>My Label</fx:String>

</fx:Declarations>

<s:Label text=”{labelText}/>

In this example we declared a String called “labelText,” and a Label that uses labelText’s value. The String is wrapped in a “Declarations” tag because it’s a non-visual element. All properties declared like this are given a public scope and are “bindable.” We’ll discuss more about data binding below.
As an alternative, you could also specify properties in script:

<fx:Script>

<![CDATA[

[Bindable(event="labelChanged")]

private var labelText:String = "My Label";

]]>

</fx:Script>

<s:Label text="{labelText}"/>

Here you’ll notice that instead of a Declarations tag, we used a Script tag, which contains a CDATA enclosure. The CDATA enclosure tells the MXML parser that content within the enclosure is “character data,” and will not follow (M)XML syntax.
The [Bindable] metadata tag means that the next property is available for data binding. Data binding is a handy, but often misused feature in MXML. For complete information on data binding, read Adobe’s Bindable Metatag Documentation.
Key Point: The key thing to know about data binding is that when you write a [Bindable] tag, always, 100% of the time, include a unique event name. If you don’t, your performance when using data binding will get really bad, really fast.
The reason is that if you don’t supply an event name, it defaults to “propertyChanged.” Then every time a property changes, Flash has to figure out which property changed, which becomes more expensive as you have more properties that are all dispatching that event. Also, if you view the ActionScript files generated from your MXML classes you can actually see how vastly different the generated code is when you do and don’t supply a property name.

Event Handlers

Event Handlers are specified in MXML very similarly to how attributes are specified, except they refer to a function rather than a property. For example:

<fx:Script>

<![CDATA[

protected function button1_clickHandler(event:MouseEvent):void

{

trace("Clicked!");

}

]]>

</fx:Script>

<s:Button id="button1" click="button1_clickHandler(event)"/>

You can probably see the connection pretty easily here, but notice that there are no curly braces in this case. Also notice that the magic variable “event” is being passed to the handler. “Event” is the naming convention used in MXML for the event that will be passed to your event handling function. You could also write event handlers like this, although I do not advocate it in all but the most trivial programs, I’m only showing this as a reference to show how the magic “event” comes out of nowhere:
<s:Button click="trace(event.type)"/>

FITC San Francisco

FITC held it’s first ever event in San Francisco last week where they brought together some of the most creative and innovative minds from Flash’s design and development communities.  I had heard about previous FITC events and their increasing reputation for great speakers, educational sessions, and never-before-seen demos experiments, so when I heard they were coming to my new home, San Francisco, I have to admit I got a little giddy.
They sent out an early call for volunteers which I jumped on in a heartbeat.  Being a volunteer was a no-brainer for me, it saved a ton of money and for just a little bit of my time I got access to most of the sessions as well as an inside look into how FITC works and what it takes to put it together.  I met several of the FITC staff and chatted with them about their jobs of putting on these events all across the world.  It’s an impressive feat for them to orchestrate so many moving parts remotely, fly to a new city and have them all fall into place, then turn and do it all over again just a couple months later in another new city!  I also thought it was really funny how all these Canadians were caught totally by surprise by San Francisco’s chilly Summer weather, it was warmer in most parts of Canada than it was in SF!
I went to several sessions including the Adobe Keynote with Kevin Lynch, Flex 4 Lifecycle Best Practices with Aaron Pedersen & James Polanco, and High Performance Mobile Content with Flash with Mike Chambers
The Adobe Keynote was great and renewed my confidence that Flash is and will be an integral part of the Internet for a long time to come.  For example, cell handset makers are starting to advertise that their devices support Flash, even putting the Flash Player logo on their packaging.  I also asked Kevin Lynch a question that has been burning in my mind for a while about the capabilities of CS5’s Device Central.  His answer was really, really impressive.  Normally you would expect the first iteration of a major feature like Device Central to be somewhat underwhelming, but not so in this case, just a few of the features are:
  • Simulation of all input types and layouts – In Device Central you can see a little picture of the actual device your testing and play with each and every one of the buttons and input controls it suppors
  • Memory and CPU Simulation – What’s more important on a mobile device than performance?  (See below!)  Device Central actually simulates the capabilities of the device you’re testing to let you know how your content will do.
  • Radio interference – Kevin told a story about how some developers were actually taking test devices into elevators to test how their application performs with degraded reception, so they built this into Device Central!
  • Screen glareWhaaaat? Does your application have enough contrast to be seen when the device is being used outdoors?  Device Central can help you find out.

Device Central is powerful, but no tool can guarantee that your app will work as designed in real world scenarios, so don’t forget to test yourself, on a real device, because as we all know: ain’t nothing like the real thing, baby.

And finally, I attended Mike Chambers’ session on mobile application performance.  I was going in hopes of picking up tips to apply to my day job as a game developer, and I wasn’t disappointed, as most of Mike’s tips could be applied to virtually any application, but is especially important when running in under-powered mobile environments.  Here are my Cliff’s notes:
  • Air 2.5 beta open – Open to anyone who registers.  Repurposes most of the work done for iPhone development and applies it to Android.
  • Bit.ly/as3performance – Grant Skinner’s performance testing framework
  • Github.com/MikeChambers – Mike Chambers’ Simple Game Framework, a set of utility classes to perform various game related functions like a Centralized Game Loop, Object Pooling, Caching, etc.
  • Mobile support coming to next version of Flash Builder (don’t know any details of what this means)
  • ALL vector rendering in AIR 2.5 is done via the GPU, which improves performance on all devices and improves battery life on mobile devices
  • All vectors on stage are rendered, regardless of screen position.  i.e. If you move an object off-screen, it is still iterated over in the rendering phase, wasting resources.  To improve this, set visible = false.
  • A new property called “cacheAsBitmapMatrix” is now available in AIR 2.5, and will be available in the Flash Player in a near release.  Right now when you set cacheAsBitmap=true, and then scale or rotate the bitmap, it has to be redrawn.  By setting the cacheAsBitmapMatrix to a matrix (usually just the identity matrix), you enable bitmap caching and greatly increase the performance of any redraws that occur.
  • Performance tip:  Do anything you can to prevent redraws (check the redraw regions to figure out what’s being redrawn).  Things that force redraws are: Using the drawing API, changing/moving an object or it’s children, removing an object/child, or occluding non-cached objects.
  • Setting Array/vector.length = 0 is faster than setting array/vector = new Array/Vector
  • Object instantiation is very expensive, so instead of disposing objects, you can put them back in the pool and reuse them later.
  • Mouse events are cheaper than touch events on mobile devices, and single finger touch events are automatically translated to mouse events.  You should use these mouse events instead of the touch events to improve performance.
  • Avoid using mouse move which is fired really, REALLY fast, and can cause lots of extra calculations that are made but go unused between frames.  Instead, do your updates at the framerate by using ENTER_FRAME
  • In certain areas where performance is super-important, consider using callbacks rather than events. Event objects have to be created and propagated, which is expensive.
  • If you’re listening to an object that is deeply-nested in the display list, stop its propagation
  • Bytearray.org/?p=1363 – A whitepaper called “Optimizing Performance for the ADOBE® FLASH® PLATFORM” (attached), this is the single greatest resource for performance tweaks I’ve ever come across.  It validates a lot of the techniques I’m already applying for game development, and points out a few others to consider.

All in all, the 1st annual FITC SF was a resounding success, and you can bet I’ll be back next year!

Flex Formatter Plugin

Code formatting is the reason for many a jihad between developers all over, and spending any time at all discussing it is a waste of time.  (So should I stop writing here?  No!  There is an answer!  Press on…)  Unfortunately this is one issue where it’s impossible to make everyone happy, so you have to settle for making everyone equally UNhappy.

A really painless way to do make everyone equally unhappy is to automate the formatting, and that’s where the amazing little gadget, the Flex Formatter plugin for Flex and Flash Builder comes in.

The plugin adds a few buttons to the toolbar area of Flex Builder.  These buttons are:

  • Generate ASDoc Comments – For your whole file!  In one click!
  • Generate ASDoc Comment – For one item (also in one click!)
  • Format Flex Code – Formats your entire MXML file (or selected lines) ….with one click
  • Indent Flex Code – Not sure why you’d use this and not just the previous button, it seems to do the same thing
  • Rearrange AS Code – Same as Format Flex Code, but for your AS files

To install it, go to “Help, Software Updates, Find and Install” and install from the new remote site:

http://flexformatter.googlecode.com/svn/trunk/FlexFormatter/FlexPrettyPrintCommandUpdateSite/

Grant Skinner has a nice post on this, as well as a settings file that he has exported for use: http://www.gskinner.com/blog/archives/2009/12/indispensable_p.html

FlexPMD

You probably haven’t heard about FlexPMD.  It’s an open source plugin from Adobe for Flex or Flash Builder.  You run it against your source code and it alerts you to “bad smells,” or potential bad practices, in your code.  These types of tools, from FlexPMD’s older brother, PMD from the Java world, and “Lint” from the C world have been around for a long time, checking over the shoulders of developers, and frustrating computer science students who are required to compile with no lint warnings.  (All my programming homework in college had this requirement, ugh!)

I ran FlexPMD against the source code for brandondement.com and was really impressed with the results.  Some of the results were of the “I don’t care about that” variety, but Flex PMD can be configured to ignore those, and many more were in the “Oh really?  You’re right!” category.  I’ve only just begun to use it, but even then I would highly recommend it for anyone who’s committed to becoming a better programmer.  More information about installation and use can be found at:

http://opensource.adobe.com/wiki/display/flexpmd/FlexPMD+Eclipse+plugin