IntroductionVideomaru is a popular choice with designers and people that does not want to code because it hides the complexity of Flash video. By just naming MovieClips with certain names, anyone can build an advanced video player with a custom look. The design goal for videomaru is thus user friendlyness. We also want it to be expandable and follow good coding practice, but this is something the users should never need to see. The videomaru Component is based on the UIComponent classes that ship with Flash CS3. It follows the general guidelines for CS3 components, but we've had to do some simplifications. We've tried to avoid other dependencies for simplicity. It would have been super-easy just to wrap the FLVPlayer classes that come with the Flash IDE and base the component on this. We can't do that due to the Adobe EULA agreement that prevents the re-distribution of the code that comes with Flash. To get around this, all the functionality is built upon the Flash Players native classes. It's a lot of extra work, but also makes it possible to work around some bugs that the FLVPlayer does not solve. We need similar functionality though, so most of the events in the FLVPlayer also exist in videomaru. When structuring the code initially, we figured it made sense to have a component class that wraps a player class. This way, we can create players directly from actionscript so it can be used in Flex as well. The player has a playlist and will support various types of media (eventually). We added FLV support first as this is the current use for videomaru, but we want to make it easy to add other kinds of media later. To ensure this, future media types must implement the IPlayable interface. If they have the methods defined in this file, the player will be able to play them. The various media types will be stored as separate classes in the media-folder below the core player classes. Version 0.1 (10th Dec 2007)The first version of this component did a detection of the clips available on stage and then applied listeners and custom code to each of these. This is a really error prone approach for several reasons: - video.Maru is primarily used by designers that may do things it is hard to account for. What if there's several play-buttons on stage (due to accidental duplication or even on purpose). This will cause reference problems.
- What if a button exist on frame 1, but not 2? That could produce "ghost" buttons that were never cleared from memory since they still had listners applied. While theoretically possible, this would require us to loop through the whole DisplayList on every frame. If we do this in a huge file, it could potentially crash the Flash Player.
- The DisplayList hierarchy is prone to error when it comes to basing the component on instance names. I've discovered that in certain cases, the component will only be able to list MovieClips on the layers BELOW itself, not those ABOVE. This is a major issue since we have no control over this, it is hard to reproduce consistently and we have no control over what the user actually does on the timeline.
Version 0.2 (18th Dec 2007)Based on the issues in v0.1, we're now basing the component on listening for clicks on the Stage-property of the MaruComponent and rather check if the object clicked is a MovieClip and has one of the predefined names. This approach will solve the above issues, unless propagation is stopped in some way (unlikely). It does introduce a new one - text on a button won't trigger the button. Gotta solve this in some surefire way. This will require a small change to buttons though. They must now issue their own stop-command on the first frame. The v2 approach also reduced the component code to half the size and makes it MUCH less error prone. Simpler is (usually) better! Version 0.3 (8th April 2008)First version committed to CVS. Fixed several bugs, did a commercial implementation and added the timeline/playhead functionality as well as progress bars. Invalidation is only partially implemented.
|
Sign in to add a comment
