Developsigner

My favorite part of AFCS is that all of the common problems you face in developing collaborative applications are solved, and most of the solutions are solid. I don’t know about you but after doing it I feel that developing an application with role based access is a pretty complicated task. Once you change your perspective to thinking in a more server-centric way the AFCS authentication and permissions scheme is nice to work with. They do a good job of only surfacing the events your current user cares about. In some cases actually too good of a job ( I have an open forum post about it ). I enjoy not having to reinvent the wheel and I like leveraging others experience even more.

Further investigation into the source code was also a positive experience. One thing I noticed pretty quickly was how the AFCS team seems to have learned from the Flex teams mistakes and has allowed for extensibility and subclassing of all their components. My main pet peeve with the Flex framework is their use of private variables where protected should have been used. I can’t tell you how many duplicate classes I have had to make just to change one property. Overall AFCS is very soundly architected. They provide well thought out interfaces for hooking into the publish / subscribe paradigm of their connect session system as well as making the pre-made pods very easy to use and extend.

The example code supplied covers all of the common use cases and even some pretty advanced ones. I found I was able to glean conventions as well as overall approach from the way the examples were created and commented.

The Extra tools supplied in the SDK are pretty awesome as well. For anyone just wanting to try it out the AFCSDevConsole.app is a great tool for those of us that think visually. You are able to see all of the parts of your account down to the actual data being sent from your devices. I also found the LocalConnectionServer.app to be a really great tool for developing when you have no interweb connection ( like on the train everyday from Oakland to Burlingame ).

Remember also that AFCS is a hosted model so you won’t have to deal with the IT and SYS-AD headaches. Instead Adobe gets to figure out how to scale and deploy.

The Bad

Remember also that AFCS is a hosted model so you won’t have IT and SYS-AD. Instead Adobe gets to figure out how to scale and deploy. ( Both a good and a bad thing )

Even though my overall opinion of AFCS is one of amazement I felt that there were some significant hurdles in getting set up that might deem it not worth it to the average developer or part time tinkerer.

You have to be pretty motivated and have a bit of time on yours hands to get going with AFCS. There are quite a few steps involved in getting to that first gratifying moment of something other than the light greyish-blue screen of mediocrity we Flex developers are all too used to. Let’s count them shall we?

There are quite a few steps involved in getting to that first gratifying moment of something other than the light greyish-blue screen of mediocrity we Flex developers are all too used to.

1. Go to the AFCS Adobe labs site
2. Find the link to the SDK ( hint it’s at the bottom of the page )
3. Go to the Developer Portal
4. Sign up ( I recommend making a new account )
5. Log in with your new account
6. Download the SDK ( the big purple button )
7. Create a new project
8. Attempt to use the SWC ( more on that later )
9. End up using source
10. Import an example project
11. Figure out the AFCSDevConsole.app
12. Set up a room in your AFCSDevConsole.app
13. Copy your room url into the correct place in your newly imported example application.
14. Run ( cross your fingers that you did everything correctly )

Update

Turns out that the namespace changes from Cocomo to AFCS were what were causing the SWC inclusion to fail. Was able to get it working after realizing this. I’m sure it will be addressed in the next drop of the SDK.

So as I said a bit of a treacherous first step in getting going, but well worth it. The main gotcha I found was just using the SWC as described in the documentation. I am by no means newcomer to SWC’s and for the most part they are the easiest way to get going. Normally you can get away with just dragging and dropping them into your libs directory in FlexBuilder so when I first couldn’t get my project compiling I thought I had overlooked something. I was never able to get any of the example projects to correctly compile with either of the supplied SWC’s regardless of what player version I targeted. Anyone who knows me will tell you I am extremely obsessive when it comes to things like these and I will literally grind all night long until I get it to work. No combination of the variables involved ever did. I had a one on one with Nigel Pegg ( great guy btw ) who recommended including the source as you would with a .jar in a Java project. See below.

Update

Looks like a fix for the caching has been checked in for the next SDK drop. These guys are on fire.

The second Major gotcha is session cacheing when debugging your AFCS applications. Since AFCS is made for collaborative applications the second thing after setting up a white board is, you guessed it, setting up two whiteboards and watching the doodles show up in both. I automatically started seeing strange behavior based on what the user role of the last authenticated user was. For instance you need to be an owner in order to instantiate any of the shared components in a room. When I ran a guest application then immediately ran an application that needed to create a shared component I would get permission errors. Although confusing as hell to the new AFCS developer the good news is that this will almost never happen in the wild with a deployed application ( I tested it thoroughly before my demo this week ).

Wrap up

All in all AFCS is in my opinion one of the hottest things out there as a truly applicable framework. If you are interested in building a collaborative application there isn’t anything else that comes anywhere close. If you have the time to get it set up and don’t mind quitting your browser after every debugging session you can rapidly bang out some next level collaborative applications.