Andrew Shorten @ Adobe

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:

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:

          flex.samples.product.ProductService
    

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:

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:

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.