How not to code Flex Applications

Jeff Tapperjtapper@digitalprimates.netDigital Primates IT Consulting

Tips and Tricks to keep you from being fired, or fed to the lions.

Who Am I Jeff Tapper (jtapper@digitalprimates.net) Senior Consultant – Digital Primates IT Consulting Group Building Internet Applications since 1995 Authored 10 books on internet technologies Adobe Certified Instructor for all Flex, AIR, Flash, and

ColdFusion courses http://blogs.digitalprimates.net/jefftapper Twitter: jefftapper

Who Are You?

• Developers who…– are open to learning– Have some experience with Flex– Have a sense of humor

• If this isn’t you, you should probably leave

Agenda

• What is bad code• Why do developers code badly• Bad Code Samples• Rules to Live By• Questions

What is Bad Code

• Bad code is…– Code which doesn’t meet the needs of a project• Efficiency• maintainability• Time to develop

– Code which doesn’t make sense

Why do developers code badly?

• Lack of Time• Lack of Knowledge• Lack of Caring

Some of my bad code…public class XMLListener extends EventDispatcher {

// FIXME! - JT - yes, i know this is// not the right solution// but im making the socket public so I// can attach a listener to it// this can clearly be done better, but im// tired, and this is what i have at the // momentpublic var socket:XMLSocket;

What are the consequences

• Bad code can lead to– Delays– Project failure– Job loss– Death

Sample 1<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml">

<mx:TextInput id="username" width="150"/><mx:TextInput id="password" width="150"/><mx:VBox width=“150" height="10" styleName="doubleLine"/><mx:Button label="submit"/>

</mx:VBox>

Main.css.doubleLine{background-image: Embed("/assets/images/doubleLine.png");}Rule1.mxml

What is wrong with #1

• Summary: Inappropriate use of container. • Description: <mx:Image> should be used to

display an image, not a container with an backgroundImage style

• Type: Maintainability, Performance• Rule: Its never appropriate to use a container

which will never have children.

#2Main App<mx:List dataProvider="{ac}"

itemRenderer="component.ItemRenderer" selectable="false" />

ItemRenderer<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" >

<mx:Image source="{data.image}"/><mx:Label text="{data.colorname}" height="30"/>

</mx:VBox>

Rule2.mxml

What is wrong with #2

• Summary: List used when VBox more appropriate

• Description: A List control has lots of code dealing with selecting items, clearly, this is not about item selection

• Type: Performance, Maintainability• Rule: Never use a List based component when

list functionality is not needed.

#3<mx:Script><![CDATA[private function setData(un:String, pw:String):void{username.text=un;password.text=pw;

} ]]></mx:Script><mx:TextInput id="username“ /><mx:TextInput id="password" />

What is wrong with #3

• Summary: Properties are set on controls, when data binding would be better

• Description: Setting properties on controls • Type: Maintenance, Development Time• Rule: Modify the Model, Let the View Follow

#4

Rule4.mxml

What is wrong with #4

• Summary: Views events handled in top level component

• Description: View is dispatching an event which is handled by a controller by passing event data back to view

• Type: Maintenance, Separation of Concerns• Rule: Always handle events as locally as

possible

#5<mx:VBox borderStyle="solid" borderColor="#00000" backgroundColor="#FFFFFF" width="200" height="100"><mx:Text text="{bodyText}" width="100%"

height="100%" /></mx:VBox>

Rule5.mxml

What is wrong with #5

• Summary: Inappropriate container nesting• Description: Additional containers added for

styling, not for child layout• Type: Performance• Rule: If you have a container with only one

child, you are usually doing something wrong.

#6<mx:Application

xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:comp="*">

<comp:ChooseMenu id= "chooser" />

<comp:DisplayMenumenuForDisplay="{chooser.menuGroup.selection.label}"

/>

</mx:Application>

Rule6.mxml

What is wrong with #6

• Summary: reaching into a child of a child• Description: Components should interact with

their children, not their children’s children• Type: Separation of Concerns, Encapsulation• Rule: Two dots and you are out

#7<mx:LinkButton label="{labels.ProcessStatus}"

enabled ="{(gridTests.selectedItems.length==1 &amp;&amp; (hasRight || (gridTests.selectedItem.StatusCode!='XX' &amp;&amp;gridTests.selectedItem.StatusCode!='XY')))?((gridTests.selectedItem.IsDerived=='n')?(gridTests.selectedItem.StatusCode!='YY'&amp;&amp; gridTests.selectedItem.StatusCode!='YX' &amp;&amp; gridTests.selectedItem.StatusCode!='XYX'):false):false}"click ="setTestStatus(event);"/>

Rule7.mxml

What is wrong with #7

• Summary: unreadable code• Description: Use functions, not complex

binding expressions• Type: Maintainability• Rule: Being too clever makes you a dumb-ass

Everyone Writes Bad Code - sometimes

• If you spend some time in the SDK source code, you can find gems like this:

var changeCount:int;changeCount=Math.max(1,getStyle("horizontalChangeCount"));if (changeCount * 0 != 0){

changeCount = 1;}

Rules To Live By

• Its never appropriate to use a container when they will never have children.

• Never use a List based component when list functionality is not needed.

• Modify the Model, Let the View Follow• Always handle events as locally as possible• If you find you have a container with only one child, you

are probably doing something wrong.• Don’t be a dumb-ass• Flex isnt broken, you are.

Questions

?

Upcoming talks

• Adobe MAX 10/4-10/8 Los Angeles

• RIA Unleashed 11/13 Boston