As you know, Flex applications are really Flash applications, which means they’re limited
by the constraints of the Flash Player. In particular, the Flash Player is not suited to producing
vanilla documentation as HTML is. It’s also not supported as HTML on portable devices,
although support is improving.
The Flash Player cannot display anything outside the boundaries of the player’s space
embedded in a web page. The size of the player window is determined by the HTML code
that integrates the Flash file with the rest of the page. This can be a real pain, since it
means your Flex application cannot make the screen bigger or smaller to suit the current
interaction. It is possible to open a new Flash/Flex window using ActionScript to call
JavaScript, but it’s rarely worth the complexity and hassle.
It’s not currently possible to drag and drop files from the desktop to the Flash Player.
Because the Flash Player is designed to work across a wide range of operating systems, it
would be very difficult to support this functionality. Every OS has a different mechanism
for how dragging and dropping works. This makes conveniences like displaying an image
that’s been dropped onto the player impossible.
Although Adobe publishes the format of SWF files, it still is the only entity that can
make changes to the format. Any enhancements to the file format can be made only if
Adobe decides to make them. Open-source formats such as Ajax do not have this limitation.
In Adobe’s defense, the company has been making great efforts to distribute Flex as
open-source to encourage community feedback and development.
Because Flex applications are published as SWF files, there is a delay when loading
them that isn’t an issue for regular HTML files. Depending on the client’s computer
speed, the network connection, and the amount of data in the SWF file, the initial load
delay can be several seconds. This is no different from any other thin client type of
application such as a Java applet or even a regular desktop application, for that matter.
The upside is that once the application loads, the user experience is very fast and smooth,
without HTML’s frequent page reloads.
The Apollo project removes many of Flex’s limitations but comes at the price of no longer
being an Internet application. Apollo executes Flex applications within the context of a
full-blown desktop application. Apollo consists of a set of runtimes that enable you to create
stand-alone applications that run on Windows, Mac, and Linux. It allows you to have total
control over the look of your applications and can use funky things such as transparency and
non-rectangular windows. Essentially it’s taking Flex and creating a stand-alone application.
Apollo has been renamed Adobe AIR, which integrates HTML, Ajax, Flash, and Flex all
together into one desktop application. You’ll be an interactive guru if you learn Flash, Flex,
AIR, and ActionScript, which all enable you to build cooler applications. You can get more
information about AIR here: http://labs.adobe.com/technologies/air.
Flex vs. HTML/Ajax
In the beginning there was HTML, and it was good, but it’s made to generate static
content. There’s no support for user interaction on a page. Animation is limited to
animated GIF images. As with practically any other technology on the web there is
constant pressure on developers to improve and add functionality to their web sites.
Dynamic HTML
Dynamic HTML is the combination of HTML, style sheets, and a scripting language
to animate or modify the appearance of a web page according to user actions. The first
scripting language was JavaScript, introduced by Netscape. Unfortunately, the scripting
language landscape resembles a war-torn battlefield. Microsoft responded to Netscape’s
JavaScript by developing its scripting language, JScript. While similar to JavaScript, it’s
not identical. This is the first landmine that anyone scripting a page to make it interactive
must navigate.
DOMs
To make matters worse, no one could agree on how to describe the elements of a web
page, called the Document Object Model (DOM). Again, Netscape and Microsoft
developed similar but not entirely compatible DOMs. The result is that the JavaScript
written to modify objects on a page often needs to check which type of browser is in
use and behave differently. This creates endless headaches for anyone writing code.
The W3C, which develops web standards, stepped in and began defining standards
for how a DOM should be defined and manipulated. This has helped make working with
multiple browsers easier, as most modern browsers support at least one revision of the
W3C DOM standard.
Ajax
The combination of JavaScript and the DOM allows web developers to script out interactions
on web pages. Ajax takes that one step further by allowing JavaScript to request additional
information from a web server without a page request (and subsequent screen refresh).
Figure 1-3 shows the distinction between the JavaScript engine and server-side scripting.
Additionally, it displays the interaction of the Filesystem or Database and Apache or IIS,
which both reside on the web server and the web browser.
