Chapter One
Why Flex?
It seems like nearly every programming book I have ever read starts off with the obligatory "Introduction to [whatever]" chapter, which basically regurgitates the essentials that everyone knows, and hence is the one chapter nearly every reader skips. In this first chapter of the book, I thought we''d start things off with a different approach, one that takes you, the reader, through the reasons that you might want to use Flex, what Flex is for, bursting some myths about Flex and the Flash platform, and, finally, ending up with a "Top 10" of Flex''s strong points. Enjoy!
What Is Flex?
Often this is either the first presciently asked question for someone new to the Adobe Flex ecosystem and the Flash Platform, or it is the last question asked after many hours of wrestling with how all of this "stuff" fits together in the scheme of things. Read on: the first two chapters in this book will make it all crystal clear.
In a nutshell, Flex is a rich Internet application (RIA) development toolkit based on the ActionScript 3.0 and MXML languages that can be deployed for the Web using the Flash Player plug-in, or to the desktop using the Adobe Integrated Runtime (AIR).
As Adobe Evangelist James Ward puts it in his article "How I Overcame My Fear of Flash" (www.jamesward.com/wordpress/2007/02/21/how-i-overcame-my-fear-of-flash/), "[the] Flash Player is a ubiquitous, cross-browser, cross-OS virtual machine enabling next generation web experiences. Flex is a simple tool for developers to build applications that execute in the Flash virtual machine."
What Is an RIA?
No introductory discussion of Flex would be complete without at least a cursory examination of the rich Internet application, or RIA.
Although the concept of RIAs had been around for quite some time, it wasn''t until 2002 when Macromedia (now Adobe Systems Inc.) coined the term from a Flash MX white paper, that the idea began catching on in web development. You can read the white paper, "Macromedia Flash MX - A next-generation rich client," at www.adobe.com/devnet/flash/whitepapers/richclient.pdf.
The RIA''s predecessor could be called a "Web 1.0 application," which is based on a linear, hypertext-centric architecture written in HTML, JavaScript, and CSS, which for the purposes of this text we will call a "hypertext application." An RIA, which has also come to be known as a "Web 2.0 application," is unique and differs from a hypertext application in several important ways:
Rich media - Although it could be argued that a hypertext application can have and use what is known as "rich media," it is not its defining characteristic. An RIA, on the other hand, is typified by the presence-rich content. This usually involves custom designed interfaces in a highly branded and/or expressive visual environment, which may use sounds, video, graphics, and motion that cannot be reproduced in a hypertext environment. One could say that a hypertext application is defined by a textual paradigm, whereas an RIA is defined by a visual paradigm.
Resides on the client - More importantly, a hypertext application follows a page-oriented architecture, where an application interface is created on the server and downloaded to the client in "pages." An RIA, on the other hand, is a self-contained solid-state machine that runs on the client, usually with the help of a dedicated runtime, such as a browser plug-in.
Asynchronous communication and data persistence - The browser page makes an HTTP GET request to the server each and every time the application must refresh its functional state, which uses a synchronous method of communication. The state and logic of the application must be tracked on the server, as each page cannot easily manage application logic across other pages. So, it is left up to the server scripting, typically coded in a language such as PHP, ASP, or JSP, to manage the application state for each and every client connected to the server.
Whereas a hypertext application communicates or "downloads" each page to the browser as the user traverses the application, the RIA need only be downloaded once, since it manages the creation of its own UI and internal logic. Because the client maintains full control over application state and functionality, and can communicate with the server independently of user interaction with the application, it is said to use asynchronous server communication.
Lower network consumption - And because an RIA does not need to communicate its state to the server, it is free to communicate to the server only if and when the online functionality is required, such as when retrieving or uploading a file, saving or retrieving data to and from the user''s account, or performing some task the client is unable to process on its own. This has the potential of considerably reducing bandwidth and server load, often translating into a huge financial savings.
Developers must take care not to overuse the pre-fetching of assets and/or data, which can eliminate any bandwidth or server load savings that might have been gained. Some RIAs actually consume a lot more network resources, but these are typically applications that make heavy use of streaming media, which would simply not be possible in a hypertext application.
Acts like software - Most RIAs distinguish themselves from simple embedded rich content by the presence of a standard user interface and a certain level of complexity that categorizes it as an application and not simply a rich media animation or video delivery medium. For instance, a video player on YouTube is not an RIA, but an online video editing application could be considered one.
Since most RIAs are developed according to object-oriented principles and not a page state model, their architecture can be more flexible; states can be set asynchronously by different parts of the application as a whole. This allows the application to act more like traditional software than a website. In other words, what determines where the user is in the application can be fluid and prone to many different variables, depending on the task being performed at any given moment. Therefore, RIAs have the advantage of increased responsiveness, as there is no waiting for a page refresh, which increases user productivity in accomplishing the task at hand.
Increased security protocols - However, that flexibility and fluidity comes at a price. Maintaining the application on the client means increased vigilance in communications security must be taken to avoid abuse, and some RIA technologies have developed some very specific and sophisticated security "sandboxes" that allow data to be communicated to and from the application only in very specific ways, which is mostly a good thing.
Browser-opaque - One of the typical drawbacks to RIAs over traditional hypertext applications is that because they act as a closed system (i.e., their application states are managed internally), they are "browser-opaque." That is, they cannot be navigated with browser controls (i.e., history states, the Back button), are not search engine indexable, and are not visible to accessible devices. This is a failing of all RIAs by any technology, including AJAX, Flash, AIR, Silverlight, WPF, and JavaFX.
This means that just as hypertext applications are not very good at rich interactive content, RIAs are not very good at large volumes of search engine-accessible hypertext content, which is why many applications such as text-heavy websites, blogs, and social networks still use the traditional hypertext application paradigm. Some RIA technologies have made great inroads to mitigate this disadvantage, but at the moment these kinds of solutions require conscious implementation on the part of the developer to bridge the browser divide. No RIA technology is currently browser-transparent, and probably will not be until browsers start integrating an RIA runtime as part of their native rendering model and search engines change their indexing schemes to include certain state-dependant standards, which given the current rate of browser evolution may be a long time in coming. The irony is that even as RIAs are redefining the way we use the Web, they are accused of "breaking the Web paradigm." Perhaps it is a matter of finding the right balance.
See Chapter 40 for more information on deeplinking in Flex applications.
Can be desktop-enabled - Until recently, the term "RIA" implied that the application would be run from within a browser context, which typically limits access and interaction with the operating system. But now, certain technologies, such as Adobe AIR, allow for the creation of RIAs that break out of the browser paradigm and onto the desktop. An RIA that resides on the desktop is differentiated from a traditional software application in that it still requires a runtime sandbox to execute the application, is usually built on web technologies and their derivatives, and has direct access to the Internet. A desktop-enabled RIA may function similarly to both an Internet browser and an installed application. At the moment, no RIA technology has the same level of system interaction with the operating system that typifies installed software, but this line is becoming ever more indistinct as the technologies driving RIAs continue to evolve.
"Sometimes connected" applications - Since the RIA can often choose when it is connected to the server, certain applications - whether in a browser or on the desktop - can operate in a "sometimes connected" mode unique to web applications, although the term is mostly used when referring to desktop RIAs. This can allow users to work offline for a period, and reconnect to the server if and when they need to save their work or update the application. A "sometimes connected" application is not necessarily independent of the server, as would be traditional network-enabled desktop software, but it allows a degree of flexibility in application usage that was impossible to accomplish just a few years ago.
Enables new business models - Since RIAs are redefining the way we use the Web, enabling applications that act more like software than web pages, new business models are possible, such as the software as a service (SaaS) model. This more than anything is the current thrust driving the Web 2.0 revolution, which is seen as the promises of the dot-com years finally coming home to roost.
For instance, Adobe has launched Acrobat.com, a rich service portal built into Flex that allows users to convert documents to PDF, upload documents and files to their account through Adobe Share, create real-time online meetings through the ConnectNow service (an online version of Adobe Connect), and author, save and download documents using Buzzword, a full-featured word processor application. Adobe has also released an online version of Photoshop that allows users to process images with a subset of the features of the original application, as well as a video delivery portal called Adobe TV, which features video tutorials on myriad Adobe technologies. Gmail and Google Docs, built with an AJAX development model, are also immensely powerful and popular applications. Other sites, too numerous to mention here, leverage the RIA advantage to offer users everything from personal scheduling and organization, to social networking and media creation tools. Using RIA technologies such as Adobe Flash and AIR in tandem, some applications can even leverage simultaneous browser and desktop-enabled versions of their online service, or create a product developed exclusively for desktop deployment.
Clarifying the Competition
Before we get into the specifics of Flex and the Flash platform, let us enumerate some of the current RIA technologies available. As of this writing, primary contenders in the current market are considered to be AJAX, Adobe Flash and Adobe AIR. Secondary contenders are considered to be Microsoft Silverlight, Sun JavaFX, OpenLaszlo, Mozilla Prism, Google Gears, Curl, and Adobe Flash Lite.
Since there is some confusion in tech reporting circles and the blogosphere as to competing equivalencies between certain of these technologies, without getting into too much detail on specific capabilities, some clarifications are in order.
AJAX, Adobe Flash, Microsoft Silverlight, OpenLaszlo, and Curl run in a browser environment, so they can be considered to be comparable competitors.
Adobe AIR, Google Gears, and Mozilla Prism are desktop-enabled RIA runtime environments, so they can be considered to be comparable competitors. Although Microsoft WPF is often compared with Adobe AIR, some do not consider it an RIA technology because it is not intended to be connected to an Internet server, but to be used as a high-level Windows development platform.
To clarify, Silverlight does not compete with AIR, and WPF does not compete with Flash, because they are deployed in completely different environments.
Flash Lite and Silverlight applications can be deployed in a mobile environment, so they can be said to be comparable competitors. Many mobile RIAs are developed for the native device operating system instead of through a mobile browser, so there is some ambiguity as to whether certain mobile technologies can be considered to be RIA-centric. For instance, Java is currently the language used by the majority of mobile applications, and by itself is not considered an RIA-specific technology. Google Android is a mobile operating system, which is sometimes confused as an RIA platform.
JavaFX competes with all of these, since it can be deployed to the browser, on the desktop, or in a mobile environment.
For the Love of Flex
Without getting into a blow-by-blow comparison between the previously mentioned technologies, let''s examine some of the misconceptions about Flex and the Flash platform, and some compelling reasons why Flex, Flash, and AIR are extremely powerful solutions for building engaging, next-generation RIAs. Since you''re reading this book, like me you''re probably already convinced. But if you still have concerns, or you''re still on the fence, let us be of help.
Bursting Myths about Flash and Flex
The majority of misconceptions and concerns about Flash and Flex fall into the following categories:
Flash is proprietary - Many people immersed in traditional open-source development environments using Linux, PHP, Java have the following concerns:
Can I author a SWF application without Adobe software?
Yes. To write software you need three things: an editor, a compiler, and a runtime. The SWF format is open, and there are third-party utilities that enable you to compile ActionScript into SWF bytecode. The ActionScript API itself is built into the Flash player, and the Flash Player and AIR runtimes are not open source. The Flex compiler is an open-source, free commandline utility that can be used with any third-party editor. The Flex framework and many of the Adobe specifications and tools are open source. Some of Adobe''s other tools (such as BlazeDS, a communications server for the AMF binary protocol), are open source, and for those that are not there are usually open-source versions (such as Red5, an open-source version of Flash Media Server). Some of the elements in the Flex SDK are not open source, such as the Flash Player, the font encoding libraries, and the Data Visualization components. More information on what aspects of the Flex SDK are open and which are free are available here: http://opensource.adobe.com/wiki/display/flexsdk/Downloads. There are also some great proprietary tools for Flex development, such as Adobe Flex Builder, but if you need to go completely open source with your tools as well as your framework, there is the option.
(Continues...)
Excerpted from Professional Adobe Flex 3by Joseph Balderson Peter Ent Jun Heider Todd Prekaski Tom Sugden Andrew Trice David Hassoun Joe Berkovitz Copyright © 2008 by Balderson, Joseph. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
