tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/267-how-do-you-manage-assets-created-in-the-flash-authoring-ideRobotlegs: Discussion 2018-10-18T16:35:16Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/27498242010-08-30T19:22:37Z2010-08-30T19:22:37ZHow do you manage assets created in the Flash Authoring (IDE)?<div><p>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.</p>
<p>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.</p>
<p>Recently someone else asked the same question, <a href="http://www.matanuberstein.co.za/index.php/2010/08/how-are-you-using-assets-in-your-ide/">http://www.matanuberstein.co.za/index.php/2010/08/how-are-you-using...</a></p></div>Jason Diastag:robotlegs.tenderapp.com,2009-10-18:Comment/27498242010-08-30T20:32:08Z2010-08-30T20:32:08ZHow do you manage assets created in the Flash Authoring (IDE)?<div><p>I split assets into multiple swfs (if it's a bigger project).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/27498242010-08-30T20:37:05Z2010-08-30T20:37:05ZHow do you manage assets created in the Flash Authoring (IDE)?<div><p>@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?<br />
Thanks!<br />
J.</p></div>Jonitag:robotlegs.tenderapp.com,2009-10-18:Comment/27498242010-08-31T15:10:32Z2010-08-31T15:10:32ZHow do you manage assets created in the Flash Authoring (IDE)?<div><p>Hi Joni,</p>
<p>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.</p>
<p>I then use a stylesheet that looks like this (the Embed stuff works in AS3 projects too):</p>
<pre><code> package adminshell
{
public class AcademyAdminShellSwfElements
{
[Embed(source="academyAdminShell.swf", symbol="MCBackground")]
public static var LoginPanel:Class;
... etc
}
}</code></pre>
<p>Then I sometimes also use another class to totally decouple the actual stylesheets from the views using them:</p>
<pre><code>package adminshell
{
public class AcademyAdminShellSkin
{
public static function get loginPanel():Class
{
return AcademyAdminShellSwfElements.LoginPanel;
}
}</code></pre>
<p>Then in the view I create the default skin:</p>
<pre><code>public function init():void
{
var skin:Sprite = new AcademyAdminShellSkin.loginPanel();
setSkin(skin);
}</code></pre>
<p>or if I'm not using the double-decoupling method:</p>
<pre><code>public function init():void
{
var skin:Sprite = new AcademyAdminShellSwfElements.LoginPanel();
setSkin(skin);
}</code></pre>
<p>The actual view itself takes care of setting up the view in setSkin, which can also switch the default for one loaded at runtime:</p>
<pre><code>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;
}</code></pre>
<p>and so on.</p>
<p>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.</p>
<p>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.</p>
<p>You could even make it totally obvious by using more descriptive method names:</p>
<pre><code> public static function get loginPanelForMainView():Class
{
return AcademyAdminShellSwfElements.LoginPanel;
}</code></pre>
<p>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. :)</p>
<p>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.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/27498242010-08-31T17:42:14Z2010-08-31T17:42:14ZHow do you manage assets created in the Flash Authoring (IDE)?<div><p>@Stray thanks for all the info!
I'm also compiling with the Flex SDK, so the Embed meta data works ok.<br />
It just confused me when you said "stylesheet". I couldn't decouple from CSS :P</p>
<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:<br />
skin['username_txt'] as TextField;<br />
If you misspelled the instance name you won't be able to catch that error up until runtime.</p>
<p>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() ?</p>
<p>J.</p></div>Jonitag:robotlegs.tenderapp.com,2009-10-18:Comment/27498242010-08-31T18:18:42Z2010-08-31T18:18:42ZHow do you manage assets created in the Flash Authoring (IDE)?<div><p>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?</p>
<p>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).<br />
</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Stray</p></div>Stray