Andrew Shorten

The BBC today launched their second desktop widget built using Flex and deployed on AIR to deliver updated news coverage from the Olympics and to provide desktop alerts for when Olympic events are starting.

Following on from the beta launch of BBC LiveUpdate two weeks ago (which was released whilst I was on holiday, so I’ll link you to Serge Jespers for details of that application), the BBC Sport “Monkey Widget” is an integral part of the BBC’s coverage for the 2008 Olympics, alongside their website, interactive TV, broadcast and mobile outputs.

Once downloaded and installed (which is made really easy by the use of the AIR installer badge on their site), you can customize the application to use one of three cartoon characters the BBC have designed for their Olympics coverage and select up to 5 different sports that you want to follow, alongside general news stories from the Olympics.

The BBC’s use of AIR really demonstrates the advantages that Adobe’s platform provides - firstly, unlike previous BBC desktop widgets which were Windows-only, these applications work on Mac and Windows (and soon Linux, although you can try to run the application today using the alpha version of AIR for Linux), and secondly AIR has allowed the BBC’s existing web designers and developers, using technologies they already know, like Flash and Flex, to build and deploy these desktop applications internally, something they previously had to rely upon third parties with specialist skills for.

Whilst taking about the BBC’s Olympics coverage, it’s worth noting that live video from the Olympics will be available through the BBC website, with a choice from up to seven video streams simulcast from BBC TV; highlights from each day’s action will be available through the BBC’s iPlayer service. All the video content will be streamed using Flash Player, but will only be available in the UK due to distribution rights.

It’s really great to see the rapid innovation coming out of the BBC using Flash, Flex and AIR - I look forward to seeing what they do next with AIR!

If you live in the UK you’ll be familiar with The Sun newspaper, if you’re not then Wikipedia will help you out, but it’s one of the most popular tabloid newspapers in the UK with nearly 8 million readers every day.

Since the 1970’s The Sun has had a ‘feature’ on page 3 which seems to be very popular with a large percentage of the UK male population - the page 3 model. I won’t go into all the details here, but you’ll get a good idea by visiting the official Page 3 website (warning: some nudity).

The Sun is today launching a new desktop application, created using Flex and deployed on AIR, that features one of their most popular models, Keeley, 21, from Bromley.

To quote from The Sun’s website “BE the envy of all your friends and get Page 3’s sexy Keeley Hazell on your desktop now! Gorgeous Keeley is here to ease you through your day, putting a smile on your face and providing up to the minute sport info, showbiz gossip and news updates direct to your desktop.”

Yes, it’s a another RSS news reader, but the team at Glue London who created Desktop Keeley have done a really nice job on this, creating a slick-looking application that uses transparent video to provide users with a little extra something… to see this in action you can select the “Come out to play” option from the menu.

If you’re installing this at work then you’ll need to make it clear, like I have, that this is for ‘research purposes’ When I showed the application to my fellow evangelists back on the onAIR tour, they too seemed pretty keen on Keeley; again, for research purposes you understand.

So, could this be one of the most popular AIR applications…? Keeley has quite a following, so just maybe it could. You can download the application from The Sun’s website.

As part of the recent European onAIR tour I presented a session on building data-intensive AIR applications - the aim of this follow-up series of three blog posts is to highlight some of the options available for incorporating data in your Flex applications, either in the browser or when running as a desktop-based application.

What is a data-intensive RIA?

There will no doubt be differing views on the exact definition of a data-intensive RIA; if however, we consider the scenarios where basic data exchange using XML over HTTP or SOAP-based web-services fail to provide the performance or functionality required to deliver a rich, engaging online experience, then these are likely to be good candidates for applications that can be described as data intensive.

So, what are the scenarios where basic data exchange doesn’t always meet our requirements? Well, what if we need to consume large amounts of data in our application; maybe thousands or tens of thousands of records need to be available on the client-side and it’s taking a long time to retrieve, parse and display the data? Or, what if our data is changing rapidly and the client-side application always needs to display the most up-to-date information? And finally, what if we need to ensure that information entered into our application is always in-sync with the server, including scenarios where the end-user is making changes to data when offline.

Over the course of these posts I’ll explore each of these scenarios, introduce BlazeDS and LiveCycle Data Services and explain how they can be used to overcome the limitations of using basic HTTP and SOAP data exchange for data-intensive applications. If you want to view or download the slides from my onAIR tour presentation, these are posted below:

Introducing BlazeDS and other comparable technologies

BlazeDS provides server-based Java remoting and web messaging technology, is free and open source, and can be highly scaled by moving your application to LiveCycle Data Services (LCDS) at a later point in time. If you’re using ColdFusion then you can use the LCDS server that comes installed with ColdFusion, or swap it out for BlazeDS (although for this post, you don’t need BlazeDS or LCDS as you use remoting straight out of the box with ColdFusion CFCs). If you’re using .NET, PHP or Ruby as your back-end then you might want to take a look at WEBOrb, which provides an alternative implementation of the remoting and web messaging technology in BlazeDS.

Installing BlazeDS

Assuming that you want to follow along and use BlazeDS, you’ll need to download and install it by following these steps:

1. Grab the BlazeDS turnkey install at http://opensource.adobe.com/wiki/display/blazeds/Release+Builds
2. Unzip it somewhere convenient (referred to as {install} below)
3a. On Mac OS X: start the server from the Terminal by moving to the {install}/tomcat/bin/ directory and typing ./startup.sh
3b. On Windows: start the server from the Command Line by moving to the {install}/tomcat/bin/ directory and typing startup.bat
4. Test that your BlazeDS install has worked by going to http://localhost:8400/samples/ in your preferred browser
5. Start the sample database that comes with BlazeDS by moving to the {install}/tomcat/sampledb/ and typing ./startdb.sh on Mac OS X or startdb.bat on Windows.

If something went wrong then please check the release notes and installation guide.

Using Remoting Services for data exchange

Let’s start in this post by looking at using BlazeDS to transfer data from the server to our Flex application. The amount of time it takes to generate, transfer, parse and render the data becomes increasingly important as the amount of data we consume in our application increases; the efficiency of the data transfer from a bandwidth perspective can also become a concern.

To demonstrate these issues, fellow evangelist James Ward created an application which provides benchmarks for loading data into Rich Internet Applications. Try using his ‘Census‘ tool to load 10,000 rows of data into Flex, firstly using XML (E4X) and then using AMF (the binary data format used within BlazeDS) - you should see a marked reduction in the time taken to retrieve/display data and the bandwidth consumed when using AMF.

Assuming that you’ve been using the HTTPService or WebService tags within your Flex application, you’ll need to make some changes to your application to make use of BlazeDS remoting and the AMF data format. With the RemoteObject tag in Flex, and BlazeDS installed on the server, you can directly invoke methods of Java objects deployed in your application server and consume the return value - which could be a primitive data type, an object, a collection of objects or an object graph.

Taking the Remoting example included within the BlazeDS Test Drive (at http://localhost:8400/samples/testdrive.htm if you installed BlazeDS as per the instructions above), we can see the following client-side code is used to invoke the getProducts method, the result of which is bound to a DataGrid component:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" backgroundColor="#FFFFFF">
	<mx:RemoteObject id="srv" destination="product"/>
	<mx:DataGrid dataProvider="{srv.getProducts.lastResult}" width="100%" height="100%"/> 
	<mx:Button label="Get Data" click="srv.getProducts()"/>
</mx:Application>

You’ll notice that unlike the WebService and HTTPService tags, we’re not defining the WSDL or URL directly in the application, instead we’re referencing a destination called ‘product’.

Using Destinations

BlazeDS and LiveCycle Data Services use a number of configuration files on the server to define destinations - as we’ll see over the course of these posts, destinations are used with remote object invocation, messaging and (in LiveCycle) the data management service. The configuration file that defines the destinations for use with our RemoteObject tag is at {install}/tomcat/webapps/samples/WEB-INF/flex/remoting-config.xml and contains the following definition for the ‘product’ destination:

<destination id="product">
    <properties>
          <source>flex.samples.product.ProductService</source>
    </properties>
</destination>

The destination is mapped to a fully qualified Java class on our application server - by taking this approach, and not defining the physical location of the data in our Flex application, we enable centralized management of data services, improve the security of our application (if your application is decompiled no information about the physical location of data services can be obtained) and increase deployment flexibility (by having the option to change the server-side implementation without updating the physical location within the Flex application).

Typed ActionScript Objects

When receiving data, Java objects are deserialized into either dynamic or typed ActionScript objects depending upon whether you have mapped the appropriate ActionScript class to the Java equivalent. To create typed ActionScript objects you must use a compiler directive within your ActionScript class to define the location of the corresponding Java class, in the format [RemoteClass(alias="packageName.ClassName")].

For a working application which uses this technique examine the “Updating data” sample from the BlazeDS Test Drive (again, at http://localhost:8400/samples/testdrive.htm if you installed BlazeDS as per the instructions above). An example of an ActionScript class mapped to a remote Java class is shown below:

package
{
	[Bindable]
	[RemoteClass(alias="flex.samples.product.Product")]
	public class Product
	{
		public function Product()
		{
		}
 
		public var productId:int;
		public var name:String;
		public var description:String;
		public var image:String;
		public var category:String;
		public var price:Number;
		public var qtyInStock:int;
	}
}

Channels

BlazeDS and LCDS separate out the transfer formats and network protocols used to send/receive data over the network from the destination definition - these are defined as channels within the services-config.xml configuration file on the server. In the case of remote object invocation we are using the default AMF over HTTP channel, but there is also an AMF over HTTPS channel that you could choose to use. If you take a look at the services-config.xml file you’ll notice that the endpoint location is defined as:

	<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>

where server.name, server.port and context.root are all defined dynamically. For browser-based applications these values will be defined at runtime, based on where the SWF file is deployed. For AIR applications, this represents a challenge however, as the endpoint can’t be resolved at runtime from the end user’s desktop; instead, we must programmatically set the endpoint used by the channel, as shown in the example below:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" backgroundColor="#FFFFFF">
	<mx:RemoteObject id="srv" endpoint="http://www.myserver.com/samples/messagebroker/amf" destination="product"/>
	<mx:DataGrid dataProvider="{srv.getProducts.lastResult}" width="100%" height="100%"/> 
	<mx:Button label="Get Data" click="srv.getProducts()"/>
</mx:Application>

An alternative approach is to use the mx.messaging.ChannelSet class to define endpoints; we’ll use this when we look at using messaging and the data management service with AIR applications in a future post.

Summary

That covers the basics for using BlazeDS and AMF to improve the efficiency of consuming data within your Flex application - if you have applications that retrieve large volumes of data then I’d certainly encourage you to try out BlazeDS. More information on this topic can be found on the Adobe Developer Centre and in the Blaze Developer Guide.

Next time I’ll take a look at how we can use the BlazeDS messaging service to ensure our application can display real-time changes to data, as well as to enable collaborative application functionality.

Whilst there are hundreds of publicly available AIR applications that you can download from the AIR showcase, the Adobe AIR Marketplace and other third-party sites, there are some that you might not have seen - the AIR applications that various teams within Adobe are using on a daily basis to improve personal productivity and provide convenient access to internal systems.

I think it’s great that we’re using our own technology to solve business problems - it really demonstrates the capability and robustness of our platform and I hope that by showing some of the applications here, it might provide some inspiration as to how you could use Flex and AIR within your organization or for a customer.

If you’ve attended an Adobe event then you may have seen the Adobe Directory demonstrated - this has to be one of the most useful and widely used tools we have inside Adobe.

Adobe Directory does exactly what it says on the tin - providing convenient desktop access to a directory of all 7,000+ Adobe employees; it works both online and offline, automatically synchronizing local data with our LDAP servers, it can show where an employee sits on an office plan and when connected to the VPN, will show a photo of the employee and their busy/free status using information from Microsoft Exchange. A new version of the application is currently in the works which integrates with ‘Pacifica‘ to provide presence and direct dial capabilities from within the application.

We’ve actually released the source code for a generic version of the directory so that you can build your own company directory application - you can get it here.

Making sure that we provide great customer service and technical support is the job of Adobe’s Worldwide Customer Care organization. To help streamline the process for Adobe employees to request assistance for a customer, the team created the Adobe Customer Care Response Tool - an application that provides a convenient way to submit new issues and track existing support cases.

The tool was built using Flex and is made available as an AIR application, with ColdFusion providing all the necessary back-end services. Given that sales representatives, pre-sales consultants and other field staff are often on the road, the provision of an application that has full offline and data synchronization capabilities makes it far better than a browser-based solution.

Along with evangelists, the other group of Adobe employees who probably spend the most time traveling is the pre-sales team; consultants who support customers who are evaluating Adobe’s solutions, such as Adobe Acrobat Connect Pro and LiveCycle ES. Providing a productive way to capture the interaction a consultant has with a customer, so that the sales, pre-sales and, if necessary, support teams can see what is happening in an account has long been a challenge - with trip reports, either as an email, an entry to a team blog or as a PDF submission process, never quite solving the problem.

To overcome the limitations of trip reports the pre-sales team has recently implemented the Adobe SE Notebook as an AIR application. This application provides a convenient way to record activities, raise issues and submit product enhancement requests, and, as with the Adobe Customer Care tool, this has full offline and data synchronization capabilities, allowing consultants to review and update information whilst on-site with the customer.

The final application I wanted to highlight really plays to Adobe’s strengths - delivering a great experience. The Adobe Presentation Tool provides a way for Adobe’s sales and pre-sales team to deliver more engaging customer presentations - expanding upon the usual PowerPoint slide-ware, to deliver a multi-media rich presentation that leverages Adobe’s technology.

One of the challenges of having a large field organization is ensuring that everyone has the latest version of slides - the Adobe Presentation Tool solves this by automatically updating the core repository of slides available within the application, while still enabling full editing and re-ordering of custom slides so that employees can prepare personalized presentations.

So, that’s a quick round-up of some of the AIR applications we’re using within Adobe. I’m sure there are plenty more I haven’t come across or that are in the works… my vote for the next internal application to be built would have to be for submitting our expenses. Maybe one day

… is a question, that as an evangelist, I’m often asked. As momentum behind Rich Internet Applications continues, with an increasing recognition that there is a need to develop and deploy software applications that can span browser, desktop and device, and a choice of RIA-enabling technology platforms becoming available (from Adobe, Microsoft, Sun, Apple and others), it’s inevitable that more time needs to be spent evaluating technology options for a RIA project.

Undertaking due diligence for the selection of a technology platform is an important part of any project however and one of the challenges can be trying to identify the key differentiators of Adobe’s platform, given the breadth of information available on our site and the array of technology components that make up the platform (Flash Player, Flash Authoring, Flash Lite, AIR, Flex SDK, Flex Builder, BlazeDS, LiveCycle DS, LiveCycle ES, Flash Media Server, etc).

I thought I’d try and boil the answer down to five or six key points that I think should be considered if you’re evaluating Adobe’s platform. My aim was not to reproduce our corporate marketing, but rather distill what has resonated with the customers I’ve been speaking to about our platform; additionally, I thought I’d try and do it without mentioning a whole bunch of individual product names/brands (something which we normally do!). As always, feedback welcome on this via comments.

So, here goes… (relatively lengthy post ahead):

#1 Capabilities

The first, and possibly most important question, when considering RIA technologies, is to evaluate whether Adobe’s runtimes (which exist for browser and desktop) provide the features that you’re going to need on your project.

There are core framework capabilities, such as the provision of visual controls, layout managers, vector graphics rendering, data services, data binding and a robust event model, as well as core runtime attributes, such as small download size, high performance and cross-platform availability, that are required in order to deliver a Rich Internet Application; these will likely be provided by all RIA platforms over time.

So, what unique capabilities does Adobe’s runtime provide?

This is not a definitive list, but comparing the market right now, webcam support, microphone support, bi-directional text, graphics card acceleration, native 3D effects, bitmap manipulation, printing support, H.264 video playback and a high-quality VoIP audio codec are some of the differentiating features that you can take advantage of when building a browser-based RIA on Adobe’s platform *.

In addition, the ability to deploy your RIA using a desktop runtime means that you can access capabilities not offered within the browser environment - including, but not limited to, native windowing, native menus, full filesystem read/write access, client-side database, clipboard access, drag and drop, encrypted local storage, integrated HTML/Flash/PDF rendering, network detection and file-type registration.

#2 Ubiquity

For web-based deployment, convenient, instant-on access to Rich Internet Applications is important - it’s what people expect from using their browser. Should you need to go beyond the capabilities of the browser, you can leverage Adobe’s browser-based runtime, either as a part of an existing AJAX application, or to deliver a complete RIA, confident in the knowledge that it’s already deployed to 98% of Internet-connected computers.

As demand for richer, more engaging applications continues, Adobe is uniquely positioned to be able to “update the web” through the rapid distribution of our browser-based runtime - the latest version of which achieved 63% availability on Internet-connected computers within just three months. Additionally, Adobe builds and simultaneously ships this for Windows, Mac and Linux desktops, providing a consistent and supported runtime across these different operating systems.

#3 Deployment Flexibility

Whilst the browser represents one way to access Rich Internet Applications, we have an opportunity to further enrich the user’s experience by considering the most convenient and appropriate medium upon which to offer applications, content and services.

Adobe’s desktop runtime removes some of the restrictions imposed by the browser, enabling RIAs that persist on the user’s desktop, have fully-customized user interfaces, offer convenient desktop functionality (such as drag/drop, cut and paste and pop-up notifications) and can access both local and remote data.

The ability to build web and desktop applications, from a single code base, using either Adobe’s RIA development framework or AJAX frameworks, means that the barrier to creating desktop applications has been lowered significantly; and, just as with our browser-based runtime, these desktop applications can be deployed consistently to Windows, Mac and Linux operating systems **.

Going forward, as part of the Open Screen Project, Adobe has committed to delivering consistent runtimes across not just browser and desktop, but mobile phones and other consumer electronics devices.

#4 Proven Technology

Adobe’s RIA development framework has been in the marketplace for nearly four years, over which time we’ve seen a significant number of Rich Internet Applications be deployed by customers - the best place to see several hundred examples of these is at our showcase site.

We’ve made a significant investment in building a RIA platform, and so we’re also leveraging this to provide the next generation of Adobe software and services - from Photoshop Express to Adobe Media Player and the recently launched Acrobat.com applications, all of which are great examples of highly scaled, highly available applications distributed over the web.

#5 Expressiveness

The word rich in the term RIA is notoriously hard to define; while richness can be influenced by the convenience, relevance or satisfaction experienced from using an application, there is no doubt however that visual expressiveness is a huge part of what helps us differentiate an RIA from other web-based applications.

Adobe is continuing to lead the way in defining the expressiveness of applications that can be deployed over the web; with the next release of our runtimes adding features such as 3D effects, programmable graphics filters, advanced text layout and hardware acceleration, we’ll see rich and immersive online experiences that simply aren’t possible today. In addition, we’re continuing to work on exposing new features, tools and workflows to designers using Adobe Creative Suite, so that they can fully participate in the creation of Rich Internet Applications.

#6 Openness

Adobe is committed to supporting open source activities; contributing to existing projects such as SQLite, WebKit and Eclipse, ensuring our runtimes are available on open source platforms and delivering key RIA components (such as the development framework, the virtual machine used in our runtimes, and our remoting and messaging technologies) as open source code. In addition, Adobe has also released the specifications for a number of file formats and communication protocols so that third parties can build tools, runtimes and servers that utilize these formats.

As part of the Open Screen Project Adobe is working with a number of industry partners to ensure that we can extend our browser and desktop runtimes to mobile phones and consumer electronics devices; as part of this initiative, Adobe removed all licensing costs for deploying these runtimes and removed licensing restrictions for several key formats, including SWF.

#7 Innovation

With a history of disruptive innovation, I’m pleased to see that Adobe is continuing to lead the way in the RIA market. Sure, there’s always more work we can do to improve designer/developer workflow, fix bugs, improve documentation, etc, (all of which we’re doing), but who else right now is building large-scale RIAs with their own technology and exposing it to millions of customers, who else is extending the reach of RIAs to the desktop so that they work across different operating systems and who else is enabling enterprise-level RIAs with support for real-time collaboration, data push and online/offline data synchronization?

There’s lots more to do as we work with customers to define the next generation of software, and we’re always looking for feedback, bugs and participation to help us get there.

So, now you know why I think Adobe’s platform is a great choice for building RIAs, I encourage you to join the thriving development community, download an SDK or two and start building an application :)

* includes Flash Player 10 features.
** Linux version currently available as a pre-release, due for final release before end 2008