Unblocking The Main Thread Solving ANRs and Frozen Frames
How Not To Code Flex Applications
1. How not to code Flex
Applications
Tips and Tricks to keep you from
being fired, or fed to the lions.
Jeff Tapper
jtapper@digitalprimates.net
Digital Primates IT Consulting
2. 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
3. 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
4. Agenda
• What is bad code
• Why do developers code badly
• Bad Code Samples
• Rules to Live By
• Questions
5. 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
6. Why do developers code badly?
• Lack of Time
• Lack of Knowledge
• Lack of Caring
7. 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
// moment
public var socket:XMLSocket;
8. What are the consequences
• Bad code can lead to
– Delays
– Project failure
– Job loss
– Death
10. 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.
12. 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.
14. 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
16. 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
18. 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.
20. 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 your out
22. 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
23. 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(quot;horizontalChangeCountquot;));
if (changeCount * 0 != 0){
changeCount = 1;
}
24. 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.