boostworthyisryantaylor

Archive for November, 2007

MXML Is The New FLA: Use It For Layout ONLY

November 12th, 2007 | Category: Dirty South, Code

I have been verbally preaching this for some time now, so this blog post is long overdue. As the title suggests, this semi-rant is going to dive down into Flex best practices in regards to layout and placement of code.

MXML Is The New FLA

Whether you realize it or not, MXML is the new FLA. Sure, Flash is still around for you to create animations on the timeline and all of that fun stuff; however MXML is really going to become the format of choice over the next few years. So, why is that? Well it's simple really. FLA is a proprietary file type for the Flash IDE. In order to open and modify a FLA file, you need to have a semi-pricey piece of software installed on your machine. MXML, on the other hand, can be written in any simple text editor and compiled using mxmlc - a compiler which is included in the open-source Flex SDK.

Further more, with MTASC out of the picture for AS3 development, we no longer have the ability to use code injection to update our SWF files once they have been published from the Flash IDE. We could always use hAxe, but that's for a different discussion and not really practicle for mainstream use. MXML eliminates our need for code injection, so we can easily define our layouts and then do batch compiles using Ant if we so choose.

MXML Describes A Layout

Like HTML, MXML describes a layout. Further more, like HTML in Dreamweaver, you can view MXML as code or an actual visual layout inside of Flex Builder. This is another reason why MXML is superior to a FLA file. The point of this post isn't to bash Flash though; I'd be the last person to ever do that. What I am trying to get across is that MXML is the evolution of the FLA. For years now, developers have been using the Flash IDE to layout components on screen and only place code on the first frame of the timeline to initalize the application class. This was deemed as the best practice for many reasons, so shouldn't that be carrying over to the Flex world?

MXML For Layout, Classes For Logic

With all of these comparisons of MXML to FLA files out in the open, let me now jump right to the point. Writing ActionScript inside a MXML document is the equivalent of sticking code all over the timeline in a FLA file. It becomes very difficult to track down why code is not responding as expected in your class files when there is code sitting in a MXML document somewhere that is overriding your functionality. Here is an example of what I am talking about:

GOOD practice: MXML used for layout ONLY. Logic in separate class file.

CODE:
  1. <?xml version="1.0" encoding="utf-8"?>
  2.  
  3. <example:Main xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:example="com.boostworthy.flex.example.*" layout="absolute">
  4.    
  5.     <mx:Button x="65" y="62" label="Example Button" id="exampleButton" />
  6.  
  7. </example:Main>

ActionScript:
  1. package com.boostworthy.flex.example
  2. {
  3.     import flash.events.MouseEvent;
  4.    
  5.     import mx.controls.Button;
  6.     import mx.core.Application;
  7.     import mx.events.FlexEvent;
  8.    
  9.     public class Main extends Application
  10.     {
  11.         public var exampleButton:Button;
  12.        
  13.         public function Main()
  14.         {
  15.             init();
  16.         }
  17.        
  18.         protected function onCreationComplete(event:FlexEvent):void
  19.         {
  20.             build();
  21.         }
  22.        
  23.         protected function onExampleButtonClick(event:MouseEvent):void
  24.         {
  25.             trace("example button clicked!");
  26.         }
  27.        
  28.         protected function init():void
  29.         {
  30.             addEventListener(FlexEvent.CREATION_COMPLETE, onCreationComplete);
  31.         }
  32.        
  33.         protected function build():void
  34.         {
  35.             exampleButton.addEventListener(MouseEvent.CLICK, onExampleButtonClick);
  36.         }
  37.     }
  38. }

Notice how the MXML only describes the view. Beyond positioning and sizing (and the instance name of course), it is also acceptable to set labels. So long as what's in the MXML only describes what you will see, but now how it will work - you are on the right track. Now let's look at an example of what not to do.

BAD practice: MXML that contains layout and ActionScript:

CODE:
  1. <?xml version="1.0" encoding="utf-8"?>
  2.  
  3. <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
  4.    
  5.     <mx:Button x="65" y="62" label="Example Button" id="exampleButton" click="onExampleButtonClick(event)" />
  6.    
  7.     <mx:Script>
  8.         <![CDATA[
  9.             internal function onExampleButtonClick(event:Event):void
  10.             {
  11.                 trace("example button clicked!");
  12.             }
  13.         ]]>
  14.     </mx:Script>
  15.  
  16. </mx:Application>

In some cases, you could even point to an undefined method in a MXML tag and walk away without any compilation errors. Bad bad bad.

This goes for data binding as well. I realize it's convenient to do something like this:

CODE:
  1. <mx:HSlider id="slider" />
  2. <mx:Text id="sliderLabel" text="{slider.value}" />

But that type of approach should be used for quick prototyping only. The better solution is to use BindingUtils inside a class. I know this is all very subjective, but I think I have made some pretty valid points here.

Feel free to share your thoughts on the matter.

13 comments

FOAM: AS3 2D Physics Engine

November 08th, 2007 | Category: Dirty South

A fellow coworker of mine by the name of Drew Cummins recently announced FOAM, a 2D physics engine written in AS3. I haven't had a chance to dive too deeply into his code base yet; however he is presenting it to our group tomorrow at work - I'm very excited about it. Be sure to check it out and leave him some feedback.

1 comment

Astro (FP10) : Typed Arrays And…More?

November 07th, 2007 | Category: Dirty South, Code

I just got word from some people over in Brighton (at Flash On The Beach of course) that Adobe announced support for typed arrays in Astro (Flash Player 10). Yes! I'm pumped about that one. Though it was already public knowledge (see page 13 in the ECMAScript 4 Overview) that this was on it's way to ActionScript in the years to come, I am surprised that they are slipping this into AS3 (rather than AS4). So, how are typed arrays going to work in AS3?

ActionScript:
  1. // Creates a new array in which all elements must be of type String.
  2. new [String]("I am string #1.", "I am string #2.", "I am string #3.");
  3.  
  4. // Same operation as above, but different notation.
  5. ["I am string #1.", "I am string #2.", "I am string #3."]:[String]

Cool right? It gets even better - if Adobe is slipping typed arrays into Astro, what else are they planning on adding to AS3 before making the move to AS4? Here are some previews of what MAY be heading our way (according to the latest draft of ECMAScript 4).

Record Types

Record types are basically property types for generic Objects. Where as with an array you define the type of elements, with a record type you define virtual properties for an Object. That probably doesn't make much sense, so just take a look:

ActionScript:
  1. // Creates a new generic Object with defined 'x', 'y', and 'z' properties, each of type Number.
  2. {x:153, y:62.38, z:100}:{x:Number, y:Number, z:Number}
  3.  
  4. // Taking it one step further, you can define the type for use throughout your code.
  5. type Point3D = {x:Number, y:Number, z:Number}
  6.  
  7. // With the type defined (above), you can use it like so.
  8. var objPoint:Object = new Point3D();
  9. objPoint.x = 153;
  10. objPoint.y = 62.38;
  11. objPoint.z = 100;

You're pumped right? But wait, there's more...

The 'like' Operator

The 'like' operator will compare two types to see if they have anything in common. For instance:

ActionScript:
  1. // Returns 'true' because they both have 'x' and 'y' properties (among other reasons).
  2. someMovieClip like someSprite

Ok, so that one is a no brainer. However, the power of 'like' is that the two objects being compared do not need to share the same base classes or implement the same interfaces. In other words:

ActionScript:
  1. // Returns 'true' because both objects have 'x' and 'y' properties.
  2. someMovieClip like somePoint

That's good stuff and will certainly be useful. Ok, how about one more?

Union Types

Union types allow you to specify more than one acceptable type for an object.

ActionScript:
  1. // Anything typed as Disaster will accept a value that is a Number or String.
  2. type Disaster = (Number, String)

Pretty cool, but I can already see this one being abused.

So anyway, there are some other gems in there as well, but these were the ones that grabbed my attention the most at first glance. Returning to the point of this entire post - will any of these make their way into AS3 next year or will we be waiting *patiently* for AS4?

3 comments

Google Android And The Open Handset Alliance

November 05th, 2007 | Category: Dirty South

The much rumored announcement of Google's operating system for mobile devices finally happened today. The software has been dubbed with the name Android and even has a SDK on the way (November 12th). Equally interesting is the announcement of the Open Handset Alliance - a group which plans on supporting the technology. There are currently 30 or so members of the alliance, including Motorola, Samsung, T-Mobile, Sprint, eBay, Intel, and of course...Google. Guess who isn't on the list........ Apple! It will be really interesting to see where all of this goes. More information is available on Google's blog.

No comments