Adobe Press Adobe Flex 2 Training From The Source Oct 2006 ISBN 032142316X

  

Adobe Flex 2: Training from the Source, 1/e

By Jeff Tapper, James Talbot, Matt Boles, Ben Elmore, Mike Labriola ............................................... Publisher: Adobe Press Pub Date: October 20, 2006 Print ISBN-10: 0-321-42316-X Print ISBN-13: 978-0-321-42316-0 Pages: 624

   Part of the Adobe Training from the Source series, the official curriculum from Adobe,

developed by experienced trainers. Using project-based tutorials, this book/CD volume is

designed to teach the techniques needed to create sophisticated, professional-level projects. Each book includes a CD that contains all the files used in the lessons, plus

completed projects for comparison. This title covers the new development framework for

Rich Internet Applications, Adobe Flex 2. In the course of the book, the reader will build

several Web applications using Flex Builder and incorporating MXML and ActionScript 3.0.

  Adobe Flex 2: Training from the Source, 1/e By Jeff Tapper, James Talbot, Matt Boles, Ben Elmore, Mike Labriola ............................................... Publisher: Adobe Press Pub Date: October 20, 2006 Print ISBN-10: 0-321-42316-X

Print ISBN-13: 978-0-321-42316-0

Pages: 624

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  Copyright Adobe® Flex™ 2: Training from the Source Jeff Tapper/James Talbot/Matthew Boles with Benjamin Elmore and Michael Labriola

  Adobe Press books are published by

  Peachpit

  1249 Eighth Street Berkeley, CA 94710 510/524-2178 800/283-9444 510/524-2221 (fax) Find us on the World Wide Web at:

  

  To report errors, please send a note to Copyright © 2007 by Adobe Systems, Inc.

  Authors: Jeff Tapper/James Talbot/Matthew Boles with Benjamin Elmore and Michael Labriola Adobe Press Editor: Victor Gavenda Editor: Robyn G. Thomas Technical Editor: Michael Labriola Production Coordinator: Becky Winter Copy Editor: Nancy E. Sixsmith Compositors: Rick Gordon, Emerald Valley Graphics/Debbie Roberti, Espresso Graphics

  Proofreader: Mark Kozlowski

  Notice of Rights

  All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. For information on getting permission for reprints and excerpts, contact

  Trademarks

  Flash, ColdFusion, and Adobe are registered trademarks of Adobe Systems, Inc. Flex is a trademark of Adobe Systems, Inc.

  Throughout this book, trademarked names are used. Rather than put a trademark symbol in every occurrence of a trademarked name, we state that we are using the names in an editorial fashion only and to the benefit of the trademark owner with no intention of infringement of the trademark.

  Notice of Liability

  The information in this book is distributed on an "As Is" basis, without warranty. While every precaution has been taken in the preparation of the book, neither the author, Adobe Systems, Inc. nor the publisher, shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer software and hardware products described in it.

  9 8 7 6 5 4 3 2 1

  Dedication My efforts on this book are dedicated to my wife Lisa and daughter Kaliope. Everything I do, I do for you two. Jeff Tapper

My efforts are dedicated to my family and friends as well

as the Adobe Training and Consulting teams for giving me the incredible opportunities that have allowed this book to come to be. James Talbot To friends.

  

To Sandra, my best friend and wife, who has helped and

supported me in so many ways over the years. Thanks for supporting me even when I chose to do crazy things, including writing this book.

  

To my siblings, Melissa, Todd, Jody, and Kent (and their

wonderful families) who continue to be better and better

friends with each passing year.

To Bryan and Colleen, who prove that once built, a solid

friendship can't be diminished with time or distance.

  To Bob and Connie, who were willing to be friends when I needed it most, even at the expense of their time. To Sue, Robert, James, Deborah, Tina, Cathrine, Leo, Jon, and Jim, who are not only my colleagues in Adobe

  Matthew Boles

This book is dedicated to my kids Olivia, Haydn, Sydney,

Carrington, and Griffen. It is always hard to take time away from you for such a task as writing. Benjamin Elmore To my wife Laura; you always make me smile.

  Michael Labriola

  Bios Jeff Tapper is the Chief Technologist and CEO for Tapper,

  Nimer and Associates, Inc. He has been developing Internet- based applications since 1995 for a myriad of clients including Morgan Stanley, Doctations, Toys R Us, IBM, Dow Jones, American Express, M&T Bank, Verizon, and many others. He has been developing Flex applications since the earliest days of Flex 1. As an Instructor, Jeff is certified to teach all of Adobe's courses on Flex, ColdFusion, and Flash development. He is also a frequent speaker at Adobe Development Conferences and user groups. Jeff Tapper and Mike Nimer formed Tapper, Nimer and Associates provide expert guidance to rich Internet application development and empower clients through mentoring.

  

James Talbot has been with Adobe (formerly Macromedia) for

  more than six years, on both the sales engineering and training teams, and has most recently been working with Flex and Flash Lite. He has traveled extensively throughout the world promoting Adobe products and certifying Adobe instructors as well as speaking at conferences. James has been an integral team member on high profile rich Internet application consulting assignments for companies such as AOL/Time Warner, JP Morgan, Fidelity, and TV Guide.

  James is actively involved in the Adobe worldwide instructor and developer community, and contributes to developer certification exams as well as organizing and speaking at user groups. James is passionate about Flash on devices as well as rich Internet applications and he believes that both technologies will change the world for the better.

  Matthew Boles is the Technical Lead for the Adobe Customer background in web development, computer networking, and teaching in both professional computer classes and the public schools. In addition to this book, Matthew co-authored a version of the Certified ColdFusion Developer Study Guide. He has also developed official Allaire/Macromedia/Adobe curricula in both ColdFusion and Flash development content areas.

  

Benjamin Elmore is the founder and principal partner of Twin

  Technologies, an enterprise consulting company that specializes in delivering rich Internet applications for Fortune 500 companies. Ben has been working in the RIA/Web 2.0 spaces since its inception and has authored several books on a variety of technologies. Ben founded Twin Technologies with a core principle of embracing a shared knowledge base within the development community. When leading Twin Technologies, Ben travels to Africa and Turkey to speak on leadership on behalf of the EQUIP organization ( ), whose goal is to raise a million Christian leaders over five years. A devoted family man, Ben lives with his wife Mary and their five children in upstate New York.

  Michael Labriola, who has devoted a decade and a half to

  Internet technologies, is a Senior Consultant and Project Lead for Digital Primates, Inc. He spends his mornings teaching developers to work with Flex; his afternoons creating rich Internet applications that generate significant ROI for clients; and his nights dreaming up ways to use Flex that its designers never intended.

  Acknowledgments

  I would like to thank Matt, James, Ben, and Mike for all their hard work, which has helped shape this book. Special thanks go to the team at Adobe/Macromedia, which has made this all possible, especially the efforts of David Mendels, Phil Costa, and Mike Nimerall of whom have offered invaluable advice during this process. Thanks to Tad Staley of Adobe consulting, who has given me more opportunities than anyone else to work on Flex projects. I would also like to acknowledge Doctations and the IT Reference Data department at Morgan Stanley, clients whose Flex 2 projects coincided with the writing of this book. This book couldn't possibly have been written without the lessons I learned on their projects, nor could their projects have been successfully completed without my work on this book. Thanks to the editorial staff at Adobe Press, who was faced with the Herculean task of making our writings intelligible. Finally, thanks to the 2004 World Series Champion Boston Red Sox. Jeff Tapper This book has consumed many, many hours and sleepless nights, but it is all due to the incredible efforts of Jeff, Matt, Ben, and Michael. I would like to thank each one of them and offer a special thanks to Michael and Robyn. This book could not have been a success without the incredible steadfastness of both Michael and Robyn, who demonstrated incredible eagle eyes and never wavered in their resolve to publish the very best. Thanks to everyone at Adobe, including David Mendels, Sho Kuwamoto, Eric Anderson, Phil Costa, and everyone else on the Flex and training team, whose efforts allowed me to have time to work on this book. James Talbot Getting this book finished has been a long and arduous road, and I could not have completed the journey without Jeff, James, Mike, Ben, and Robyn. I hope Mike can forgive me for getting him involved in a project that has taken much more time than either of us could have ever imagined. I also hope Robyn can forgive all of the authors for making this such a long project. Josh and the rest of the gang at Digital Primates deserve kudos for the work they have done in testing this book. Thanks also to Dave Mendels, Phil Costa, Sho Kuwamoto, Heidi Williams, and the rest of the Flex and Flex Builder teams for building great products and helping me understand them. Also thanks to Bob Tierney and Kevin Hoyt for giving doses of reality Flex when needed. Matthew Boles I heard someone once say that the best part of writing is when it is over and you get to see the benefit of your labor. My part in this book was a simple one and I would like to acknowledge the great work done by my co- authors who shouldered the largest share. Thank you for the opportunity to assist with the book; it was a pleasure. At a recent technology get-together I ran into my first mentor, Greg Fisher. My experience in life has shown me that you can either hoard or share your knowledge with those around you. I am grateful for your willingness so many years ago to choose to invest and share with me.

affection. Benjamin Elmore I would like to thank Matt, Jeff, James, and Ben for their work and dedication to bringing this project together.

  Thanks to Robyn for her diligence, understanding and patience during the process. Thanks to Josh, Jim, and Peter of the Digital Primates' team for hours of reading, running code, supporting my half-thought-out ideas, and generally being great friends and colleagues. Thanks to Shirl for her candor and counsel, and specifically for pushing me in this direction. Thanks to Matt for inviting me to join this project and team. Thanks to my family for the encouragement they always provide. Finally, thanks to my wife Laura, who supports my craziest ideas with a smile and a lot of understanding.

  Michael Labriola

  Introduction

  It's just a few short years since Macromedia coined the term

  rich Internet application. Back then, the idea felt somewhat

  futuristic, but all that has changed. rich Internet applications (or RIAs, as we affectionately refer to them) are reality and they are here right now.

  Macromedia released Flex a couple of years ago, making it possible for developers to write applications that take advantage of the incredibly prevalent Flash platform. These applications don't just look great; they also are truly portable, can be fully accessible, and (most importantly) dramatically change the end user experience replacing the page request model of the web to something far more elegant and usable. Something richer. Numerous organizations have discovered the benefits of Flex and have successfully built and deployed applications that run on top of the Flash platform. The highest profile of these is Yahoo!, which created the next generation of Yahoo! Maps in Flex. But despite the early Flex successes, Flex 1 was most definitely not a mass market product. Pricing, tooling, deployment options, and more meant that Flex 1 was targeted specifically for larger and more-complex applications, as well as for more-sophisticated developers and development. But this has now changed.

  Now part of the Adobe family, Flex 2 was released mid 2006a brand new Flex with a new integrated development environment (IDE), new pricing, new deployment options, a new scripting language, and a brand new Flash Player too. Flex 2 is most definitely a mass market product, designed to bring the values and benefits of RIAs to all developers. learn (especially when Flex Builder writes many of them for you). ActionScript has a steeper learning curve, but developers with prior programming and scripting experience will pick it up easily. But there is more to Flex development than MXML and ActionScript. There are many things that need to be understood to be a successful Flex developer, including the following:

  How Flex applications should be built (and how they should not) Relationships between MXML and ActionScript, and when to use each Various ways to interact with back-end data, and the differences between each How to use the Flex components, and know how to write their own Performance implications of the code they write and how it is written Best practices to write code that is scalable and manageable and reusable (there is definitely more to Flex than MXML and ActionScript)

  And this is where this book comes in. Matthew Boles, James Talbot, and Jeff Tapper (ably assisted by Benjamin Elmore and Michael Labriola) have distilled their hard-earned Flex expertise into a series of lessons that will jump-start your own Flex development. Starting with the basics and then incrementally ensuring success at every step of the way. Flex 2 is powerful, highly capable, fun, and incredibly addictive, too. And Adobe Flex 2: Training from the Source is the ideal tour guide on your journey to the next generation of application development.

  Enjoy the ride! Ben Forta SeniorTechnical Evangelist Adobe Systems, Inc.

  Prerequisites

  To make the most of this course, you should at the very least understand web terminology. This book isn't designed to teach you anything more than Flex, so the better your understanding of the World Wide Web, the better off you'll be. This book is written assuming that you are comfortable working with programming languages and are probably working with a server-side language such as Java, .Net, PHP, ColdFusion, or a similar technology. Although knowledge of server-side technologies is not required to succeed with this book, there are many comparisons and analogies made to server-side web programming. This book is not intended as an introduction to programming or as an introduction to object-oriented programming (OOP). Experience with OOP is not required, although if you have no programming experience at all, you might find the materials too advanced.

  Outline

  As you'll soon discover, this book mirrors real-world practices as attempt has been made to inform you. The exercises are designed to get you using the tools and the interface quickly so that you can begin to work on projects of your own with as smooth a transition as possible.

  This curriculum should take approximately 3840 hours to complete and includes the following lessons:

   : Getting Started : Using Simple Controls : Using Remote XML Data with Controls : Using Controls and Repeaters with Data Sets : Creating Custom Components with ActionScript 3.0

: Using Drag and Drop : Using Formatters and Validators : Using the History Manager

   : Charting Data : Pushing Data with Adobe Flex Data Services

: Creating Transitions and Behaviors : Using Shared Objects Setup Instructions Technical Notes

  Before getting started, you should follow the setup instructions in the appendix to ensure that you have the environment set up properly for use with this book. Much of the data for the hands-on tasks is retrieved from

   Of course, you must have an Internet

  connection to access this site. In lieu of this, you can start the

   to http://localhost:8300/ and

  access the data locally. For example, in "Using Remote XML Data with Controls," simply replace

   with

  http://localhost:8300/units.xml to access the same XML data

  Throughout the book, we use this wording: "Data type the function as void" or "Data type the function as String." This is just to make the instructions simpler; the authors realize the function itself is not data typedwhat is really being data typed is the value the function returns.

  Who Is this Book For?

  Macintosh and Windows users of Flex Builder 2 can complete all

  

• however, cover

  Flex Data Services, which only runs under Windows. Macintosh users can continue with those Chapters if they have access to a Flex Data server running on a separate machine. Setting up that server and connecting to it is, alas, beyond the scope of this book.

  The Project Application Adobe Flex 2: Training from the Source includes many

  comprehensive tutorials designed to show you how to create a complete application using Flex 2. This application is an "online grocery store" that displays data and images and then submits completed orders to the server. It includes an executive Dashboard to enable store managers to view real-time graphs showing sales details, as well as a data-entry application for adding or editing the products sold by the grocery. By the end of 25 hands-on lessons, you will have built an entire web site using Flex. You will begin by learning the fundamentals of Flex and understanding how Flex Builder can be used to aid in developing applications. In the early lessons, you will make use of Design mode to begin laying out the application, but as you progress through the book and become more comfortable with the languages used by Flex, you will spend more and more fully comfortable working with the Flex languages and can probably work even without Flex Builder by using the freely available Flex 2 SDK and command-line compiler.

  Standard Elements in the Book

  Each lesson in this book begins by outlining the major focus of the lesson at hand and introducing new features. Learning objectives and the approximate time needed to complete all the exercises are also listed at the beginning of each lesson. The projects are divided into exercises that explain the importance of each skill you learn. Every lesson will build on the concepts and techniques used in the previous lessons.

  Tips ( ): Alternative ways to perform tasks and suggestions to consider when applying the skills you are learning.

  

Notes ( ): Additional background information to expand your

  knowledge and advanced techniques you can explore to further develop your skills.

  Cautions ( ): Information warning you of situations you

  might encounter that could cause errors, problems, or unexpected results.

  Boldface text: Words that appear in boldface are terms that you must type while working through the steps in the lessons. Boldface code: Lines of code that appear in boldface within

  code blocks help you easily identify changes in the block that you are to make in a specific step in a task.

  <mx:HorizontalList dataProvider="{dp}" labelFunction="multiDisplay" columnWidth="130"

  Code in text: Code or keywords appear slightly different from the rest of the text so you can identify them.

  To help you easily identify ActionScript, XML, and HTML code within the book, the code has been styled in a special font that's unique from the rest of the text. Single lines of code that are longer than the margins of the page allow wrap to the next line. They are designated by an arrow at the beginning of the continuation of a broken line and are indented under the line from which they continue. For example:

   public function Product (_catID:Number, _prodName:String, _unitID:Number, _cost:Number,

_listPrice:Number, _description:String, _isOrganic:Boolean, _isLowFat:Boolean, _imageName

  :String) Italicized text: Words that appear in italics are either for emphasis or are new vocabulary.

  Italics are also used on placeholders, in which the exact entry may change depending upon your situation. For example:

  driveroot:/flex2tfs/flexGrocer, where the driveroot is dependent upon your operating system.

  Menu commands and keyboard shortcuts: There are often

  multiple ways to perform the same task in Flash. The different options will be pointed out in each lesson. Menu commands are shown with angle brackets between the menu names and commands: Menu > Command > Subcommand. Keyboard shortcuts are shown with a plus sign between the names of keys to indicate that you should press the keys simultaneously;

  

Appendix: This book includes one appendix that will guide you

  through the steps to set up the working environment required to execute the exercises in this book.

  

CD-ROM: The CD-ROM included with this book includes all the

  media files, starting files, and completed projects for each of the lessons in the book. These files are located in the assets, start, or complete directories, respectively. "Understanding Rich Internet Applications," does not include tasks; however, the CD-ROM includes media in the directory

  

This media provides the flexGrocer directory for your

  project. At any point you need to return to the original source material, you can restore the flexGrocer. Some lessons include an intermediate directory, which contains files in various stages of development in the lesson. Any time you want to reference one of the files being built in a lesson to verify that you are correctly executing the steps in the exercises, you will find the files organized on the CD-ROM under the corresponding lesson. For example, the files for folder.

  The directory structure of the lessons you will be working with is as follows:

  [View full size image]

  Adobe Training from the Source

  The Adobe Training from the Source and Advanced Training

  

from the Source series are developed in association with Adobe

  and reviewed by the product support teams. Ideal for active learners, the books in the Training from the Source series offer hands-on instruction designed to provide you with a solid grounding in the program's fundamentals. If you learn best by doing, this is the series for you. Each Training from the Source title contains hours of instruction on Adobe software products. They are designed to teach the techniques that you need to create sophisticated professional-level projects. Each book includes a CD-ROM that contains all the files used in the lessons, completed projects for comparison, and more.

  Adobe Authorized Training and Certification through the Adobe Authorized Training Partner program. Get up to speed in a matter of days with task-oriented courses taught by Adobe Certified Instructors. Or learn on your own with interactive online training from Adobe University. All these sources of training will prepare you to become an Adobe Certified Developer.

  For more information about authorized training and certification, check out

  What You Will Learn

  You will develop the skills you need to create and maintain your own Flex applications as you work through these lessons.

  By the end of the course, you will be able to:

  Use Flex Builder to build Flex applications Understand MXML, ActionScript 3.0, and the interactions of the two Work with complex sets of data Load data from a server using XML, web services, and Remote objects Handle events to allow interactivity in an application Create your own custom events Create your own components, in either MXML or ActionScript 3.0 application Add charts to an application And much more...

  Minimum System Requirements Windows

  Intel Pentium 4 processor Microsoft Windows XP with Service Pack 2, Windows XP Professional, Windows 2000 Server, Windows 2000 Pro, or Windows Server 2003 512MB of RAM (1GB recommended) 700MB of available hard-disk space Java Virtual Machine: Sun JRE 1.4.2, Sun JRE 1.5, IBM JRE

  1.4.2 Macintosh Flex Builder for Macintosh is not available at the time this book went to the printers, but is expected shortly.

  The Flex line of products is extremely exciting, and we're waiting to be amazed by what you will do with it. With a strong foundation in Flex, you can grow and expand your skillset quickly. Flex is really not too difficult to use for anyone with own custom applications and sites in no time.

  

Lesson 1. Understanding Rich Internet

Applications What You Will Learn In this lesson, you will:

  Explore alternatives to a page-based architecture See the benefits of rich Internet applications (RIAs) Compare the RIA technologies available

  Approximate Time This lesson takes approximately 30 minutes to complete. Lesson Files Media Files:

  None Starting Files:

  None

  None Computers have been playing a role in the business environment for more than four decades. Throughout that time, the roles of the client and server have been constantly evolving. 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 the new demands. This evolving process continues today, as businesses are demanding faster, lighter, and richer Internet applications. In this lesson, you will learn about this evolving nature and understand the business requirements that push us to build rich Internet applications (RIAs).

  

You will use Flex to build the FlexGrocer application seen

here.

  [View full size image]

  Understanding the Evolution of Computer Applications

  In the earliest days of computerized business applications, all processing took place on mainframes, with the client having no role other than to display information from the server and accept user input. This was largely dictated by the high cost of processing power. It simply was not affordable to spread powerful clients throughout the enterprise, 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 available, more desktop

  applications, such as word processors and spreadsheets, could

  run stand-alone, so no server was necessary. One challenge faced by organizations with microcomputers was a lack of centralized data. Although the mainframe era had everything centralized, the age of the microcomputer distributed everything, adding many challenges for centralizing business rules and synchronizing 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 for business logic and data to be stored and accessed from a centralized locationwhich solved the problems of the day. The new challenge introduced with the client/server systems was distribution. Any time changes needed to be made to client applications, IT departments had to manually reinstall or upgrade the software 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. This model worked by having a web browser act as a thin client, whose primary job was to render HTML and 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 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, 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 surrounded the user interface (UI). Many of the conveniences that end users grew to accept over the previous decade were lost, and the UI was limited by the capabilities of HTML.

  For example, desktop software as well as client/server applications frequently use the drag-and-drop feature. However, HTML (Hypertext Markup Language) applications almost never use the feature, due to the complexities and lack of cross- browser support for the DHTML (Dynamic HTML), which it requires to implement in a pure HTML/DHTML solution.

  In most cases the overall sophistication of the 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

  Today, the demands for Internet-based applications continue to grow and are often quite different from the demands of the mid-1990s. End users and businesses are demanding more from their investments in Internet technology. The capability to deliver true value to users is forcing many companies to look toward richer models for Internet applications; models that combine the media-rich power of the traditional desktop with the deployment and content-rich nature of web applications.

  As Internet applications begin to be used for core business functionality, 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 therefore they are 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, service-

  oriented architecture (SOA) became more feasible for web- based applications.

  To meet the demands of businesses, RIAs should be able to do the following: Provide an efficient, high-performance run time for executing code, content, and communications. In the next section of this lesson, you will explore the limitations of the standard HTML-based applications, and learn that the 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 browser support. Building RIAs with these tools so they will work on a variety of browsers and operating systems involves building multiple versions of the same application. Enable using server-side objects through using Web Services or other 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.

  Enable use of the applications when "offline." As laptops and other portable devices continue to grow in popularity, one of the serious limitations of Internet applications is the requirement that the machine running the application be 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 currently possible. A successful RIA should enable users to be productive with or without an active connection.

  Breaking away from the 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 which server-side technologies (if any) are used, the flow goes something like this:

  1. User opens a browser and requests a page from a web server.

  2. Web server receives request.

3. (optional) Web server hands request to an application server

  to dynamically assemble page or

4. (optional) Web server retrieves static page from file system.

  

5. Web server sends page (dynamic or static) back to browser.

  6. Browser draws page in place of whatever was previously displayed.

  Even in situations 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 loading in the browser. One of the key goals of RIAs is to reduce the amount of extra data the page the user is viewing? This is the way standard desktop or client/server applications work. Although this goal seems simple and is readily accepted by developers taking their first plunge into RIA development, often web developers bring a page-based mindset to RIA applications and struggle to understand how to face the challenges from the page-based world, such as, how to "maintain state." For example, after users log in, how do we 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, in which each request to the server was an atomic unit that knew nothing about previous requests. This stateless nature of the web allowed for greater efficiency and redundancy because a connection did not need to be held open between the 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 far more simultaneous requests. 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 was 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 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.

  Identifying 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 needs to demonstrate real return on investment and truly add value. RIAs achieve this on several levels: they reduce development costs; and add value throughout the organization.

  Business Managers

  By making it easier for users to work with software, the number of successful transactions is increasing. This increase occurs across many industries and can be quantified by businesses with metrics, such as increased productivity using intranet applications or increased percentage of online shoppers who complete a purchase. More productive employees can drastically reduce labor costs while growing online sales increase revenue and decrease opportunities lost to competitors.

  IT Organizations

  Breaking away from page-based architectures reduces the load on web servers and reduces the overall network traffic. Rather than transmitting entire pages over and over again, the entire application is downloaded once, and then the only communication back and forth with the server is the data to be presented on the page. By reducing server load and network traffic, infrastructure costs can be noticeably lower. RIAs application, as well as greatly reduce the development time to build the application.

  End Users

  End users experience the greatest benefits of RIAs. A well- designed RIA greatly reduces users' frustration levels because they no longer need to navigate several pages to find what they need nor have to wait for a new page to load before continuing to be productive. Additionally, the time users spend learning how to use the application can be greatly reduced, further empowering them. Today, there are a number of excellent applications, which would not be possible without the concepts of an RIA, such as the Harley Davidson Motorcycle Configurator and the Kodak EasyShare Gallery applications. These easy to use applications give an excellent example of the ease of use an RIA can offer an end user.

  RIA Technologies

  Today, there are several technology choices developers have when they start building RIAs. Among the more popular choices are HTML-based options, such as Ajax (Asynchronous Javascript and XML), as well as plug-in-based options such as Adobe Flash, Adobe Flex, and Laszlo which all run in Flash Player. A new option from Microsoft seems to be on the horizon because the Microsoft channels are abuzz with talk of XAML and the Windows Presentation Foundation.

  There are four different run times on which the current RIA landscape is based. Those are Ajax, which is supported by Dojo, OpenRico, Backbase and the Yahoo ToolKit; Flash Player, which is used by Flex and Laszlo; Windows Presentation Foundation (WPF), which is Microsoft's not yet released platform; and Java, which is used by AWT, Swing, and Eclipse RCP. It seems that both the Java and WPF solutions are taking aim at desktop applications, rather than RIAs although they could be used for RIAs as well.

  Asynchronous Javascript and XML (Ajax)

  One of the easier choices to understand (but not necessarily to implement) is Ajax, which is an acronym for Asynchronous

  Javascript and XML. Ajax 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 structure by manipulating the HTML DOM without reloading a new page. Updates may involve new data that is loaded from the server in

  The earliest forms used Java applets for remote communication. As browser technologies developed, other means, such as the use of IFrames, replaced the applets. In recent years,

  XMLHttpRequest was introduced into JavaScript, providing a means to facilitate data transfers without the need for a new page request, applet, or IFrame. In addition to the benefit of Ajax using elements already familiar to many web application developers, Ajax requires no external plug-in to run. It works purely on the browser's capability to use JavaScript and DHTML. However, the reliance on JavaScript poses one of the new liabilities of Ajax: it fails to work if the user has JavaScript disabled 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. For applications in which the target audience can be controlled (such as intranet applications), Ajax can be written to support a single browser on a particular platform (many businesses today have standardized browsers and operating systems). However, when applications are opened to larger audiences (such as extranet and Internet applications), Ajax applications need to be tested (and often modified) to ensure that they run identically in all browsers on all operating systems. Ajax is not likely to go away any time soon, and each day more and more high-profile Ajax applications are launched with great acclaim (such as Google Maps). It should be noted that Ajax is not actually a programming model in and of itself. It is really a collection of various JavaScript libraries. Some of these libraries include reusable components designed to make common tasks easier. Although Ajax lacks a centralized vendor, integrating these libraries introduces dependencies on third parties, which assumes a

  Flash

  One of the key competitive run times in the RIA space is Adobe's Flash Platform. The Flash Platform is currently the key competitor to Ajax for RIAs. Originally written as a plug-in to run animations, Flash Player has evolved over the years, with each new version adding new capabilities while still maintaining a very small footprint. Over the past decade, Flash Player has gained near ubiquity, with some version of it installed in more than 97 percent of all web browsers on the Internet. Since 2002, Macromedia (now part of Adobe) began focusing on Flash as more than an animation tool. And with the Flash 6 release, Macromedia began to provide more capabilities for building applications. Macromedia found that with the combination of the ubiquity of the player and the power available from its scripting language (ActionScript), developers could 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 is that content and applications developed for any particular version of Flash Player will (usually) run on any platform/browser that supported that version of the player. With very few exceptions, it remains true today. Historically, the biggest drawback of building applications for the Flash Player was the authoring environment, which was clearly built as an animation tool for users creating interactive content. Many developers who wanted to build RIAs for Flash Player were thwarted by the unfamiliarity of the tools. This, coupled with the scant materials available in 2002 for learning to use Flash as an application platform, kept many serious developers from successfully building Flash applications. greatly simplified the development process and reduced the number of RIAs developed directly in Flash Studio.

  Laszlo

  Sensing the need for more developer-friendly tools for building RIAs, Laszlo Systems developed a language and compiler that enabled developers to work with familiar languages from which their compiler could create applications to run in Flash Player.

  Just like Ajax, Laszlo applications are built in JavaScript and

  XML, but they run in Flash Player, so they make available the rich-user experiences of a desktop client along with the deployment benefits of traditional web applications. Flash Player also gives the capability to run on virtually every web browser regardless of the operating system. Unlike Ajax applications, Laszlo uses a compiler that takes the XML and JavaScript and then publishes a Flash SWF file from them. This allows developers freedom from varying levels of JavaScript support across different platforms.