As an example application, I've put together a little Flex application that lets you guess when my daughter (Ava) will be born called "What Will Ava Do?"
You can guess the date, time, weight, and length. Feel free to give it a whirl at http://firemoss.com/com/firemoss/avapool/ - I'd love to hear from you!
4 comments - Posted by Joe Rinehart at 5:18 PM - Categories: Flex | Off Topic
I love loading spinners. I'm not sure why. Sometimes, when something locks up with a spinner going, I won't even notice.
In Flex apps, I've used one by "jake," but I had a few issues with it:
I was restless the other night, so I put together my own version, featuring the following:
In its simple, stock form, it's just a spinner:
However, spinning something else (like a Button) with custom effects can be entertaining:
It's not perfect (the stock "tick" for the spinner doesn't use CSS, etc.), but how much more overengineered could a loading spinner get?
Try it out and play with the parameters (view source enabled). Use at your own peril.
5 comments - Posted by Joe Rinehart at 3:02 PM - Categories: Flex
It looks like ColdBox beat me to the punch on this one. I've been working on this since MAX, but I got hustling and committed the bits to the Model-Glue SVN ("bleeding edge") repository this morning.
There's a full blog entry about using this on the Model-Glue blog, as well as a 13-minute video of its use.
For those of you interested in the highlight reel, the following snippet shows how you'd use the new Model-Glue RemotingService (part of the application template) and the AS3 helper classes to read a Widget of a given WidgetId and display the Model-Glue trace of it being loaded:
Enjoy!
1 comments - Posted by Joe Rinehart at 7:25 AM - Categories: Flex | Model-Glue
One thing that's bugged me for a bit about the native Accordion control in Flex is that there's no default way (that I can find) to state an alternate icon or style for the header of the open child.
You can manually watch it for changes, changing the style (or other properties) of the header for the selected child, but that's a bit of an "outside in" approach.
I'm by no means a styling or skinning expert for Flex, so I wanted a solution that'd let me work in my more "developerish" and less "designerish" mindset.
To this end, I knocked together an extension of the default AccordionHeader that has two properties: openStyleName and closedStyleName. Pretty self-explanatory: it'll assign the open or closed style when the header's parent according changes its selected child.
Demo w/ view source is available at http://www.firemoss.com/blogsamples/accordionheader/.
Basic usage:
2 comments - Posted by Joe Rinehart at 3:26 PM - Categories: Flex
I wouldn't quite say I've been a Flex "Hack" up until recently, but I definitely haven't had the same level of tooling and formality behind my Flex applications as I have in the ColdFusion realm.
After working with slippery beasts like the dynamic typing of ColdFusion and the unpredictability of HTML interfaces, Flex is such a wonderful development environment that I've often felt it unnecessary to use many of the tools and techniques I've relied on in HTML-focused ColdFusion development.
On my current project, however, I'm changing my ways. Here's a quick list (not a tutorial) of tools I'm using that are changing my world:
On the server side, unit tests have saved me when it comes to developing ColdFusion-backed Flex applications. It's a lot easier to develop services against programmatic tests than it is to work through a Flex UI.
Until today, though, I'd never used FlexUnit. In the past half-hour, I've installed it, written tests against the four Cairngorm commands (we just started it yesterday!) in the application I'm working on, and I can now test the controller, model, and services tier of my application without clicking through a UI. It's good stuff, and I'd recommend downloading the tool and reading Darron Schall's tutorial.
Why use Ant when you can compile via Flex Builder?
In my current situation, it allows us to set up daily builds of our application on a testing server.
In other situations, it'd allow you to automate builds of your application pointing to alternate resources (such as environment-specific services-config.xml files, etc).
Additionally, my current project is to be "brandable," allowing alternate UIs to be used while keeping a single code base of controller, model, and service tier code. We're accomplishing this by writing the application in a code-behind style (see next section), using Ant to compile against a Flex library projects for each "brand" containing view-tier assets.
By doing all of this via Ant, we can use a single build script to compile and deploy changes to all brands of the application simultaneously.
Code-behind is a technique that separates UI code from UI component declaration. I'm still a bit on the fence about it.
On the positive side, code-behind allows me to write UI code that'll be common across all of our "brands," allowing the actual view implementation to change drastically without altering underlying functionality.
In other words, presentation-focused developers only worry about the MXML tags. I worry about handling their behavior and linking them together in a code-behind class.
It's not without its quirks - Binding is nearly broken, requiring me to manually bind in the code-behind, which could trip up presentation developers wanting to more with bindings (or require them to write AS code in their view, which somewhat defeats the point of code behind).
Additionally, I'm afraid of how much code some folks may cram into a code-behind, mistaking code-behind for a full separation of concerns / MVC style architecture. Especially on the AIR side of the fence, it wouldn't be surprising to see an ASP.NET-style mess of SQL queries being placed inside of UI-tier event handlers (creationComplete on ContactListCodeBehind.as fires an SQL query to list contacts - whoa, it sounded OK in theory!).
Conclusion
If you're looking to make a shift from occasionally writing Flex applications to making them a large part of your development life, I'd encourage you to explore all three of these techniques / technologies. They're fairly lightweight ways to make Flex development easier, more productive, and more professional!
5 comments - Posted by Joe Rinehart at 9:24 AM - Categories: Flex | Best Practices
A Flex developer asked me a question about events today. "[When using events], Flex code hinting does something like customName.CUSTOM_NAME. Any idea where it's getting that from?"
When you're creating your own events, it's important to follow this convention: it enables greater compile-time checking of event types.
Let's pretend I was working with Contacts, and I created a ContactEvent with types of "contactSaved" and "contactDeleted" being used in MXML components.
In my component, I do this to create a contact event:
Whoops, I just typed "contractSaved" as the type. That's going to make me spend forever figuring out why its listeners aren't being fired.
To save this kind of mess, use static constants on your custom events and avoid the "magic string" antipattern:
Now, when you raise the event, reference the constant:
No more mystery event names!
2 comments - Posted by Joe Rinehart at 10:01 AM - Categories: Flex | Best Practices
This is a rather long post that walks through creating a ColdFusion service CFC and a Flex class to communicate with it using test-driven development tools.
Test-driven development: at first, it seemed like a lot of overhead. However, now that I've been doing it for a year and on multiple projects, I can't get enough. Believe it or not, you will get things done faster. Even better, I'm now more confident in my code, and I think it's made me an overall better developer.
3 comments - Posted by Joe Rinehart at 2:05 PM - Categories: Flex | ColdFusion MX | Flex and ColdFusion | Best Practices