TwinTechs

I recently had the opportunity to integrate the Adobe Flash Collaboration Service, also known as AFCS, with another application.  For those of you that don’t know, AFCS is a hosted Adobe service that gives Flex developers the ability to easily add real-time social capabilities directly into an application.

Getting Started:

Although it’s still in Beta, the product team at Adobe has done a great job with documentation and has released a slew of sample applications. Setting up an initial “Hello World” AFCS project with webcam, text chat, and a white board support can be done in less than an hour. The Adobe “Hello World” code sample is here.

Getting Down and Dirty:

As we all know, sample applications always work perfectly. But if you are trying to do something a little off piste…  well… many times, things can get a bit dicey.  Our application’s requirements resulted in us extending the base AFCS functionality a fair amount.   These extensions can be summed up into two distinct groups:

1. Storage of additional data in AFCS.
2. Enhancements/additions to the current AFCS components (pods).

Storing additional data in AFCS

Luckily, storing additional data in AFCS is easy.   AFCS has a three-deep level data hierarchy,  including:

1. Collection Node: The highest level.  Collection Nodes wrap up functionality stored in components/pods and consist of a collection of nodes.
2. Node: Second Level.   These generally wrap up functionality to a certain section, e.g. a history of a chat window and consist of a collection of message items.
3. Message Item: Lowest level.  Message Item’s support both primitives and simple objects.

In addition, there is a whole bunch of additional goodness relating to all of these data structures including private messaging, session management, and user management.  Also, there is a rather extensive security model that allows you define read/write permissions at a granular level.

Retrieving data and notifying clients of data changes was very easy and the Nodes operated in much the same way as Shared Objects do in Flash Media Player. There were events notifying clients of both data changes as well as synchronization with the server.

I did find a couple of downsides with the data model. Creating a collection node requires owner permissions and  this ended up being a problem as our application had clients trying to dynamically add instances of pods. In addition, the data model is not N deep. This could be troublesome with some data sets, i.e. you want to store the data in nodes as a BST.

Extending AFCS Components

Extending the base components, while not particularly hard, is a little time consuming and does force a developer to get his hands dirty. Fortunately, the developers at Adobe followed some coding rigor and separated most of the pods into two components, model and view. Thus, if you only have to change the L&F of a component and not necessarily its underlying functionality, you can get away with just extending the view component.

In our case, we had to update both the model and the view components. This resulted in reading and understanding the individual components and updating them as necessary.

In hindsight, it might have been prudent to just write our own components.  Once you are comfortable with the API and its functionality, it is easy enough to write your own custom components and interface with AFCS.

Final Thoughts:

Overall, I was very impressed with AFCS and I think it has potential.  The ability to generate an application that gives you chat, webcam, and whiteboard functionality instantly is great. In addition, being able to develop Flex components without the fuss of configuring and installing (not to mention developing!) an app server is a huge plus. Recommendation to Adobe: a desktop sharing component would make this a killer service.