 | | | [Flashnewbie] Timeline/OO Methodology [was Sound question] | [Flashnewbie] Timeline/OO Methodology [was Sound question] 2004-02-06 - By Jim Cheng
Back
Marc Hoffman wrote:
> I agree it's best to centralize all code, but most Flash is still
> timeline-based, and for good reason, such as when streaming is required.
> So, as in Brian's case, there are going to be buttons and frame actions
> dispersed along the timeline and there's nothing wrong with that. I also
> find that Flash that's created all in one frame may be a developer's
> dream but it's often a designer's nightmare :)
As a developer, I'm of the "centralize your code" school
and typically develop using a single frame, one or more
.AS files and object-oriented methodologies,
However, I agree with you that a lot of work done in
Flash is timeline-based. This is particularly true if
you're collaborating with designers and are dealing with
inherently time-based media such as non-looping sound,
videos or complex animations.
To avoid dispersing code throughout thousands of frames
and also to keep the designer(s) whom I work with from
having a conniption fit or two over seeing oddles of
code, I oftentimes do something like this:
1) Have all the design elements placed on the timeline
like a designer would normally do. Tell them that
you'll handle the AS. They should tell you when
to stop and start the movie, rather than doing it
themselves.
2) Add one extra layer to the .FLA file. For kicks,
call it "Actions." Put one keyframe at frame 1 on
that layer. Leave it blank. Now open up the
Actions panel and type in something like:
#include "player.as"
This will be all the code that your designer will
ever see. Everything else will be "magic" that you,
the developer, will throw in. Now you just have to
tell them to make sure that the magic Actionscript
file is in the same directory as their .FLA or
Flash will be unhappy when they "test movie."
3) Now go and write all your code in the Actionscript
file. I usually treat the movie much like a class
and have a structure like this:
A single public function for moving the playhead.
This function needs to be an abstract layer that
separates the rest of the code from the individual
frame numbers of the movie. This is important as
otherwise you'll end up changing "magic numbers"
all over the place if your designer needs to add
or remove a few frames here or there.
Several other public functions to control other,
miscellaneous things such as the volume.
A function with one large switch() statement that
with cases based on the current frame. This
contains *ALL* your frame-specific code. This
function is assigned as the event handler for the
movie's onEnterFrame event and will do different
things (or nothing) depending on what frame has
just been entered. You really shouldn't do any-
thing outside the massive switch() statement to
keep things fast unless something really does
need to happen.
Miscellaneous private functions that don't need to
be called from outside the movie. These can be
the specific frame functionality called from the
massive switch statement above.
In my experience, such a scheme generally keeps both
your developers and your designers happy. While your
mileage may vary, I think this is a good compromise
between designers relying on the timeline as a sort of
"instruction pointer" and developers wanting as
little to do with the timeline and frame numbers as
possible.
Regards,
Jim
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Supported by Fig Leaf Software
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Lower Prices for Certified Training! Check out new lower prices for
Certified Macromedia Training from Fig Leaf Software. Expand your
skill set with courses in ColdFusion, Flash, Rich Internet
Applications and .NET in the new year. Fig Leaf Software provides
the highest caliber instruction at our training centers in Washington
D.C., Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at
your location.
Get the details at http://training.figleaf.com/
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
To unsubscribe, e-mail: flashnewbie-unsubscribe@(protected)
For additional commands, e-mail: flashnewbie-help@(protected)
Earn $52 per hosting referral at Lunarpages.
|
|
|