Flash Site Architecture - one swf vs many?

Question

I'm about to start building a site entirely in flash (per the client's request), using AS3, and was wondering about best practices for doing so in terms of application architecture. The site isn't too large--think homepage, persistent nav, 8 subsections or so, each with their own content but similar design between subsections. In the past, I would have used multiple swfs (say, one for the nav and one each for the subsections) and loaded them dynamically; now, though, I'm considering taking a different route and using a more object-oriented design, with lots of classes and just one swf (plus a preloader to load it).

Are there any best-practices for determining whether it's better to dynamically load smaller swfs vs building a single large swf? In AS2 I think loading many smaller swfs made more sense, but with AS3's stronger object-oriented capabilities I'm wondering if that's still the case.

I know that one argument against the single-swf design would be the added weight of loading everything upon initial siteload, but I don't think there's enough heavy content that it's of real concern here.

Any thoughts?

Answer 1

one argument against the single-swf design would be the added weight of loading everything upon initial [...]

You will want to keep parts that change frequently from those that don't separate if there is any. There is something called Ordered Creation and creationPolicy to take care of loading time. But apart from that, it really boils down to something you will be comfortable maintaining.

Answer 2

It depends on what you mean by "smaller."

Don't break it into chunks that are too small or you'll kill yourself with connection overhead. Don't pack the whole site into one mammoth wad that will takes weeks to download.

A good rule of thumb: if you find yourself trying to think up catchy or entertaining things to display while your users are waiting for it to download, restructure instead.

-- MarkusQ

Answer 3

I thinks this heavy depends on the content of the pages and how many assets you already have included in you swf.

We usually just make 2 swfs: one preloader and the real application.

The applications does not have any text or images included. Everything (except fonts) loaded dynamicly from the server as the content is dynamic on most of our cases. The size of the swf does not increase much you add another 10 classes.

The it is hard to give a 100% direct answer to you question, as said it depends on the weight of the content (and whether it is dynamic or very static).

Answer 4

no there is that i know of
("best-practices for determining whether it's better to dynamically load smaller swfs") but i can think of a good reason to load all the content in the beginning
what i am usually doing

• i write all the code in one place

• load swf with graphic dynamically

Answer 5

In my experience, the common practice these days for (most) small to medium Flash websites/applications is a two SWF architecture, a shell that loads a core. Sometimes you can get by with just one SWF that tracks its own load progress. That said, you want to load content and assets on demand; images, video, animations and large textual content. These typically should not be embedded in the core SWF but loaded on user request. The primary advantage in either case here (one vs two SWFs) is code maintenance. You only need recompile the core SWF when you make updates to the application. In this model, you could still load additional SWFs that contained timeline-based animations, as long as you kept your application code in the core.

Hope that helps!

Answer 6

Your loading time may be an important factor, but an additional factor to consider is whether or not the "look and feel" of your SWF is apt to change while the underlying code remains the same. For several "skinnable" games I worked on, where the gameplay was identical but we wanted to be able to change the imagry to match sponsor clients, we broke the title into two SWFs, one with all the executable code (Application.swf), and another with all the art assets in it (Library.swf). This worked out well as our art team could go and muck with the Library.swf, and as long as they maintained the same movieclip export naming scheme (and frame labels as applicable), they could build new artwork and simply swap out their "skin" swf without needing to recompile or know anything about the source code.

I think we used LoadMovieClip() to handle the library assets, and of course all the library clips needed to be marked for export on frame 1 with appropriate labels. Also, all of our code was in separate AS files, and as we were using AS2.0, we included movie clips as members of classes, as opposed to putting logic in the movie clips themselves. This almost totally segregated the art from the code, with the exception of a few base movie clips in the Application.SWF that were used for initialization and handling the OnEnterFrame() functions, then passing any input or tick based functionality down the chain of child objects.

It's been about a year since I worked on this stuff, so my terminology may be a bit off. Still, I hope this is helpful.

Answer 7

There is never one "SAY ALL" way of doing anything. One project may be small and fine to code up in a procedural fashion, as to where another may be intricate, have many hands involved and upon most certainly be able to accept change, then OOP and design patterns may be the way to go. For a production based site that is surely going to be broken into sections, abstracting each section into its own FLA/SWF/DOCUMENT CLASS allows your code to be maintainable. If something in the about section requires change, we merely open the AboutDocumentClass.as, for instance, and make our changes. Lets be real, you should be using SWFAddress now days to offer deeplinking; enabling favorites, back, and forward buttons for flash sites. With a proper implementation of SWFAddress and a nice preloader, one can achieve a very smooth, low footprint site, that is easy to manage and scale.

That being said, I believe any production level flash developer ought to know about the GAIA Framework. In just minutes you have an entire bone structure of FLA's, document classes, swf's, etc. GAIA not only arranges the outputted files in an intelligent hierarchy, but it also sets up SWFObject, and SWFAddress, as well a preloader.

This is all done by first editing an XML file that is in the bin folder wherever you had GAIA output the new project files. Once your done editing the XML and any other items, you tell GAIA to scaffold, for every section you accounted for in the XML, a FLA is created, a document class with hooks to either a timeline based transition, or a TweenLite/Max implementation depending on your choice before scaffolding. Again this takes about five minutes and you have bones of your site with preloading, SWFAddress deeplinking, and hooks to transitions.

The result is a tidy output of files using a standard set of names and conventions that should be easy to read and cut back on redundancy ten-fold.

Brian Hodge
hodgedev.com blog.hodgedev.com