Lesson 1: Understanding Rich Internet Applications

Computers have played a role in business environments for more than five decades. Throughout that time, the roles of client and server have constantly evolved. As businesses and their employees have become more comfortable delegating responsibilities to computers, the look, feel, and architecture of computerized business applications have changed to meet their demands. Today businesses are asking for even faster, lighter, and richer Internet applications. In this lesson, you will learn about this evolutionary environment and understand the business requirements that push developers to build rich Internet applications (RIAs).

You will use Flex to build the FlexGrocer application seen here.

The Evolution of Computer Applications

In the earliest days of computerized business applications, all the processing took place on mainframes, with the client having no role other than displaying information from the server and accepting user input. This setup was largely dictated by the high cost of processing power. Spreading powerful clients throughout the enterprise was simply not affordable, so all processing was consolidated and “dumb terminals” provided the user interaction.

As memory and processing power became cheaper, dumb terminals were replaced by microcomputers (or personal computers). With the added power, more desktop applications, such as word processors and spreadsheets, could run as stand-alone applications, so no server was necessary. One challenge faced by organizations with microcomputers was a lack of centralized data. While the mainframe era had everything centralized, the age of microcomputer-distributed data made it more difficult to centralize business rules and synchronize data across the enterprise.

To help resolve this issue, several vendors released platforms that sought to combine the strengths of the microcomputer with those of the mainframe, which led to the birth of client/server systems. These platforms afforded end users the power and ease of microcomputers while allowing business logic and data to be stored in, and accessed from, a centralized location. The new challenge introduced with client/server systems was distribution. Anytime changes needed to be made to client applications, IT departments had to manually reinstall or upgrade the software on every single desktop computer that ran the software. Large companies found they needed a full-time IT staff whose primary responsibility was keeping the software on the end users’ desktops current.

With the explosive growth of the Internet in the 1990s, a new model for business applications became available. In this model, a web browser acted as a thin client whose primary job was to render HTML (Hypertext Markup Language) and to send requests back to an application server that dynamically composed and delivered pages to the client. This is often referred to as a “page-based architecture.” This model successfully solved the distribution problem of the client/server days; the specific page of the application was downloaded from the server each time an end user needed it, so updates could be made in a single centralized place and automatically distributed to the entire user base. This model was and continues to be successful for many applications; however, it also creates significant drawbacks and limitations. In reality, these early Internet applications bore a great resemblance to mainframe applications, in that all the processing was centralized at the server, and the client only rendered data and captured user feedback. The biggest problems with this model surrounded the user interface (UI). Many of the conveniences that end users gained in the client/server era were lost, and the UI was limited by the capabilities of HTML. For example, desktop software as well as client/server applications frequently allows drag-and-drop. However, HTML applications almost never do; they are prevented by the complexities of—and a lack of cross-browser support for—the DHTML (Dynamic HTML) elements that are required to implement drag-and-drop in a pure HTML/DHTML solution.

In most cases, the overall sophistication of the client-side solutions that could be built and delivered was greatly reduced. Although the web has offered great improvements in the ease and speed of deploying applications, the capabilities of web-based business applications took a big step backward because browser-based applications had to adapt to the limitations of the web architecture: HTML and the stateless nature of Hypertext Transport Protocol (HTTP).

Today, the demands on Internet-based applications continue to grow and are often quite different from the demands of their mid-1990s counterparts. End users and businesses are demanding more from their investments in Internet technology. Many companies are looking toward richer models for Internet applications—models that combine the media-rich power of the traditional desktop with the ease of deployment and content-rich nature of web applications.

As Internet applications begin to be used for core business functions, the maintainability of those applications becomes more crucial. The maintainability of an application is directly related to the application’s architecture. Sadly, many web applications were built with little thought about the principles of application architecture and are therefore difficult to maintain and extend. Today, it is easier to build a solid architecture for an application by providing a clean separation between the business, data access, and presentation areas. With the introduction of elements such as web services, the concept of a service-oriented architecture (SOA) has become more feasible for web-based applications.

Rich Internet applications are the next step in this ongoing evolution. They exist to meld the usability and functionality of the client/server era with the ease of distribution provided by the Internet era. To meet the demands of businesses, RIAs should be able to do the following:

• Provide an efficient, high-performance way to execute code, content, and communications. In the next section of this lesson, you’ll explore the limitations of the standard HTML-based applications and learn that traditional page-based architectures have a number of performance-related challenges.

• Provide powerful and extensible object models to facilitate interactivity. Web browsers have progressed in recent years in their capability to support interactivity through the Document Object Model (DOM) via JavaScript and DHTML (including HTML 5), but they still lack standardized cross-platform and cross-browser support. Although there are drafts of standards that may address these limitations in the future, building RIAs with these tools today so that they work on a variety of browsers and operating systems involves creating multiple versions of the same application.

• Enable using server-side objects via Web Services or similar technologies. The promise of RIAs includes the capability to cleanly separate presentation logic and user interfaces from the application logic housed on the server.

• Allow for deployment to a variety of devices. Applications are no longer used just from computers, they are also accessed from phones, televisions, tablets, and other connected devices.

• Enable use of Internet applications when offline. As devices continue to grow in popularity, one of the serious limitations of Internet applications is the requirement that the machine running the application remains connected to the Internet. Although users can be online the vast majority of the time, business travelers know there are times when an Internet connection is not possible. A successful RIA should enable users to be productive with or without an active connection.

The Break from Page-Based Architecture

For experienced web developers, one of the biggest challenges in building RIAs is breaking away from a page-based architecture. Traditional web applications are centered on the concept of a web page. Regardless of which server-side technologies (if any) are used, the flow goes something like this:

1. The user opens a browser and requests a page from a web server.
2. The web server receives the request.
3. The web server hands the request to an application server to dynamically assemble the web page, or it retrieves a static page from the file system.
4. The web server sends the page (dynamic or static) back to the browser.
5. The browser draws the page in place of whatever was previously displayed.

Even when most of the content of the previous page is identical to the new page, the entire new page needs to be sent to the browser and rendered. This is one of the inefficiencies of traditional web applications: Each user interaction requires a new page to be loaded in the browser. One of the key goals of RIAs is to reduce the amount of extra data transmitted with each request. Rather than download an entire page, why not download only the data that has changed and update the page the user is viewing? This is the way standard desktop and client/server applications work.

Although this goal seems simple and is readily accepted by developers taking their first plunge into RIA development, web developers often bring a page-based mindset to RIAs and struggle to understand how to face the challenges from the page-based world, such as “maintaining state.” For example, after users log in, how do you know who they are and what they are allowed to do as they navigate around the application?

Maintaining state was a challenge introduced by web-based applications. HTTP was designed as a stateless protocol: Each request to the server was an atomic unit that knew nothing about previous requests. This stateless nature allowed for greater efficiency and redundancy because a connection did not need to be held open between browser and server. Each new page request lasted only as long as the server spent retrieving and sending the page, allowing a single server to handle a much larger number of simultaneous requests.

But the stateless nature of the web added challenges for application developers. Usually, applications need to remember information about the user: login permissions, items added to a shopping cart, and so on. Without the capability to remember this data from one request to the next, true application development would not be possible. To help solve this problem, a series of solutions were implemented revolving around a unique token being sent back to the server with each request (often as cookies, which are small text files containing application-specific identifiers for an individual user) and having the server store the user’s information.

Unlike traditional web applications, RIAs can bypass many of these problems. Because the application remains in client RAM the entire time it’s used (instead of being loaded and unloaded like a page-based model), variables can be set once and accessed throughout the application’s life cycle.

A different approach to handling state is just one of many places in which building applications requires a slightly different mindset than web application development. In reality, web-based RIAs bear more resemblance to client/server applications than they do to web applications.

The Advantages of Rich Internet Applications

Unlike the dot-com boom days of the mid- to late 1990s, businesses are no longer investing in Internet technologies simply because they are “cool.” To succeed, a new technology must demonstrate real return on investment and truly add value. RIAs achieve this on several levels: They can reduce development costs and add value throughout an organization.

Business Managers

RIAs make it easier for end users to work with the software, which leads to an increase in the number of successful transactions. This increase can be quantified: Businesses can measure things like the productivity of employees using intranet applications or the percentage of online shoppers who complete a purchase. More productive employees, making fewer mistakes, can drastically reduce labor costs; and growing online sales can increase revenue and decrease opportunities lost to competitors.

IT Organizations

Breaking away from page-based architectures reduces the load on web servers and reduces overall network traffic. Rather than entire pages being transmitted over and over again, an entire application is downloaded once; then, the only communication back and forth with the server is the data to be presented on the page. Easing the server load and network traffic can noticeably reduce infrastructure costs. RIAs that are developed using sound architectural principles and best practices can also greatly increase the maintainability of an application as well as greatly reduce the development time to build the application.

End Users

A well-designed RIA greatly reduces users’ frustration levels because they no longer need to navigate several pages to find what they need, nor do they have to wait for a new page to load before continuing to be productive. Additionally, the time users spend learning how to use an application can be greatly reduced. As the success of devices such as Apple’s iPhone and Google’s Android-based phones clearly demonstrates, a rich user experience matters, and people are willing to pay for it. End user experiences are one of the greatest benefits of RIAs. Today, there are a number of excellent applications that would not be possible without the concepts of an RIA, such as the MLB.TV Media Player for Major League Baseball, which delivers real-time and on-demand games with statistics and commentary, or the FedEx Custom Critical shipment tracking dashboard that tracks high-value shipments as they move toward delivery. These applications provide excellent examples of the ease of use an RIA can offer an end user.

RIA Technologies

Today, developers have several technology choices when they start building RIAs. Among the more popular technologies are those based on HTML, such as AJAX (Asynchronous JavaScript and XML) and HTML 5, and those based on plug-ins. Plug-in-based options execute code written in languages such as MXML/ActionScript or XAML/.NET in a virtual machine (Flash Player and Silverlight, respectively); these are installed inside the web browser.

The current RIA landscape offers four platforms: HTML5/AJAX, Java, Microsoft Silverlight, and Adobe Flash Platform. Each has distinct advantages and disadvantages when applied to an RIA. As with many things in life, the key is discovering the right tool for your circumstance.

HTML 5 and Asynchronous JavaScript and XML (AJAX)

One of the easier technologies to understand (but not necessarily to implement) is AJAX. It is based on tools already familiar to web developers: HTML, DHTML, and JavaScript. The fundamental idea behind AJAX is to use JavaScript to update the page without reloading it. A JavaScript program running in the browser can insert new data into the page or change its structure by manipulating the HTML DOM without reloading a new page. Updates may involve new data loaded from the server in the background (using XML or other formats) or responses to user interaction, such as a mouse click or hover.

Early web applications used Java applets for remote communication. As browser technologies developed, other means, such as IFrames (floating frames of HTML content that can speak to each other and to servers), replaced the applets. In recent years, XMLHttpRequest was introduced into JavaScript, facilitating data transfers without the need for a new page request, applet, or IFrame.

In addition to the benefit of using familiar elements, AJAX requires no external plug-in. It works purely on the browser’s capability to use JavaScript and DHTML. However, the reliance on JavaScript poses one of the liabilities of AJAX: It fails to work if the user disables JavaScript in the browser. Another issue with AJAX is that it has varying levels of support for DHTML and JavaScript in different browsers on different platforms. When the target audience can be controlled (say, for intranet applications), AJAX can be written to support a single browser on a particular platform. Many businesses today standardize their browsers and operating systems to help solve this problem. However, when the audiences are opened up (such as those for extranet and Internet applications), AJAX applications need to be tested, and often modified, to ensure that they run identically in all browsers and on all operating systems. As the number of browsers available for each operating system continues to increase, this becomes increasingly challenging. Combine that with the requirement many businesses have to support older, outdated versions of browsers, and ensuring that the code runs identically in all browsers often becomes the largest segment of application development.

Finally, HTML and JavaScript were not created with applications in mind. This means that, as a project grows in scale, the combination of code organization and maintenance can be challenging. AJAX is not likely to go away anytime soon, and each day more high-profile AJAX applications (such as Google Maps) are launched to great acclaim. In fact, for certain classes of applications, usually smaller widgets and components, AJAX is clearly a better solution than any of its competitors due to its small size and relatively independent deployment model.

It should be noted that AJAX is not a programming model in and of itself. It is really a collection of JavaScript libraries. Some of these libraries include reusable components designed to make common tasks easier. Because AJAX lacks a centralized vendor, integrating these libraries introduces dependencies on third parties, which assumes a certain amount of risk.

The latest version of the HTML specification—HTML5—has added a number of new features, making it more competitive with other RIA technologies. It now includes support for vector-based drawing and animations, video playback, and lots of other new features that were previously possible only with a browser plug-in.

Unfortunately, HTML is still a draft proposal. The current HTML 5 specification available from www.w3.org/TR/html5 warns that the specification is still being formed, and is not currently stable. When it is eventually finalized, it will aim to reduce some of the complexity and certainly the disadvantages of working in this environment. However, at this time we must take a wait-and-see approach to identifying how organizations producing browsers adopt and implement this technology. Decision makers should remember that the previous four versions of HTML were implemented very differently by the various browser makers, and should wonder if there is reason to believe the fifth version will be any different.

Java Virtual Machine

Java—and the languages and frameworks built on Java—are the de facto standard for most enterprise server applications. However, Java has had a traditionally difficult time on the client for many reasons, including download size and perceived and real difficulties maintaining and updating the Java runtime.

Although there are certainly some success stories of Java client-side code, such as the Eclipse project (the development environment that Flash Builder itself uses), Java is still struggling to gain market share in the RIA space.

The current offering from the Java community in the RIA space is called JavaFX, a software platform designed to run across many JavaFX-enabled devices. While JavaFX has been embraced strongly by some of the Java community, it has so far received a lukewarm welcome by those not already committed to Java as their end-to-end solution. The 2.0 release for JavaFX is scheduled for the second half of 2011; perhaps with that release the promise of JavaFX will be fulfilled.

Microsoft Silverlight

As of the time of writing, Silverlight 4.0 is the currently released version of the Microsoft solution for building RIAs. It is a comprehensive offering whose many pieces include:

• Silverlight—A web-based application framework that provides application functionality, written in a subset of .NET.

• XAML—Extensible Application Markup Language. The XML-based language in which you declare user interfaces, XAML is somewhat analogous to Flex’s MXML language, which you will learn about shortly.

• Microsoft Expression Studio—A professional design tool intended to build Windows client applications as well as web applications targeted for the Silverlight player. The suite specifically includes:

• Expression Web—A visual HTML editor.

• Expression Blend—A visual application that builds and edits applications for WPF (Windows Presentation Foundation) and Silverlight applications.

• Expression Designer—A graphics editor.

• Expression Encoder—A video encoder.

With these tools, Microsoft is promoting a workflow in which designers create compelling user interfaces with Expression (using WPF or Silverlight), and then developers implement the business and data access logic.

As of the time of writing, Silverlight plug-ins exists for most browsers on Windows and a few browsers on Mac OS X. A Linux and FreeBSD implementation written by Novell, named Moonlight, brings this content to those operating systems. The current stable release of Moonlight is 2.3, which supports Silverlight 2.0 applications. There was a recent release of a preview for Moonlight 4.0, which targets support for Silverlight 4.0 applications.

Silverlight is beginning to offer a compelling platform, especially for .NET developers who can use tools such as Microsoft Visual Studio and leverage existing knowledge to quickly create new applications. The only limitation that Microsoft seems to have at this moment is the distribution of the Silverlight runtime, which is still limited even on Windows, let alone Mac and Linux. According to riastats.com, 27 percent of all browsers do not have a Silverlight player installed, and nearly three-quarters of all machines running Linux do not have Silverlight.

Silverlight is absolutely worth watching over the coming years.

Adobe Flash Platform

One of the leading competitors in the RIA space is the Adobe Flash Platform. The platform is composed of a number of tools and technologies designed to provide rich and compelling user experiences while maximizing developer productivity and designer involvement.

While many pieces of the Flash Platform can be included as needed for different types of applications, the following sections include the ones most relevant to this book.

Adobe Flash Player and AIR

Originally written as a plug-in to run animations, Flash Player has evolved significantly over the years, with each new version adding capabilities while still maintaining a very small footprint. Over the past decade, Flash Player has gained near ubiquity, with some version of it installed on more than 99 percent of all desktops. Since 2002, Macromedia (now part of Adobe) began focusing on Flash as more than an animation tool. With the Flash 6 release, Macromedia began providing more capabilities for building applications. It found that the ubiquity of the player, combined with the power of the scripting language (ActionScript), enabled developers to build full browser-based applications and get around the limitations of HTML.

By targeting Flash Player, developers could also break away from browser and platform incompatibilities. One of the many nice features of Flash Player was that content and applications developed for any particular version of Flash Player would usually run on any platform/browser that supported that version. With very few exceptions, that remains true today.

AIR (Adobe Integrated Runtime) continues the tradition of Flash Player, but removes dependency on the browser. AIR allows content written for Flash Player, in addition to HTML and JavaScript, to run as a desktop application, effectively eliminating the need for ActionScript developers to learn additional languages should they wish to deploy their applications as more traditional applications or to non-desktop devices. Current versions of the AIR runtime are available for Windows, MacOS, Linux, and the Android Operating Systems. Support for other Mobile operating systems such as iOS, BlackBerry and Windows Phone 7 has been publicly discussed as a near future possibility.

Flash Professional

An industry-leading tool for creating engaging experiences, Flash is familiar to most designers worldwide. It provides a rich environment to create graphic assets as well as animations and motion.

Flash Professional can be used alone to create RIAs; however, the environment is intended for designers creating interactive content and may seem unfamiliar to developers who wish to build RIAs using a more traditional development methodology. Originally, this kept many serious developers from successfully building applications on the Flash Platform, leading to the introduction of the Flex framework.

Flex

Sensing the need for RIA tools that were more developer-friendly, Macromedia created a language and a compiler that enabled developers to work with other, familiar languages from which the compiler could create applications to run in Flash Player. In 2004, Macromedia released Flex 1.0 (followed by Flex 1.5 in 2005). Adobe continued this cycle, releasing Flex 2.0, Flex 3.0, Flex 4, and Flex 4.5 in 2006, 2008, 2010, and 2011, respectively. Functionally, Flex applications are similar to AJAX applications, in that both are capable of dynamic updates to the user interface and both include the ability to send and load data in the background.

Flex goes further by providing a richer set of controls and data visualization components along with the next generation of developer tools and services to enable developers everywhere to build and deploy RIAs on the Flash Platform.

Flex builds on several key technologies and introduces several new pieces:

• ActionScript 3.0—A powerful object-oriented programming language that advances the capabilities of the Flash Platform. ActionScript 3.0 is designed to create a language ideally suited for building RIAs rapidly. Although earlier versions of ActionScript offered the power and flexibility required for creating engaging online experiences, ActionScript 3.0 advances the language, improving performance and ease of development to facilitate even the most complex applications with large datasets and fully object-oriented, reusable code.

• MXML—A declarative XML syntax that allows for the simplified creation and maintenance of user interfaces. MXML provides an easy way to visualize and implement the hierarchical nature of a complex UI without the need to directly write and maintain ActionScript code. MXML is automatically compiled to ActionScript during the process of building a Flex application.

• Flash Player 10.x—Building on the success of Flash Player 9, this next generation of Flash Player focuses on improving script execution and driving Flash Player to additional smaller devices. To facilitate this improvement, FP10 introduces optimizations to the ActionScript Virtual Machine (AVM), known as AVM2, a virtual machine that understands how to execute ActionScript 3.0 code regardless of the device displaying the content (for example, a mobile phone, a TV, or a desktop computer). Major improvements in runtime-error reporting, speed, memory footprints, and improved use of hardware acceleration are allowing developers for this platform to target a variety of devices well beyond the desktop/web browser. Unlike applications built with JavaScript, Flash Player is capable of using a just-in-time (JIT) compilation process that enables the code to run faster and consume less memory, like a native application installed on your computer. More recent releases of the Flash Player have included support for high definition video, improved hardware (and GPU) acceleration, multi-monitor full screen support, and more.

• Flex SDK—Using the foundation provided by FP10 and ActionScript 3.0, the Flex framework adds an extensive class library to enable developers to easily use the best practices for building successful RIAs. Developers can get access to the Flex framework through Flash Builder or the free Flex SDK, which includes a command-line compiler and debugger, enabling developers to use any editor they prefer and still be able to access the compiler or debugger directly.

• Flash Builder 4.5—Flash Builder 4.5 is the second release of the rebranded IDE (integrated development environment) built on the success of Flex Builder 2 and 3. Providing developers with an environment specifically designed for building RIAs, Flash Builder 4.5 takes the IDE to the next level. Built on top of the industry-standard open source Eclipse project, Flash Builder 4.5 provides an excellent coding and debugging environment and promotes best practices in coding and application development. Drawing on the benefits of the Eclipse platform, it provides a rich set of extensibility capabilities, so customizations can easily be written to extend the IDE to meet specific developers’ needs or preferences. Additions to Flash Builder 4.5 include custom code templates, support for development of mobile and multi-screen applications, improved designer/developer workflow, and much more.

Flash Catalyst

There is also a new version of Flash Catalyst—a tool focused on designers creating RIAs. Flash Catalyst allows designers to build applications by selecting portions of preexisting artwork created in Adobe Photoshop, Illustrator, or Fireworks and then indicating how that artwork relates to the application (scrollbar, button, and so on).

Using this tool, a designer can create pixel-perfect application shells complete with behaviors, transitions, and even data placeholders that are ready for integration and implementation by a developer using Flash Builder 4.5. The combination of these tools represents a powerful cross-platform designer-developer workflow built on the industry-standard graphics editing capabilities offered by the Adobe Creative Suite.

The latest version of Flash Catalyst allows for custom, skinnable components, the ability for developers to “protect” code, so design changes don’t accidently break functionality, and much more.

Flash Platform Server Technologies

Although beyond the scope of this book, the Flash Platform extends further to the server, providing services and functionality that RIAs can consume. Available servers and services range from workflow engines to data persistence and from messaging to video publishing and delivery.

Although you don’t need any of these components to build rich experiences and applications, they do provide amazing capabilities that can extend your applications’ reach and use.

What You Have Learned

In this lesson, you have:

• Explored the evolution of computer applications (pages 4–6)

• Explored alternatives to page-based architecture (pages 6–7)

• Explored the benefits of RIAs (pages 7–8)

• Compared RIA technologies (pages 8–15)