Comments on: Flex Feature Request: Creating Packaged Classes with [Embed]

By: Josh Tynjala

Josh Tynjala — Mon, 14 Jan 2008 20:58:42 +0000

Ah yes, Flash SWCs are a pretty good option too. If I don’t want to use Flex, but I still need UI components, I just throw all the Flash CS3 components in a big SWC and add it to my build settings in an AS Project. I don’t think I had extended that thought to specifically targeting skin assets rather than whole components, but it makes sense. Easier than writing out all the [Embed] lines too.

By: Randy Troppmann

Randy Troppmann — Mon, 14 Jan 2008 17:50:50 +0000

I know it’s a little ugly but I have been using swc assets from flash in FB by addling them to the build path in the properties of a flex project. I get code introspection at develop time (nice!) and I can then import the package and instantiate it like any other display object.

I will vote for your feature request.

By: Brian Deitte

Brian Deitte — Mon, 14 Jan 2008 17:38:16 +0000

Compile-time checks of the Embed class that Erik showed does happen. Note that if you use the parameter “-keep” to see the generated classes, you’ll see that an Embed class is generated for each Embed variable. In other words, the Embed-on-a-variable is just syntactic sugar for Embed-on-a-class.

By: Doug McCune

Doug McCune — Mon, 14 Jan 2008 17:10:24 +0000

better anyway. It keeps things in the same structure as the rest of your code. Yeah, it creates these mini classes that are essentially empty except for the embed statement, but I think I’m OK with that.

I assume that compile-time checking of these Embeds doesn’t happen, but seems like with that structure it wouldn’t too hard to do (hell, I dunno, maybe it does it now).Ha, I didn’t know you could do that either. I might argue that that’s

Erik, thanks for showing us stuff we didn’t know.

By: Josh Tynjala

Josh Tynjala — Mon, 14 Jan 2008 16:46:58 +0000

That’s interesting, Erik. I didn’t know that was possible. Personally, though, I’d prefer to be able to define many different asset classes in one file.

By: EECOLOR

EECOLOR — Mon, 14 Jan 2008 12:59:55 +0000

I might be missing something, but this feature is already present:

package x.y
{
   [Embed(source="myLibrary.swf", symbol="myAsset")]
   public class Asset extends MovieClip
   {
   };
};

To create a new Instance you can just do 'new x.y.Asset();'. Greetz Erik

By: Tink

Tink — Mon, 14 Jan 2008 10:14:17 +0000

“Sure, I can already do something similar by creating a class with a lot of public static constants, but it feels kind of like a hack.”

I actually don’t mind this method too much. I know all my assets will be in the one place, a little like them all being inside a Library in Flash. That said being able to specify a package would open up more options.

I definitely for the compiler only embedding assets that are used.

By: Doug McCune

Doug McCune — Mon, 14 Jan 2008 09:20:58 +0000

Yeah, OK, you’re definitely right about the bloat issue already if you use a static assets class. I change my previous comment and instead of citing that as a danger, that’s an additional feature request. I would love to be able to be that lazy and just define a whole slew of embedded assets, knowing that only the ones I explicitly instantiate somewhere in my code by calling new MyEmbeddedAsset(); will actually get embedded in the SWF. This would be a great feature with the current state of embedded assets too.

As to where they would go, not sure, maybe in an additional metadata tag in the main Application? Or how about in a CSS file, which sounds kinda weird at first, but I think might make some kind of sense.

By: Campbell

Campbell — Mon, 14 Jan 2008 09:05:55 +0000

That would be a great feature. and save having more code bloat at the top of Classes.

Yeah have to agree with Doug on the Compile time checking for embedding the bytes. I could see util.IconLibrary classes getting crazy bloated, ala Java styles.

I also us the BitmapAsset for Types of imported graphics instead of DisplayObject, in my code as its a bit more descriptive. (Most images get typed to a subclass of this at compile time), but thats merely personal preference. Potato, potato stuff really.

Will be voting once I get my account confirmation email

By: Josh Tynjala

Josh Tynjala — Mon, 14 Jan 2008 08:41:18 +0000

A ton of embeds in an assets class could easily be forgotten too. I rarely embed things in a local class if there’s more than one or two things embedded in the entire app, so the risk is about the same for me. Good point, though.

One thing I didn’t mention, but is worth questioning, is where are we supposed to place these sorts of Embeds? With a centralized assets class, you specifically reference it in your code so there’s nothing special about it. For embeds like this, there needs to be a specific way to make sure that the compiler knows about them, beyond adding them all to the metadata section in the main application file or something. That could get messy.