Flex News Desk

So how do you write Flex Builder Tracer Bullets knowing that Flex can be a RAD tool and Tracer Bullets are good to do? I have provided two lists, one technical and the other esoteric,  that you can follow to hopefully build your Flex applications a little faster via Tracer Bullets. Here are the two lists:

Technicals

1. Don't use ActionScript, use MXML
2. Use states, don't use transitions
3. Write strongly-typed ValueObject's based on client's data needs
4. Build workflows, then build use cases
5. Use copious amounts of tagged builds in Subversion (or whatever source control you use)
6. Componetize sections
7. Use Canvas first, Panel later
8. Make builds easy to see
9. Use fake data from real ValueObjects
10. Put event handlers in Script tag, not in MXML

Esoterics

1. Find a friend in sales (or a stakeholder at your client)
2. Write e-mails to stakeholders (sales/client) who ask a question that can be answered
3. Recognize an opportunity, and take it
4. Use a phone, not e-mail or IM

Don't Use ActionScript, Use MXML
Flex Builder can render MXML components pretty accurately, whereas ActionScript components are not so accurate. This means you can see, in the Design View, your application as it's coming together. This includes GUI controls and your use of states. Having to compile your app just to see one component visually is slow. Build in MXML because it's faster to write, and faster to see.

Use States, Don't Use Transitions
A lot of screens have specific states. Some have none. The majority, do, though. It's quicker to make one LoginForm with three states than three different MXML views that make up a LoginForm. Quicker to edit, too. Flex Builder can show you those states visually, and automatically write the code for you to add and remove controls as well as changing their properties when the state changes. It's always easiest to start with "main_state", and go from there. If you don't, you may later have to copy and paste the MXML you've already written into AddChild tags individually, which are themselves in state tags. Total pain. Do it right the first time.

Transitions, the animated changes between states, add a lot and make the user's eye-focus putty in your hands. Don't do it yet, though. Wait until you've gotten direction on your appliation before you start directing the user's attention. Transitions are probably the most volatile code in your application, and are also the most subjective. Finally, they cause unexpected changes later when you start throwing data at components that causes their state to change (like custom item renderers, for example).

Define clear states for each View (component), and build them using Flex Builder. It's okay to hand type MXML as well.

Write Strongly Typed ValueObjects Based on the Client's Data Needs
Understand the data you have, as a client developer, early. Whether it's coming from your server team, the client's server team, or both, understand what you are going to be able to represent that data model in a strongly type set of classes. These do not need to match the server, and new ones can be created specifically to make GUI development easier, including properties. Getting these done allows you to be build Views (components) that actually have accurate GUI controls on them to represent the data. No VOs, and your just guessing. VOs give your GUI design direction, and give it purpose.

If there is contention in the VOs, you have a communication problem. Solve it, learn the nomenclature, get the lingo down. Collectively agree with all parties involved to have one name for everything. While some developers will say two, "We call it an asset ID, but the customers call it an item ID," you're just making it more confusing for you in meetings, e-mails, and IMs. Bad communication will sabotage any project, and clear data is the key.

If they are strongly typed, when you decided to refactor, you'll get compiler errors in Flex Builder that make it easy to quickly change names in places that your global find and replace didn't catch (or if you were just too paranoid to do so, by hand).  This way, your application is resilient to change... and it's not even really an application yet.