In today's data-centric world, being able to efficiently work with information is a necessity. Users want (and need) access to their "stuff" from whatever computer they're at, whenever they need it. They want to drag and drop, they want rich fluid graphical experiences with sound and video -- and they want it all right now!
Software developers want it all too. Time to market is of high strategic value, software development (and maintenance) is expensive, and guaranteeing that all users are on the exact same version at the exact same time is critical.
Rich Internet Applications (RIAs) address problems such as these by making it possible for developers to give users a compelling experience that, instead of reloading a page every time they click on something, have the feeling of "live" applications. That's the key ingredient to providing users with a sense of engagement.
RIAs do this through browser plug-ins which act as local runtime engines. And with a runtime engine available for various browsers and operating systems, applications look the same no matter what system users are using.
While there are a number of tools that let developers build RIAs, Adobe's Flex, now in its third release, was one of the first. Flex3 is an open-sourced development framework with unique features such as:
- The nearly ubiquitous Flash Player.
- A huge, knowledgeable community.
- Tight integration with Adobe tools such as Photoshop, Fireworks, and Coldfusion.
- A free SDK
The heart of what executes a Flex application is the Flash Player, a powerful, fast, and lightweight platform-agnostic runtime engine. The Flash Player that Flex applications execute on is capable of processing large amounts of data, has robust 2D graphical rendering capabilities, multi-threaded processing, support for various communication protocols, and true multimedia formats, such as streaming video, images, and audio. However, developers coming into Flash from the software world may find the transition awkward at times because of Flash's roots in animation and an environment based on timelines, layers, frames, and frames per second, rather than, say, lines of code.
In a nutshell, here's what the lifecycle of a typical Flex application looks like:
- Use Flex Builder (or SDK) to develop in your local development environment by writing MXML and ActionScript code.
- When testing, you use Flex Builder (or SDK) to compile code, where the main output is an "SWF" file.
- Use the browser to launch this file, which invokes the Flash Player plug-In, and your application executes.
- A Flex application typically interacts with a server tier to exchange data.
- When the application is ready to be released, publish the SWF and any accompanying files (images, for instance) to your production Web server where users invoke it via URLs.
If you work with application servers like Coldfusion and PHP, it is important to note that you're not pushing the source files to production, but rather a compiled application (similar to Java's ".java" files).
Flex is an event-driven environment. In traditional Web development, events may mean users clicking on links or Submit buttons, causing your server to execute the appropriate URL and producing some output. However, the term "event" isn't used as much in traditional Web applications because most of the application is on the backend. However, Flex is a client-side technology with all the action on the user's side. Consequently, what drives a Flex application are events — something causes something to occur, and something else handles it when it occurs. Thus the two main pieces of an event-driven application are:
- Event Triggers that cause events; anything from users moving the mouse over a button to the application loading.
- Event Handlers that handle events; anything from invoking functions that change display characteristics to committing an input form. This is where the logic is.
If you're coming from traditional Web technologies, you may not be used to thinking like this.