How do you manage assets created in the Flash Authoring (IDE)?

Joni's Avatar

Joni

30 Aug, 2010 07:15 PM

Hello, I want to learn how other devs manage assets created in the Flash Authoring when working on a pure Actionscript project (using robotlegs of course).

This is how I'm currently working.
I have an assets.fla where I create all the visual representations of my components. In other words, a bunch of MovieClip set to export with a class name. There is no code in this .fla file. I've configured Flash to generate a .swc which is included in my Flash Builder Project.

So, in my FB project, I have 2 choices:

  • I can extend the assets created in the FlashAuthoring to add all the view logic to my components. By doing so I also have code hinting when I reference an object that's inside the asset.

  • I can use a composition approach and instantiate this asset inside the view logic class. Pretty much the same as before though I have to add an extra level when referencing any other object inside the asset. Something like asset.title.text instead of title.text.

Another thing about this approach is that I end up having only one SWF. For some big projects this isn't going to work.
But by having one single SWF I also have one main preloader for the site, and that's it, besides any preloader when loading external content from a service.

How do you guys manage visual assets created within the Flash Authoring and their corresponding view logic in a pure actionscript project?

  1. 1 Posted by Jason Dias on 30 Aug, 2010 07:22 PM

    Jason Dias's Avatar

    I do things very simliar, I do break the assets.fla up based on what section of the site they apply to because I work with a few other developers, this makes it easier to prevent the same fla being edited by 2 people at the same time.

    I only keep assets that are needed for the gui or application in the swcs, if they are things that are needed during runtime or on-demand I still load those in externally.

    Recently someone else asked the same question, http://www.matanuberstein.co.za/index.php/2010/08/how-are-you-using...

  2. 2 Posted by Stray on 30 Aug, 2010 08:32 PM

    Stray's Avatar

    I split assets into multiple swfs (if it's a bigger project).

    A single 'view' (a view that isn't more granular) is a single exported item in the library, and I access this via a stylesheet class with statically Embedded variables to access the view classes.

    In addition, most of my views extend ISkinnable - an interface with one function : setSkin(skin:Sprite) and this is used to actually set up the visuals.

    This means that most of my views are suitable for re-skinning at runtime. Not all my apps need it but it's good to have it there for when I do use it.

    In my RL apps the reskinning at runtime is triggered through the view's mediator - a SkinLoadedEvent.SKIN_LOADED fires with the sprite and the view class - mediators check if it's the same as their view class and then pass it on if it is.

    Stray

  3. 3 Posted by Joni on 30 Aug, 2010 08:37 PM

    Joni's Avatar

    @Stray, could you explain a little more about this: "A single 'view' (a view that isn't more granular) is a single exported item in the library, and I access this via a stylesheet class with statically Embedded variables to access the view classes." Is the stylesheet thing a Flex-only thing? Where do you put view logic in this case?
    Thanks!
    J.

  4. 4 Posted by Stray on 31 Aug, 2010 03:10 PM

    Stray's Avatar

    Hi Joni,

    So - in terms of the 'granularity' - I mean that I export each 'view' that has a mediator. That view could be a single button, or could be a complex view with multiple elements.

    I then use a stylesheet that looks like this (the Embed stuff works in AS3 projects too):

          package adminshell
    {
    public class AcademyAdminShellSwfElements
    {
    [Embed(source="academyAdminShell.swf", symbol="MCBackground")]
    public static var LoginPanel:Class;

    ... etc
    }
    }

    Then I sometimes also use another class to totally decouple the actual stylesheets from the views using them:

    package adminshell
    {
    public class AcademyAdminShellSkin
    {

    public static function get loginPanel():Class
    {
    return AcademyAdminShellSwfElements.LoginPanel;
    }

    }

    Then in the view I create the default skin:

    public function init():void
    {
    var skin:Sprite = new AcademyAdminShellSkin.loginPanel();

    setSkin(skin);
    }

    or if I'm not using the double-decoupling method:

    public function init():void
    {
    var skin:Sprite = new AcademyAdminShellSwfElements.LoginPanel();

    setSkin(skin);
    }

    The actual view itself takes care of setting up the view in setSkin, which can also switch the default for one loaded at runtime:

    public function setSkin(skin:Sprite):void
    {
    removeAllChildren();
    addChild(skin);
    usernameTextField = skin['username_txt'] as TextField;
    passwordTextField = skin['password_txt] as TextField;
    submitButton = skin['submit_btn'] as SimpleButton;
    }

    and so on.

    I could use a factory class to return a Sprite ready to use, but I prefer to keep the actual instantiation in the view itself.

    The purpose of the double-decoupling is that it allows you to group your skin classes by purpose, rather than which swf they originated in, and then get a quick look at all the skin stuff you're using for one functional area in one place, rather than trawl across multiple views to see what is being used where.

    You could even make it totally obvious by using more descriptive method names:

    public static function get loginPanelForMainView():Class
    {
    return AcademyAdminShellSwfElements.LoginPanel;
    }

    Just as importantly, it allows you to utilise whatever daft export names the animator who built the swf happened to use, without polluting your view class with code like "RedThingy" ... obviously in an ideal world we can beat sense into the animators and they give us nice descriptive, sensible asset export names, but this is your air-lock between your lovely pure code and their random headspace. :)

    I hope that makes sense. Actual view logic is still handled in the usual way (whatever approach you would normally have used). I don't think it's Flex-only, but I am compiling with the flex SDK rather than the IDE itself, so it might be that you have to use the flex compiler to get it to work.

    Stray

  5. 5 Posted by Joni on 31 Aug, 2010 05:42 PM

    Joni's Avatar

    @Stray thanks for all the info! I'm also compiling with the Flex SDK, so the Embed meta data works ok.
    It just confused me when you said "stylesheet". I couldn't decouple from CSS :P

    I've used this approach in the past too. What I didn't like was the part where you had to do this kind of stuff:
    skin['username_txt'] as TextField;
    If you misspelled the instance name you won't be able to catch that error up until runtime.

    If you would happen to load the SWF with assets at runtime, how would you return the skin class? Would you have to use something like: loadedSWF.loaderInfo.applicationDomain.getDefinition() ?

    J.

  6. 6 Posted by Stray on 31 Aug, 2010 06:18 PM

    Stray's Avatar

    Agreed on the runtime error risk - except that it's mitigated by thorough testing, and if you aren't testing your views then how do you know that they look right?

    The compiler can't catch position/colour/font/spelling errors etc, so I have a very comprehensive test approach and the correct instigation of the view parts is always tested in my unit tests for my views (along with anything else I can pin down, such as position of objects that move), and then skins loaded at runtime are tested as well (and usually I would wrap that skin switch in a try{} and revert to the original skin in the case of an error).

    Ultimately you can't have the advantages of the full power of the IDE for designing and the full power of the compiler for testing, so this approach allows me to have very rich interfaces (visually) with effects on the text etc done by the design team, while still developing with the full power of Sprouts etc.

    There may well be a better way though - I've only stumbled across this way of doing it and refined it as I've encountered problems.

    My skin loading is done a little differently - the swf base class for a runtime loaded skin conforms to an interface which provides a 'menu' (in the restaurant sense) of available visual assets and will instantiate the one you want and pass the sprite already instantiated. So - when the skin has finished loading, the SkinManagerModule goes through that menu and fires each sprite out on an event which also specifies the view class it's intended for.

    I don't use the exact same names for library assets between the skins - because I can't use the applicationDomain stuff in the usual way as the applications I'm developing are in Air and the security model requires that complex objects be loaded into the application sandbox, only simple objects can pass across the sandbox bridge.

    So - if I had redSkin and blueSkin and they each had a skin item for 'BigButton' they would be exported in the library as redSkin_BigButton / blueSkin_BigButton and so on. That's probably a peculiarity of Air that wouldn't be needed in flash player, but the same approach would work.

    Stray

  7. Stray closed this discussion on 12 Feb, 2011 10:51 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac