Flash Platform 2009 – Year in Review – Part 3

In part 1 of the year in review I talked about some of the great applications and content that have been created on top of the Flash Platform. In part 2 I talked about the partnerships and what that has enabled this year. Now I’m going to turn to the tools and technologies from Adobe. When I look back at my own personal history with Flex and the Flash Platform, coming with Flex 1.5 and Flash Player 7, it’s amazing to see the progress we made this year.

The biggest news came at MAX. We provided beta versions of Flash Builder 4, Flash Catalyst, and ColdFusion Builder. Three tools that cover a broad spectrum of RIA development. Flash Builder 4 built on top of our momentum with Flex Builder and introduced a new data-centric development methodology as well as some long-asked for productivity enhancements. Flash Catalyst is a completely new tool that lets designers bring in designs from Photoshop and Illustrator and turn them into working, interactive Flash content without writing any code. And of course ColdFusion Builder provided ColdFusion developers an Eclipse-baesd tool from Adobe that works seamlessly with Flash Builder and lets ColdFusion developers quickly work on ColdFusion and HTML projects. The three tools work together to let designers and developers collaborate around all parts of an RIA project. And the next generation of Flash Professional also got a sneak peak at MAX with the announcement that Flash CS5 will support creation of native iPhone applications.

We also started to lay out our vision for services at Adobe in 2009. Before and during MAX we provided betas and some new information about the Adobe Flash Platform Services. This includes things like LiveCycle Collaboration Services which lets you easily add real-time collaboration components to your Flex and Flash applications. We debuted a Distribution service that lets you track and distribute Flash content across a number of popular properties. There was also the Try/Buy service codenamed “Shibuya” which will help Flash developers directly make money from what they build on the Flash Platform.

Both of our runtimes, AIR and Flash Player, saw beta versions of the next generation. We provided beta access to Adobe AIR 2 which provides developers a lot more access to native functionality as well as adding next-generation HTML support and performance optimizations. Developers had access to a beta of Flash Player 10.1 later in the year which is the first version of Flash Player that is intended for smart phones. Developers got to see how this version of the player would run on the desktop with new memory optimization and support for multi-touch gestures. Flash Player 10.1 will be released for Mac, Windows, Linux, and smart phones like the Palm Pre and Google Android later this year.

Adobe was also busy in the server space. ColdFusion 9 was released this year and it included much deeper support for Flex and AIR applications as well as the ability to tightly integrate with Microsoft Office documents (including SharePoint) and some nice code enhancement for long-time ColdFusion developers.

And finally, this was a big year in openness for the Flash Platform. We’ve worked hard to keep the Flash Platform as open as possible by doing things like open sourcing the Tamarin virtual machine and providing the SWF and AMF specifications in addition to contributing to existing open source projects like the Eclipse foundation. This year we open sourced two new projects, the Open Source Media Framework and the Text Layout Framework. The Open Source Media Framework (OSMF) provided a standard way to create and extend the way video content plays on the Flash Platform. The Text Layout Framework (TLF) brought world-class text capability to the Flash Platform. It included support for right-to-left languages like Hebrew and Arabic and gave developers very detailed control over exactly how text was rendered by the Flash Player. Both technologies are available with all of Adobe’s open source initiatives on http://opensource.adobe.com.

Between the tools, new services, the runtimes, the servers, and our open source efforts, it’s been a big 2009 and we’ve set the stage for a bigger 2010. We can’t wait to see what our community does with these technologies. You are the ones that keep the Flash Platform moving and keep us cutting edge. Thanks for a great year!

Rundown of the MAX News

The press releases just crossed the wire and we have a ton of news coming out of MAX. Plus more surprises in store for tomorrow. For those of you not here you can still check the keynotes out. I’m hosting the online side of the MAX keynotes and we’re doing some fun stuff before and after the keynotes to give you a sense of what’s going on at MAX. As you can tell from the rundown, there’s some fun stuff today.

Flash Platform Runtimes

We’ve been saying all year that Flash on mobile devices is a push this year and we’ve made a lot of progress. Today at the keynotes we’re going to be showing off Flash Player 10.1 for smartphones. This is the version of the Flash Player that we’ve been working on so hard this year. We’ve been working with some great partners including Nvidia and ARM to optimize the player for those devices and create a quality mobile experience.

Possibly more important is that the number of companies committed to the Open Screen Project continues to grow. Today we announced that RIM is joining the Open Screen Project which means that Blackberry will be supporting Flash Player 10.1. Google is also on board. We’ll have public versions of Flash Player 10.1 for Palm, and Windows Mobile later this year with Google Android and Symbian following shortly. Developers will have mobile bits in their hands soon.

We also announced AIR 2.0 which is going to give Flash developers a lot more native hooks into the operating system. A lot of the developers I talked to wanted it and so that’s what the team did. Mike Chambers talked about some of these features at Flash on the Beach. Another cool feature of AIR 2.0 is the ability to record from the microphone without going to a server. getMicrophone can now be a reality


We also have public betas of both Flash Builder and Flash Catalyst that are available today. I’ve been really impressed with how far Flash Catalyst in particular has come from Beta 1 to Beta 2. It’s a lot more polished, has more functionality (including video) and feels a lot more fun to use. If you checked out Beta 1 and found it lacking, you should check out Beta 2. We’ve also made big progress on Flash Builder and I’ve been a very happy camper using the tool full-time.


Some very cool stuff is also happening on the server side. We’ve released ColdFusion 9, a spectacular release with some great features including the ability for you to consume ColdFusion as a service from inside of your Flex application without writing ColdFusion code. I’ve also been playing with the LiveCycle Data Services release and it’s modeler plug-in for Flash Builder. The team has focused on model-driven development making it easy to generate and create a model, then linking that model directly to your Flex application. It helps by generating all of the assemblers and you can directly modify the user interface just by changing the model.

Finally we’ve got some Flash Media Server news. We’re adding support for HTTP streaming which will include support for content protection. We also have released the Collaboration side of Flash Platform Services and announced pricing so you can jump in and start adding collaboration to your application.

If you guys have any questions (sorry I don’t have more fleshed out info, it’s a lot of news), feel free to drop me an email – ryan@adobe.com and I’ll try and answer what I know.

New Project: Flex Collaboration Library

I’ve been digging deeply into the dark crevices of Adobe Flash Collaboration Services (AFCS) my session on creating collaborative components at MAX this week. One of my examples is a collaborative map so I relied heavily on the Yahoo Maps example that ships with the AFCS SDK. One of the things I like about the Yahoo Maps example is that it includes a class that extends ArrayCollection and includes some hooks for collaboration. It’s essentially a collaborative ArrayCollection and I rewrote parts of it for my own example and have found it to be very useful across a lot of my projects.

I realized that it could lower the barrier to entry on AFCS if some of the Flex classes that people rely on a lot had “automatic” support for collaboration via AFCS. So I took the class I created based on the Yahoo Maps example and tried to make it as “drag-and-droppable” as can be for someone who wants to start using AFCS. It merges two concepts, the ArrayCollection concept, and the CollectionNode concept from AFCS. CollectionNodes let you store any piece of data on the server and lets multiple people add/change/remove information from the collection. Events are fired so that any time someone changes a piece of data it can be updated across all of the connected clients.

What I’ve done with my SharedArrayCollection class is put all of that logic into a single class that extends ArrayCollection. Developers can use the SharedArrayCollection just like they would use an ArrayCollection but the difference is that the SharedArrayCollection is automatically enabled for multi-user collaboration with AFCS. The only major difference is that instead of listening for a collectionChange Event you listen for a CollectionNodeEvent.

I’m still hacking out the basics and after MAX I’ll try to provide an example use case so people can see exactly how it works. I’ve put everything up on GitHub under the Flex Collaboration Library project. I’m hoping to make the SharedArrayCollection more bullet proof and then create more AFCS-enabled Flex classes and components. Let me know if you find a bug or if you find this at all useful.

The Full Flash Platform Services Story

platform_servicesToday we announced the release of the distribution side of Flash Platform Services. Most of the action is on Techmeme but I liked the ReadWriteWeb post, the TechCrunch post, and the VentureBeat post specifically. Distribution Services is the one that’s new and the goal is to let you track your application across a number of different screens while also simplifying the distribution mechanism. There are also hooks that will let you easily bring in advertising so that you can both track and monetize your content. The first thing people will think of is widgets, and that makes sense because a lot of the “sharing” aspect, which we’re partnering with Gigya for, will remind people of the widgets they’re able to place on Facebook, MySpace, blogs, and other places. But as Serge’s MAX Widget shows, these can be more complicated applications as well. So while widgets may be the first thought, any one of these three threads; sharing, tracking, and advertising, can be brought into an application of any size. So regardless of what kind of application you’re building, these services should be helpful.

Show me the money
One thing this allows you to do is easily monetize your content. The money side of this is that advertisers or developers can buy installs and pay a fee (starting at one dollar) per successful installs. You can also target this a bit, so if you want to make sure a high number of people are embedding your widget, you can promote it via the network and you’ll be charged a fee anytime someone embeds or installs your content. On the profit side, you can also offer to host advertisements via our network. We’ll give you a specific CPM (cost per thousand impressions), we estimate around $5, and pay that out to you.

These services also work with mobile devices. This is one of the slickest features I’ve seen demoed because when a user wants to install a shareable mobile application, they’ll get an SMS with a link to the application. When they click it, our distribution service detects which device they’re on and will push out the correct version of the application. Currently we support Symbian S60 phones, Windows Mobile, and the iPhone. That doesn’t mean you can use Flash on the iPhone, but you can create an iPhone version that can be pushed out with our distribution network.

The Rest of the Services Story
There are three parts to the Flash Platform Services initiative; Distribution, Collaboration, and Social. Distribution is what we announced today, Social will make it easy to integrate social networks like Facebook and MySpace, and Collaboration has been in beta for a while, you know it as Flash Collaboration Services. All of these will have a pay-per-use model and will provide added functionality or easy integration for developers. The Flash Platform is the most cutting edge technology on the web. The full range of things it lets developers and designers do just doesn’t exist on any other platform. As a result, we’re able to do some very interesting things when it comes to collaboration, tracking, distribution, or integration. The goal of these services is to make it much easier for any Flash Platform developer to accomplish those things. Lowering the barrier to entry for things that makes Flash so powerful is going to be beneficial for a lot of developers.

AFCS Presentation to BAADAUG Slides

I just posted the slides for my BAADAUG presentation on Adobe Flash Collaboration Services.

I had a great time with the group and I appreicate them putting up with a brand new slide deck. I’ll be giving a version of this over at the ActionScript Conference in Singapore, so if you’re in the area, you can still register!

In The Bay Area? Come Check Out AFCS

I’m going to be presenting at the Bay Area Application Developer Adobe User Group today (Tuesday) on Adobe Flash Collaboration Services. It starts at 6:30 at Learn iT!. Here’s the blurb:

Ryan will walk us through how to getting started with AFCS, show us how to use the default pods that are delivered with AFCS, and how to extend existing components to make them collaborative. Finally he will show us real world examples of AFCS in action.

The Web Way vs the Wave Way vs the Flash Collaboration Services Way

afcs_logoAnil Dash has a post worth reading up on his blog that talks about the “Web Way” versus the “Wave Way” and why Google Wave won’t succeed because it doesn’t really fit the same pattern of successful web technologies. He makes 4 general points to define the “Web Way”:

  • Upgrades to the web are incremental. Instead of requiring a complete overhaul of your technical infrastructure, or radical changes to existing behaviors, the web tech that wins is usually the sort of thing that can be adopted piecemeal, integrated as needed or as a normal part of updating one’s websites or applications.
  • Understanding new tech needs to be a weekend-sized problem. For a lot of web developers, long before they start integrating a new protocol or platform into their work, they hack together a rough demo over a long weekend to make sure they truly grasp how it works. And a weekend-scale implementation on a personal site usually translates roughly into a 90-day implementation cycle in a business context, which is a reasonably approachable project size. (In tech, three days in personal effort often translates to three months of corporate effort.)
  • There has to be value before everybody has upgraded. This is basically a corollary to Metcalfe’s Law. While we know networks increase in value as they add more nodes, the nature of web tech is that, in order to be worthwhile, it has to provide value even if the people on the other end haven’t upgraded their software or web browsers or clients or servers. Otherwise you’re shouting into an empty room.
  • You have to be able to understand and explain it. Duh.

The entire post goes on to explain details of where Wave fits and where Wave fails. But as I read it I couldn’t help see it as a ringing endorsement of Flash and especially Adobe Flash Collaboration Services (AFCS). Before I dive in, I understand that Anil’s “The Web Way” has an inherent requirement that everything be “open”. Flash and Flash Collaboration Services probably won’t fit in most people’s definition of “open” as it relates to the web. In this case, I think that’s part of the benefit. One thing Anil does is looks at Wave from the developer perspective and he provides a list of technologies required to use Google Wave and add real-time collaboration to your web application:

  • Federation (XMPP)
  • The robot protocol (JSONRPC)
  • The gadget API (OpenSocial)
  • The wave embed API (Javascript)
  • The client-server protocol (As defined by GWT)

That’s a lot of stuff for a developer to know and understand if they want to start building something that interoperates with and leverages the technology behind Google Wave. Now think about a Flash developer who wants to add real-time collaboration to their web application. They’ve got no real new protocols to learn (RTMP behind the scenes but not necessarily exposed in such a way that developers need to understand it), no new languages to learn, no new client-server protocol, it’s just ActionScript and(/or) Flex, and some new APIs. Then your application is real-time enabled. So lets look at the four “Web Ways” and see how they apply to AFCS.

  • Upgrades to the web are incremental. With the pods and APIs for AFCS, it’s pretty damn easy to just integrate it with your current application. There is no rewriting from scratch and you can literally just add an AFCS component and enable collaboration for your application. As you dig deeper, the service gets more complex and you can do more with it, but to start, it’s dead simple.
  • Understanding new tech needs to be a weekend-sized problem. If you’re a Flash developer already, all you’re learning are a few new APIs. You still have to understand the fundamental issues behind real-time collaboration if you want to create complex components, but you’ve got the core development skills to create those applications so you can focus on learning the theoretical stuff and not the code stuff.
  • There has to be value before everybody has upgraded. This is my favorite, because it’s one of the benefits of Flash. AFCS has 2 versions, a Flash Player 9 version and a Flash Player 10 that adds some more audio support. If you’re targeting Flash Player 9 then 98.8% of the web can see your application and with Flash Player 10 it’s 86.7%. No one has to upgrade anything to see your new real-time enabled application.
  • You have to be able to understand and explain it. With AFCS you can easily add real-time collaboration features like video chat, whiteboarding, and shared data into your Flash-based application. I think that works.

Now again, I understand that openness is a pretty core part of what the web is. But there has always been a trade off between openness and innovation when it comes to the web. And even in cases where “open” can be innovative, like with Google Wave, everyone else has to catch up. With AFCS, even though it may not fit with the wider definition of the “Web Way” you can take advantage of the cutting edge technology that everyone is excited about and ensure that it’s 1) easy to build and 2) easy for your customers and users to view.

Thanks to Sachin for tweeting the link to Anil’s post. I didn’t take the time to read it until I saw he did.

A Week of Flash Collaboration: Shared Models and Collection Nodes

Update: This blog post took me the better part of a day and a half and just as I was posting it I realized I had a huge hole in the logic for my application because of the problem at the bottom. My plan is to come back and clean this up, as Peter suggested, divide it up into a couple of parts. The most important parts are the first couple of paragraphs that talk about the sharedModel classes and the last paragraph that mentions how the AFCS team architected things to build on top of very low level base classes like CollectionNode. Largely this blog post is a mess and digging into CollectionNode was interesting but I recommend it only after having some time playing with the other classes in sharedModel. After that this might be a useful post to read. Diving into the video tutorials is also highly recommended.

The basic building blocks of Adobe Flash Collaboration Services (AFCS) are really the sharedModel package which includes the CollectionNode classes. Using the classes in the sharedModel package you can share any piece of data across AFCS connections and use these classes to build custom collaboration components like charts or maps where data can be updated and must change for everyone who is connected. I’ll first talk about some of the classes in the sharedModel package and then dive into how to use the CollectionNode, which provides the base functionality for sharing data.

Shared Models
The classes in the Shared Model package include a number of ways to share data and actions with AFCS. For the most part, the classes in sharedModel all use the CollectionNode to exchange data but they abstract a bit of the nuts and bolts of CollectionNode to make it easier to use. For instance the SharedProperty class lets you take any arbitrary property and share it across AFCS instances. It includes the ability to specify a CollectionNode or to just use one that will be generated as soon as the component using SharedProperty is created. Nigel Pegg has a great tutorial which covers using SharedProperty. Another set of classes in the sharedModel package are the Baton classes. The Baton is essentially a SharedProperty that gives you more control over when a user can edit something. The Baton class helps define when something is currently in use and shouldn’t be editable by anyone else in the room. It includes methods to grab() and putDown() a baton as well as a batonHolderChange event that can be used to make changes to the user interface. Nigel’s video goes through this as well using the example of a TextInput box. Using the Baton classes it is easy to disable editing of the TextInput while someone else is typing inside of it.

All of the classes above use collection nodes and there are three major parts to the basic CollectionNode: creation, configuration, usage. As the documentation states, an AFCS room is essentially a bunch of CollectionNodes exchanging data and each of those nodes has specific configurations that define who and how people can interact with them. One thing to note is that CollectionNodes can only be created by a room owner, or someone with UserRoles.OWNER so when creating a CollectionNode, the owner must be the first person in the room so they can “initialize” it. After that the developer can use the NodeConfiguration classes to customize what level of user has read or write access to the node.

Creating a new CollectionNode is pretty straight forward. In this example I’m going to create a mini-game where the participants have to match up a ColorPicker to “win”. To set up the game, I’ve got one CollectionNode with a “Color” node that will contain the values of the ColorPicker. Here’s how I create the CollectionNode:

protected function application1_creationCompleteHandler(event:FlexEvent):void
nodeGame = new CollectionNode();
nodeGame.sharedID = "gameNodes";
nodeGame.addEventListener(CollectionNodeEvent.SYNCHRONIZATION_CHANGE, onSync);
nodeGame.addEventListener(CollectionNodeEvent.ITEM_RECEIVE, onItemRecieve);

A few things to notice. First, the sharedID property is described in the docs as the “logical address of the collection within the room” and is how AFCS will refer to it so it needs to be unique. It is also the name that you will see when you browse the nodes in the room console that comes with the SDK. Second, in order to use the node we have to make sure it’s synchronized or we’ll get an error. After creating the node I added a CollectionNodeEvent listener that fires when we have a synchronization change event. I also added an event handler for when we receive messages upon subscribing to the node which I’ll talk about later. Once the SYNCHRONIZATION_CHANGE event fires we can start making changes to our CollectionNode:

protected function onSync(event:CollectionNodeEvent):void
var config:NodeConfiguration = new NodeConfiguration();
config.modifyAnyItem = false;
config.userDependentItems = true;

Now that we’re able to make changes to the CollectionNode I can create the Node that will store messages, in this case the “Color” Node. First I need to use the NodeConfiguration class to set up some rules for the game. By setting the modifyAnyItem property to False I make sure we’re not allowing users to modify messages that aren’t created by them. The userDependentItems property set to true means that when the user leaves the room, we clear out all of the messages belonging to them. In our game we don’t want to find a match with someone who isn’t playing any more. The NodeConfiguration classes allow us to tweak things like what happens to messages as well as define permissions for specific nodes within my CollectionNode. Once we’ve created the NodeConfiguration I can use the createNode() method to create a Node named “Color” and pass in the configuration values I just created. The last method there is a function I created. After we create the node and configure it I want to send the value of my ColorPicker to AFCS so I can start playing the game. I do that with a createMessage()</code< function.

protected function createMessage(overwrite:Boolean):void
var colorMessage:MessageItem = new MessageItem("Color");
colorMessage.itemID = cSession.userManager.myUserID + "_color";
colorMessage.body = color1.selectedColor;

My createMessage() takes one variable, a Boolean that we'll use to tell AFCS whether or not we are allowed to overwrite an existing message. The first part of the code is where we create our MessageItem to be sent. I'm just creating a new MessageItem and passing in which Node it will belong to, in this case the "Color" node I created above. Then I give it an itemID which is how it will be referred to by AFCS. I use the current userID and prepend that to the word color. Finally I set the body of the message. The body of a MessageItem can be a String, a Boolean, a Number,or a key-value pair. In this case we're just going to pass in our selectedColor value. Once we create the MessageItem we need to add it to the Node. To do that we use the publishItem() method on the CollectionNode. This is where I pass in the overwrite flag. In this case, I don't want the MessageItem to be overwritten because this should be the first time we're adding it since we called it from the OnSync method. But later I want to make sure we overwrite it because we're making updates to it.

As soon as we publish our message, it's going to go into AFCS and then AFCS is going to send it back to us so we make sure it was sent correctly. When that happens it will fire an ITEM_RECEIVE event which we added an event handler for in our initial function. That code looks like this:

protected function onItemRecieve(event:CollectionNodeEvent):void
var tempMessage:MessageItem = event.item;
var userName:String = cSession.userManager.getUserDescriptor(tempMessage.associatedUserID).displayName
if(tempMessage.associatedUserID != cSession.userManager.myUserID)
if( tempMessage.body == color1.selectedColor )
Alert.show('Winner! Your partner is: ' + userName);

This is where we start to get to the game. The first to lines just put the MessageItem and user displayName into their own variables. Next we put the selectedColor from our message and the displayName into an array that's stored on the client. This is kind of important. A lot of the sharedModel classes, like SharedProperty for instance, will handle storing data for you but the CollectionNode class doesn't, it's a very basic, low level component. So in this case we can't tell AFCS to send us a list of messages to check and see if there is a match, we have to keep a record within our own application. I do that by storing the information in an Array. Once I do that I want to check if we have a match but I need to make sure we're not matching our own color so I do a quick check using the associatedUserID and myUserID from the ConnectSession. Once we know that isn't the case I can check the body of the message with my current color to see if there is a match and pop up the appropriate dialogue.

When we make changes to our color to try and find a match we also need to send the update to AFCS and check our Array so I added an event handler to my ColorPicker for any change event:

protected function color1_changeHandler(event:ColorPickerEvent):void
for(var i:Number=0; i<arrColors.length; i++)
if(event.color == arrColors[i].color)
Alert.show('Winner! Your partner is: ' + arrColors[i].user);

In this case the first thing we do is call createMessage() with the overwrite flag set to true so we are overwriting our current message with the new color value instead of creating a new one. Then we run through our array of colors to see if this new color matches anything on the system. Do you notice a problem?

The problem is this: We configured our Node to remove all messages as soon as someone leaves the room but because we're using CollectionNode instead of one of the higher level classes we also have that array that is storing the values. We're using that array to check for a match after we change our color but we don't ever clear out old messages from our array so we might get a match from someone who is no longer logged in. We're also not checking the array and updating values so we have a lot of old data.

Welcome to Multi-User Applications
Multi-user applications are fun but there is also a lot to deal with. Luckily, the AFCS team has done a very good job of building base functionality into classes like CollectionNode and then building on top of them with classes like SharedProperty that take care of a lot of the complicated parts of managing a collaborative application. I tried to get nitty gritty and show how CollectionNode works but I really encourage you to start with the higher level classes, get an idea of what's happening, then break down to the low level base classes when you need to start creating very customized collaborative applications with specific rules, custom components, and many different types of data.

You can grab the full project here (Flash Builder 4 FPX file) and see how the parts fit together. I'll be updating it in the next few days to take into account the problem above and include a version that people can play.

A Week of Flash Collaboration: Authentication and Drupal Integration

afcs_logoThis is my first attempt at series I’m hoping to start called “A Week of” which will cover 5 topics in a particular subject over the course of the week. For the first one I’m going to do Adobe Flash Collaboration Services and I’ll be doing a blog post on something AFCS related every day. If you’re not familiar with Adobe Flash Collaboration Services (AFCS) I encourage you to check out my tutorial on the Developer Center to get started. Note: There is a new SDK version (0.93) on the Developer Portal which includes everything in one place including video tutorials and an AS3-only version of the SDK. Worth checking out.

Authentication During Development
During development it’s relatively easy to authenticate against the Flash Collaboration service even if you aren’t online. The basic component for Authentication is the AdobeHSAuthenticator. During development the AdobeHSAuthenticator tag lets you pass in your Adobe ID credentials to connect to a room.

Adobe Flash Collaboration Services also lets you test and develop without having to connect to the AFCS servers with the LocalAuthenticator tag. There is an AIR application as part of the SDK that, when running, will let you use the LocalAuthenticator to pass in an arbitrary username and connect to a room on your local machine.

Guest Authentication
You can set up AFCS to just allow guests to log into your rooms without any authentication. There are a couple of things you need to do to set this up. First, you have to make sure the room is active. You can do this using the AFCSDevConsole AIR application that comes with the SDK. It’s also a good idea to make sure your room settings autoPromote guests so that when the anonymous users log in they are given publish access and can actually collaborate with other users. This can be done either in code with the RoomSettings tag or inside of the AFCSDevConsole.


External Authentication
The most common use case is integrating your own authentication system with Adobe Flash Collaboration Services. AFCS uses a token system that can be generated using the Account Shared Secret which is available when you create an account at the AFCS Developer Portal The SDK comes with code for a number of server side languages including Java, PHP, ColdFusion, Python, and Ruby that help facilitate the generation of the token. In my example I took some of the sample code and scripts and integrated it with a Drupal environment. As a CMS, Drupal has it’s own authentication system and user administration. I created a basic module that exposes an AFCS chat room if the user is logged into the Drupal system and uses the existing Drupal username in the chat-room so that the Drupal users can chat with each other in real time.

I started off by creating an Admin page for my AFCS module that exposes a set of parameters needed to generate the token. That includes the account, or name you create when you first sign up for AFCS, the room for this particular application, your Adobe ID username and password, and finally the shared secret.


Now that I have those variables I can generate a token and set up the session. Using the scripts provided in the SDK it’s easy in PHP to create a new AFCSAccount object, log in, and get the session token.

$host  = "http://connectnow.acrobat.com";
$accountURL = "{$host}/" . variable_get(afcs_account, 'test');
$roomURL = "{$accountURL}/" . variable_get(afcs_room, 'test');
$account = new AFCSAccount($accountURL);
$account->login(variable_get(afcs_user, ''), variable_get(afcs_pass, ''));
$session = $account->getSession(variable_get(afcs_room, ''));
$token = $session->getAuthenticationToken(variable_get(afcs_secret, ''),$user->name,$user->name,50);

The variable_get functions are Drupal-specific but the code should be easy to follow. We first build the full roomURL based on the account and the room name. Then we login with our username and password and finally create a session based on the room. the getAuthenticationToken method takes the Shared Secret and the name that will display to all of the other connected users. The last parameter is the role which is a number from 0 to 100 and tells AFCS what the user can do. 100 is a full host and 50 allows users to publish content and collaborate.

Now that we have the token and the roomURL we need to somehow get that into the SWF file. The external authentication example that comes with the SDK and my Drupal example both use FlashVars which are read by the Flex application and then used to authenticate and set up the session. When the application finishes loading I call the Application.application.parameters object to start the session.

public var authToken:String;
public var roomURL:String;
protected function application1_applicationCompleteHandler(event:FlexEvent):void
roomURL = Application.application.parameters.roomURL;
authToken = Application.application.parameters.authToken;

From there on out it’s a typical Flash Collaboration Services application that uses our token.

<rtc:AdobeHSAuthenticator id="auth" authenticationKey="{authToken}" />
<rtc:ConnectSessionContainer id="cSession" roomURL="{roomURL}"
authenticator="{auth}" autoLogin="false" width="100%" height="500"]]
     <mx:HBox width="100%" height="100%"]]
          <rtc:SimpleChat id="chat" width="80%" height="100%" />
<rtc:Roster id="roster" width="20%" height="100%" dataProvider="{cSession.userManager.userCollection}" />

Hopefully that provides an example of external authentication. If you want, you can download the Drupal module that I created here. It’s still in the very basic stages and I’ll be adding to it down the road but it does show off how to use Drupal authentication in your Adobe Flash Collaboration Service applications.