It's a bit embarrassing to admit that it has taken me this long to post this app. I first spoke about it at my talk at MAX 2008 in Milan but then Christmas came and went and I got swamped with work... Apologies, but better late than never.
So what have we got here? My PureMVC Skeleton App is a simple Flex project that uses the PureMVC framework to give you a bit of a head start with your next FMS project. I'm by no means suggesting that this is the best way to build an FMS app but what I can say is that it works well for me. Not only that but since I've picked up PureMVC I have been able to build much larger projects than ever before, and the framework allows me to come back to an app months later and pick it up in no time at all. Everything has its place and it's easy to find your way around, and projects generally end up well maintained.
One thing I should point out is that the app itself has no UI - there's nothing to see when you compile it (hence the skeleton bit in its name). You will however see traces if you compile a debug project, or install Firebug for Firefox so you can see the Thunderbolt AS3 traces I tend to use extensively.
In order to connect to your own FMS application you first need to create it on FMS (mine is called pmvcskeleton) and then go into the ResourceBundleProxy and on line 42 add your corresponding RTMP string. I'm not sure if this is a good idea but I often use ResourceBundles for configuration options such as the RTMP string, I find it quite handy since they usually do not change so I just compile that in.
It helps if you are a bit familiar with FMS based applications and the MVC design pattern. For everything else check out the PureMVC website, it has tons of info and a lively community. Or why not sign up to my FlashMedia List, there's always a bunch of knowledgeable people there ready to help.
On this note I will leave you to it, take a look at the app and feel free to post a comment if anything isn't clear.
Massive thanks to Simon who gave me some excellent tips when I got stuck with certain PureMVC nags.
#1 by Peter Lorent on 1/9/09 - 3:08 PM
#2 by Stefan Richter on 1/9/09 - 7:44 PM
#3 by Stefan Richter on 1/9/09 - 7:45 PM
#4 by Peter Lorent on 1/10/09 - 11:21 AM
#5 by Cliff Hall on 1/10/09 - 6:41 PM
I've actually set up an account at influxis recently to work with video. They totally rock, but I don't necessarily want to use their off-the-shelf apps. I've been preparing to do a little PureMVC/FMS work and this'll give me a great headstart.
Also, Peter, there's really no need to start any PureMVC project in the standard version.
As you've recently found with the Becks site, MultiCore is just as easy to use, and another plus is that you can unit test things a bit easier because you can get a clean core for every test.
Cheers,
-=Cliff>
#6 by Cliff Hall on 1/10/09 - 6:45 PM
#7 by Cliff Hall on 1/10/09 - 7:03 PM
The problem with putting them in resource bundles is that if they do change you have to recompile (which usually means promotion of the new release through different environments with testing, etc. In my experiences, many organizations have rigid deployment policies about code, but are less rigid for configuration changes.
So its nice for config to be totally decoupled from code if possible. If it forces a recompile, then it might as well be a constant defined in a class somewhere. This will still need to go through the 'promotion to production' process, but sometimes can simply be tweaked at staging, tested and then promoted to production without the codebase having to change or for a developer to become involved. Then sysadmins can handle configuration as usual.
Check out the DeploymentConfig utility which handles loading of config at startup as well as using different XML namespaces to give you the ability to have separate configurations for each deployment environment (i.e. dev, staging, production).
-=Cliff>
#8 by Stefan Richter on 1/10/09 - 7:24 PM
As for source vs SWC I do that so I can easily go into the framework code to check how things work behind the scenes, nothing modified there though.
#9 by Cliff Hall on 1/10/09 - 8:00 PM
Then it would be good to remove the source from your zip. That way people know what version it is. In the future if there are changes, they'd have no way to know if this was the latest and greatest or not.
-=Cliff>
#10 by Doug Gray on 1/13/09 - 10:07 PM
Nice job S i'll be having a gander at your code over the next few days.
I've had a quick look and to be honest it's like reading a book - nothing overly complex means it's easy to get immersed in the idea rather than the code. I've recently started using Pure for some projects with AMX so it's reassuring that you've approached things in almost exactly the way i have for my apps.
At the moment i'm building mostly reporting apps for delivered video but soon we're looking to update the main products that form Vision2 http://www.amxuk.co.uk/assets/literature/Vision2.B...
Your skeleton will defo be helpful so thanks for the heads up.
Cliff nice work!
::peace::
#11 by Doug Gray on 1/13/09 - 10:33 PM
I think it's less confusing to have specific helpers where everything resides.
So in a recent PureMVC app i have a package called staticdata within which i have ApplicationDataConstants.as, ApplicationEventConstants.as, CommandConstants.as, ComponentEventConstants.as, InstanceNames.as and NavigationConstants.as.
Interested to hear if you think this is any better/worse
#12 by Stefan Richter on 1/14/09 - 8:46 AM
yes your approach is totally fine, in fact I'd recommend it and do similar in more complex projects. This really is just a simple app to get you started, so hack away and modify to your liking.
Cheers
Stefan
#13 by Mediocre-Ninja.blogSpot.com on 1/20/09 - 1:40 PM
But I think I would refactor the source code a bit more. The first file I looked at was "ApplicationFacade.as" and the first consts make me a bit confused about consistency:
public static const STARTUP:String = "startUp";
public static const APP_READY:String = "appready";
public static const NETSTATUS:String = "netstatus";