Designer vs. Developer: Declaring Stage Instances

Here I am in Flash CS3, coding AS3 on the timeline with a few Document classes here and there for sanity on an insane deadline. While waiting for my source control to download (someone apparently checked in the WHOLE internet), I figured I’d blog about an interesting observation I came across this week.

I’ve been working with traditional software developers and receiving assets from Flash Designers for integration into a big Flash site. We had problems with a particular file awhile ago, and since I’m usually the guy who fixes stuff, I opened it up to see what’s wrong. The FLA would compile, but was throwing mad runtime exceptions. Reading through the code, both classes written by the designers and code written by the developers, I saw the problem.

The designer code wasn’t declaring any of the MovieClip’s as member variables, like:

public var slider:MovieClip;

The developer code, was. While the designer code would compile, because their classes extended MovieClip which is dynamic, it would NOT work at runtime; you’d get runtime exceptions claiming some property didn’t exist. The MovieClip’s they didn’t define as member variables were created at runtime since the designers had named instances on the stage. Flash would then look at the AS3 class, and go, "Dude, there is NO ‘slider’ property defined here… wtf, exception for you!" That’s how developers like it; if I accidentally accessed something, even in a dynamic class, let me know so I can fix it.

…however, designers don’t have time for that crap. A lot of time, you don’t know if you’ll have instances on stage, or rename, or get new artwork, and have to re-do everything really quickly. Coding is the last thing on your mind, least of all, GOOD coding. Flash CS3 actually has "declare stage instances", a property under File > Publish Settings in the AS3 Settings button, checked by default.

This means that if a MovieClip appears on stage, when you compile the FLA, it’ll automatically generate those variables for you. However, if you turn this off, Flash expects YOU to define them in your class or time line code. This is what developers do.

Since these FLA’s are changing hands a lot, this setting is getting toggled on and off depending on who touches it. If I get it, I turn it on so the designer code I get will… you know… actually work. The developers, however, get mad because Eclipse or Flash Develop won’t give them code hinting since they aren’t declaring their class member variables, the lexical parsers go, "I’m not helping you JavaScript Boy!". They turn it off, compile, and feel happy. Naturally, they DIDN’T convert all the designer code to ALSO declare their variables, and thus things start exploding at runtime.

I agree with the default setting, and I’m glad we have this feature, but I have no clue what the best practice is. The purist developers will tell you that you should turn that shiz off, and write proper code. The designers and me will retort, "I do not have time to write code under my insane deadline, with ever changing visual content, and code that’ll never be maintained after the launch date."

I feel the developers’ pain coming from years of doing AS3 and learning to love runtime exceptions, having predefined variables that help your code work the first time, and also making it easier to debug and maintain. If you’re using Flash content in Flex, you typically turn it off since you’re writing the AS3 classes that wrap the design content in a strongly-typed way. If it’s just Flash content and you’re working with designer created FLA’s, you typically leave it on.

Things weren’t so bad in AS2 since you could enforce the requirement to have variables declared. Now, though, it’s an actual setting saved WITH the FLA itself IN the IDE. This can be confusing since you can’t see it since it’s buried in the IDE, only its effects at runtime. Like I said, I’m glad we have the ability to toggle this feature, but man… I foresee a lot of places having rules around this setting in their work flow. It could cause major rework if not agreed upon from the start.

18 Responses

  1. Don’t get me started….

  2. I hear you on this one. My approach works like this: if I’m actually coding classes, I’ll be doing it in Flex Builder, so I’ll turn it off and get code hinting. If I’m doing a one-off timeline-coded experiement, declare that shiznit for me.

    I wonder if a per-symbol setting would make this easier to collaborate among coders and designers, or if it would just cause a huge mess.

  3. Reminds me of that story where the the bird and the fish fall in love with each other?

  4. My rule of thumb is to default to what the designers want. Chances are that most of this stuff is simply over their heads.

    It sucks for us but at least we know how to fix the problems. If the designers get stuck they would have to call in us developers anyway.

  5. Interesting discussion, even more since I battled with this very same concept on a project this past week.

    I had one bonus being that I was THE developer, so I would simply turn that off and code it myself. Of course on other projects I haven’t been so lucky.

    @Josh, interesting idea there.. I think we should be able to declare it like that, especially since some things don’t change and it causes unnecessary headaches.

  6. I think I’ve seen this approach in the Essential ActionScript 3 book and I’ve used it.

    1. Leave the option turned on, so the Flash IDE will generate all the properties.
    2. For every thing I need to refer and use code hinting I would do the following:

    private function get scroller { return this["mcScroller"]; }

    or something like this.

  7. I’m sure its absolutely the least efficient way to deal with it, but we usually let the designers do the FLA in their nasty, unorganized designer way(can a brotha get a layer name?). Then we take their ugly FLA, and we make a new and pretty FLA. from that point on, if the designers need to change stuff they can do it in their FLA, and then we take it and put it in ours. This probably only works because the FLA is just a clip repository for us. Our Flash experiences are Actionscript projects in Flex and we just import the SWFs at runtime to get the assets.

    When FLA’s get really interesting is when you try to have 3 or more people working on them independently. FLA’s don’t get along with version control.

  8. Of course it makes perfect sense to declare symbols in the classes. And the preference toggle seems a last minute addition to solve the needs of the designer-minded. Jesse, what you are exposing here is evidence of the growing gap between designers and developers in the flash world. The bar keeps raising for the developer. Why can’t it raise for the designer? Turn that shiz off!

    I say that and yet I have given in and leave it on … I still put declare the properties but I comment them out.

    Chris says that the FLA becomes a clip repository and I think this is exactly right. Tweening has had it’s day. The power of Flash is in the hands of the developer.

  9. That’s an awesome trick, Vladimir!

  10. mh

    Vladimir – NOOOOOO
    Never ever use ['someDynamicthing'] – dynamic typing is evil and if your doing that then there really is no point in worrying about details like stage instances.
    We have just had some quiet time at work and so i spent 2 (lazy) days converting 40 games and a years work so that automatically declaring instances are turned off. It really wasnt that painful (the complier guides you through -publish – add property rinse and repeat) and i now have a much more robust type safe code that FDT loves. I guess it depends on the complexity of your code but if your building big applications then everything you can do to get the compiler on your side is worth it in the long run. IMHO
    ps im not a designer :)

  11. The point of doing dynamic access in the technique Vladimir is using is so the compiler ignores the access, yet the lexical parsers in FB/FD/FDT can see the gettter as a strongly-typed variable. Besides, even though it’s dynamic, you’ll still get a runtime exception if the MovieClip doesn’t exist on the timeline, and AS3 is still faster doing dynamic lookups like that than AS2.

    …regardless, if we all had 2 extra days, I think we’d all agree with your approach!

  12. @mh, That is an interesting idea, but sometimes time doesn’t allow it. Vladimir, that is a very good idea.

  13. Vladimir, I think your approach is very similar to how I have done in the past. Never undervalue strongly-typed vars. Good article Jesse, I am glad to see someone getting a consensus so we can all start implementing some standards.

  14. The problem here is that instead of joining designers and developers, Adobe increases the divide.

    What they should have done (and still should do) is make it so you can declare stuff in the class, and if you check the box in Flash to do it for you, it doesn’t complain about it, and instead says “Obviously we have a designer and developer working together here.”

    I don’t see how it would be so hard to have an option to auto-declare turned on and also allow you to declare what you need. I’m so tired of seeing Adobe post lame ideas like “How do we make the Actions window better?” How about making the Flash IDE Compiler better first? :)

  15. Just like Christ, I’ve stopped worry about declaring stage instances after moving to Flex…, just let the designers do the flash bit although I am still doing all by myself most of time:) It is also hard to find good flash designers too…

  16. dang im always late and last!

    dude ive been saying this for years: Flash should take a cue from .NET…

    Anything on the stage is added in code in the .as file. Anything removed from stage is removed from the .as file. Nothing should be magically compiled into the swf and NOT added to the .as file for all to see as well.

    I HATE how the stage and class are separate and treated with different rules.

    for me though im a purist trapped in a pragmatist body (or the other way around, i forget). So I ALWAYS declare my movieclips but i have a small team and can enforce standards.

    However, if your dealing with designers that just need to get things done outside of your influence, you can’t spend your time purifying their code. So I saw do what works best for you at the time.

    also, and i haven’t touched the project panel since it never really worked for me EVER. it be nice if settings like that where in a standardized project.xml file so flash, fdt, flex etc could read and handle it to avoid the toggles between different users, ides, prefs, evil monkeys, etc.

    -erik

  17. I submitted a feature request to Adobe. A better approach, in my opinion, would be for the Automatically Declare Stage Instances setting to completely go away. Flash should be able to determine if I’ve declared a stage instance or not. If I have, then it doesn’t need to do anything. If I haven’t, then it should declare the instance.

    I encourage everyone to make sure Adobe knows we’d like a better approach to stage instances.

  18. [...] a “Symbol” suffix on its name, define the variables (similar to un-checking “automatically delcare stage instances”), and then embed that class via composition that does not have the “Symbol” suffix on [...]

  19. Meh Meh

    Simple solution:
    Don’t let the designers even touch Flash. Let them design their little hearts out in Illustrator and Photoshop and leave anything to do with Flash alone. Yes, it takes a bit more time to prepare the assets and bring them into Flash, but it saves many headaches in the long run. (Also, don’t use Flex just for its code hinting. Use Flex for Flex projects. If you just want something nice for doing AS, use FlashDevelop)

  20. [...] Flex and Flash Developer – Jesse Warden dot Kizz-ohm » Blog Archive » Designer vs. Developer: De… I think I’ve seen this approach in the Essential ActionScript 3 book and I’ve used it. [...]

  21. [...] other major advantage this approach has is that it renders the “Automatically declare stage instances” debate irrelevant. You can let the designers leave this setting off and write bits of timeline code if [...]