Category: Flash

  • No exclude.xml in Flash CS3 for AS3: Solution via Bridge Pattern

    Exclude.xml, functionality in Flash 8 and MX 2004 that allowed you to exclude ActionScript 2 classes compiled into your SWF, does not work in Flash CS3 for ActionScript 3. A similar function is available in Flex 2 via the load-externs option. This is the basis of how Flex modules work. The lack of this functionality just adds another challenge to Flash Developers who have expectations coming from AS2; this actually makes AS3 usage in Flash worse than AS2 when creating Flash sites, or large Flash applications.

    “Great Jesse, no one cares about your vendetta, so how do we fix it?”

    I have no clue, but the server architect I work with, John Howard, had a good idea. We’ll probably implement it in the next 2 weeks after we hit some interim milestones. I’ll explain his idea at the bottom, but first a review. If you want to skip the review, go to the bottom.

    Why Exclude Classes?

    When creating large Flash websites or applications, you’ll tend to have many SWF’s. This was especially true with AS2 driven not just from a media perspective, but also from a performance one. If you go to a visual website, say Flickr, and spend 20 minutes on it, you’ll probably download hundreds of images. Rather than download 20 minutes worth of images initially, you download on the fly and download whats needed. Flash and Flex apps can be built this way; it’s called excluding classes in Flash, and modules in Flex.

    In Flash, the main way to download assets over time is to load external SWF’s into another SWF. You use the loadMovie/loadMovieNum functions or the MovieClipLoader class, or the Loader component to do this pre-AS3. Although you can load images and video externally from a SWF just like a webpage can, the SWF format itself has visual advantages, such as images that can have alpha channels, yet also have JPEG compression applied to those images. JPEG does not have alpha channels, GIF only has a 1 bit alpha, and PNG never got the glorious browser support we all desired and only has lossless compression. When creating visual layouts that have a lot of media such as a multitude of images, audio, and/or video meshed with animations, this can be a stand alone SWF. Typically those types of things would be put into their own symbols such as a Graphic or MovieClip. However, if they got large enough, you should make it an external SWF for 3 reasons.

    The first is because it’s faster for you to make changes to the SWF. When you do a test movie, aka compile a SWF, Flash has to render animations, compress your bitmaps and sounds, as well as integrate your video if any. This can take a lot of time. Sometimes that time isn’t actually that bad, but because of the frequency in which you are re-compiling your SWF’s to check for visual accuracy, and doing this say every 2 minutes, and you end up saving 2 seconds in your compile… well, hey, that’s almost 10 minutes of your day you just saved right there! This is more apparent for larger media, however, like mp3 compressing a bunch of audio, or integrated video that can make your FLA’s take a minute or more to compile.

    The second is you can get help, aka RAD development. Instead of sharing the same FLA, you can have a project broken up into multiple FLA’s that another designer/developer can use so you both can work together on the same project.

    The third is that you only make the user download what they need to download. If you have a site that has 6 sections, you only need to make the user download the first section. You can either load the other section when the user clicks to go there, or download in the background once the first is done.

    The work-flow for visual projects in Flash is dead easy. There are a lot of frameworks, such as Gaia, and methodologies out there for facilitating this kind of work.

    For Flex, you have to be a rocket scientist. Flex 3 has some help in this department, but they are a long way off in how easy this is in Flash.

    For Flash applications, it’s a little different. In the beginning, our first enhancement to this was Remote Shared Libraries. What this allowed you to do was have a “reference MovieClip”, or any other symbol for that matter, in your library. Your symbol would have the SWF that it is stored in stored with the symbol as metadata. You’d go make that Symbol in another FLA, and upload those SWF’s together to your website. When your SWF was played, if a remotely shared symbol appeared on the time line, the Flash Player would automatically go download this for you.

    The bad was you really didn’t have much in the way of code in control or getting events about this. However, that ended up saving you a lot of work since it did it for you. Either way, this worked out pretty good because you could treat the symbols as normal symbols; the FLA would actually keep a local copy. You could update the symbol from the Library in case it changed in another FLA. You could additionally ensure every time you compiled it updated for you, but this was the slowest thing on the planet.

    In the end, Remote Shared Libraries were a management nightmare in Flash. For simple projects where you had a master SWF, they worked damn good. For anything more complicated, it was what I call “Flash Jenga” (Jenga is a game consisting of a tower of stacked wooden blacks the size of your pinky. The challenge was to remove bottom blocks without making the whole thing topple). If you got it to work, you were the shit, but it was very easy to break, and once it did, things came crashing down. The tools never really helped you manage your Remote Shared Libraries.

    Flex Builder has some nice improvements in this realm with regards to tool support.

    The biggest problem, however, with Remote Shared Libraries in regards to application development and code. Like I said, they still work good for assets; anything that isn’t ActionScript classes.

    Since ActionScript 2 and 3 utilize a lot of classes, and thus have dependencies, this makes things challenging when creating your applications for low initial download impact in mind. I’ll rehash my version here, but reading these 3 blog posts by one of the the mxmlc compiler creators, Roger Gonzalez formerly of Adobe, is probably a little more authoritative and better written. (Multi-SWF Applications, Modular Applications (part 1), Modular Applications (part 2)).

    It’s hard enough to architect an application, especially when accounting for a designers needs for dynamic Views. It’s another when you visualize a package of classes, and then have to account on how to reduce dependencies so you only load some classes in some SWF’s, and others in another SWF, but be sure not to use in a master SWF, thus reducing the overall file size. This can lead to code duplication, or a non-efficient use of a RSL, or too much in an RSL that’s not used by 80% of the application. As if software development wasn’t hard enough, you have a designer who keeps changing your MovieClip instance names.

    You could just say fuggit, and just load a bunch of SWF’s as users navigate to those sections. However, your wasting bandwidth by using duplicated code. For example, in the image below, 3 forms are loaded into a master SWF on the fly whenever a user navigates to that section. Each other has it’s own unique set of components; however, each also has it’s own copy of Button, or mx.controls.Button to be exact in AS2. Say that your Button is 14k. You’ve now duplicated that 14k across 3 SWF’s.

    Exclude-01

    …however, why not just load that class once, and have all other SWF’s use that same already loaded class? You can! First, a review on how AS1/AS2 classes work.

    In the old AVM, aka, the one that runs AS2 and A1 (regardless of player version), classes are defined on _global. The _global keyword is like this object that never dies, and is accessible via the _global keyword in ActionScript. It’s also accessible across SWF’s and across _levels (_level is like a loaded SWF basically). This means that SWF’s loaded in can access classes on _global as well as defining their own. They cannot, however, overwrite classes. In AS3, this behavior is controlled via ApplicationDomain; in AS2, it is what it is.

    Since you know you’ll be loading those 3 SWF’s into a SWF that will already have the Button class defined, you can then just not compile those 3 SWF’s with the Button class. The user then only has to download 14k once; any other SWF that uses the Button class can use that already downloaded class. In the example below, the Button class has been moved to the shell.swf, increasing it’s size from 8k to 22k. However, notice that that same 14k is now removed from the login.swf, the amount.swf, and settings.swf.

    Exclude-02

    In this particular example, you’ve ended up saving 24k! Now, imagine a large website or large application consisting of dozens of SWF’s that could potentially use the same class. You can see how this feature saves a ton of bandwidth.

    How Exclude.xml Works

    Exclude.xml works like dis. If you have a FLA called “my.fla”, you create an XML file in the same directory next to the FLA called “my_exclude.xml”. When you compile your FLA, Flash will look for that exclude.xml file. If it finds it, it’ll read it. Any class written in that XML file will NOT be compiled into your SWF. The con to this is the SWF no longer works on it’s own; you have to load it into another SWF to test. The plus is that you’ve now saved file-size since the SWF will get the class it needs to work from another main.swf. Most importantly, your work flow has changed; just your SWF.

    In the past, I wrote some JSFL to automate this. One JSFL script would delete the exclude.xml file, and then do a test movie. You map this JSFL to Control + Enter so your Test Movie works as normal. I then created another JSFL script to create the exclude.xml based off of a set of classes I knew would be shared throughout the site, and then test your movie. I then mapped this JSFL to Control + Alt + Enter, replacing test scene. That way, you can create SWF’s ready for deployment easily.

    Now that Flash CS3 has E4X, writing such scripts is a ton easier, and gives ANT in Eclipse a run for it’s money in automation. Course one could use Rake (Ruby‘s version of Make), but anyway.

    In Flex using mxmlc, this part is actually automated for you; the XML you need is generated via the mxmlc -link-report parameter. You immediately feed that generated XML file to -load-externs, and booya, you have a SWF with those classes removed.

    So, pretty pimp, huh? Guess what; it doesn’t work in Flash CS3 for AS3. I know, right? “Yeah hi, I’ll take some AS3 with a side of lame sauce.”

    Using mxmlc Doesn’t Work

    I tried using mxmlc with -incremental set to true, making sure it doesn’t actually recompile the entire SWF, but just those classes that have changed. If you make sure your FLA has a Document class, this’ll work; mxmlc can use that as the root class. However, in recompiling your classes, it basically ignores the symbols your FLA has created, thus “I’ll take it from here” attitude. Um…mxmlc, dude, f-off, at least we can use pixel fonts…

    You could do this in MTASC for AS2, I guess their bytecode replacement techniques are just different. Either that, or I’m maybe missing a mixture of mxmlc compiler arguments… :: crosses fingers hoping someone says so in comments ::

    Bridge Pattern to the Rescue (sort of)

    So, my boss suggested a proxy technique. Basically, we use the J2EE blah blah blah official blah blah Bridge Pattern. The Bridge Pattern in a nutshell is 2 classes that implement the same interface; one provides the pretty face, whilst the other does all the work. The pretty face is called the Abstraction and the one who does the work is called the Implementation.

    If you were going to create a Button component using the Bridge Pattern, you would do it in 3 steps.

    1. Create the IButton interface
    2. Create the Button class that implements IButton
    3. Create the ButtonImpl class that implements IButton, and does all the work.

    Flex 2 actually uses this in a few places, specifically the ToolTipManager class. ToolTipManager merely proxies everything to ToolTipManagerImpl. He instantiates an Implementation class (ToolTipManagerImpl) via a magic string to ensure there are no dependencies, meaning the compiler doesn’t know to compile it in. To ensure it is compiled in, however, they do do (gross) a dependency variable above that.

    This is how the Bridge pattern will work to save file size. The child SWF’s will only contain the interfaces and abstractions; the implementations will be in the main SWF. First thing to do is create the interface, mainly for typing purposes.

    Now that that’s done, I do the same thing the ToolTipManager does; I instantiate the ButtonImpl class inside of Button via a magic string. This ensures that Flash doesn’t see the usage of the class. If it did that, Flash would compile it in. A magic string, however, cloaks it from the compiler. Using flash.utils.getDefinitionByName, I can instantiate the ButtonImpl class with my magic string:

    var btnImpl:Object = getDefinitionByName("com.multicast.controls.ButtonImpl");
    impl = new btnIpml() as IButton;

    Now, I can just create my sets of components as normal:

    var btn:Button = new Button();
    addChild(btn);

    However, the ButtonImpl class won’t be compiled into the child SWF’s. Instead, he’ll be compiled into the main shell.swf.

    Based on some initial tests, I reckon interface will run about 500 bytes to 2k, and the Button class from 2k to 4k. The Impl will be around 8k. So, being conservative and rounding up, all of my child SWF’s will no longer have 14k in them, but rather 6k. Like exclude, the developer whether using Flex Builder with an ActionScript project, or Flash CS3, can code normally with AS3’s strong-typing, and/or Flash’s time line and symbols. The down-side is I’m still duplicating anywhere from 2k to 6k in any additional child SWF that uses Button.

    It’s not perfect, but it’ll do.

    Unknowns

    What I haven’t figured out yet is the implementation details. Premature optimization is the root of all evil so I hear, but seriously, how much speed does keeping the interface for strong-typing really give me? What if I just remove the interface, and cast impl in the example above as a DisplayObject, or more accurately, a MovieClip? I feel the Interface is for Java people who like a bunch of classes; to me, 2 is too many, let alone 2 and an interface. I’m only doing this because a feature that worked in 2 previous Flash IDE’s now doesn’t; don’t punish me by making me write more classes to compensate for a feature that removed classes in the first place. Convention works for the Ruby guys; why not me? I don’t really want to spend much time on benchmarks, but any dynamic look up will cause the old AVM to be used, and since this component set is created with AS3, it kind of defeats the purpose of using AS3 if you aren’t going to take advantage of the runtime speed.

    Secondly, what is impl, a DisplayObject, or rather a class that uses a DisplayObject via Composition? Traditional programmers who came to Flash in the past would use Composition all the time because the thought of extending a GUI base class freaked them out. So, instead of extending MovieClip or Sprite, they’d instead store a reference to the MovieClip or Sprite passed in the constructor. All methods would then act on that reference, as opposed to the class itself via Inheritance. Would doing Composition be better? Although it may have a tad more code, it’d be redundant, so hopefully zlib SWF compression would see that and I’d still hit my small file size goal. Furthermore, I wouldn’t end up with twice as many DisplayObjects. In AS2 that was bad, but in AS3… not so much. If all Buttons were just a simple shell with the “real” Button inside it as the impl, is that really that bad? My gut says make the Implementation class via Composition to save on the number of DisplayObjects.

    Basically, rather than doing:

    // Button.as
    private var impl:IButton;
    
    public function Button():void
    {
            var btnImplClass:Object = getClassByDefinition("com.multicast.controls.ButtonImpl");
            impl = new btnImplClass() as IButton;
            addChild(impl);
    }
    
    public function setSize(w:Number, h:Number):void
    {
            impl.setSize(w, h);
    }
    
    // ButtonImpl.as
    public function setSize(w:Number, h:Number):void
    {
            this.width         = w;
            this.height     = h;
    }

    I’d instead do:

    // Button.as
    private var impl:IButton;
    
    public function Button():void
    {
            var btnImplClass:Object = getClassByDefinition("com.multicast.controls.ButtonImpl");
            impl = new btnImplClass(this) as IButton;
    }
    
    public function setSize(w:Number, h:Number):void
    {
            impl.setSize(w, h);
    }
    
    // ButtonImpl.as
    private var btn:IButton;
    
    public function ButtonImpl(ref:IButton):void
    {
            btn = ref;
    }
    
    public function setSize(w:Number, h:Number):void
    {
            btn.width         = w;
            btn.height        = h;
    }

    Any other ideas (or corrections), lemme know.

  • Silverlight First Impressions

    I’m a Flash & Flex Developer, and these are my first impressions of Silverlight. Silverlight is a rich media web browser plug-in that was recently released by Microsoft.

    This is long. If you’re in a hurry:

    …otherwise, just read the whole thing over coffee, beer, or pick a section.

    Contents

    Introduction

    I felt the need to post for four reasons.

    First, there are a lot of negative attitudes out there that I think potentially blind people from the cool technical features Silverlight has. Second, all the developer oriented posts written by people in Flash / Flex sphere are not as technical as I would like and wreak of Microsoft PR machine bs, or uber-idealism with no technical supporting data; well not enough for my taste. Engineers can be some mean, critical mofo’s and I’ve yet to see an article really rip into Silverlight from a technical perspective. Third, there are also some inaccuracies in the blog-sphere on how powerful Silverlight 1.0 is and what you can actually do with it compared to Silverlight 1.1. Fourth, my 3 4 5 6 day old (What frikin’ day is it!?) is finally asleep, but I can’t sleep.

    Overall, I wanted to report my 3rd endeavor to learn Microsoft’s story on how they see this all working, and get a feel for the technology. To give some context, I am an Adobe kid; I use their design & development products in my career and for fun. I develop using Flash & Flex as a client architect at my full time job working at Multicast Media, a video streaming & Internet TV company. The views below, however, are my own and are not associated in any way with Multicast Media. We use a lot of technologies where I work, both client side and server-side such as PHP , Java, Ruby, C++, .NET, Flash, Flex, AJAX, and tons of HTML & JavaScript. I use both Mac and PC, and have drifted away from using Microsoft Office products on both machines now that I’ve become comfortable using Google Docs. I love to code, and love working with designers.

    I am not an expert on Microsoft technologies, and am still a Silverlight n00b. I apologize for any inaccuracies below (feel free to correct me in the comments). These are my impressions.

    TOP

    What is Silverlight? My Version

    Beyond being a browser plug-in to play rich media, Silverlight in my mind is definitely positioned as an application development platform for the web. In reading the SDK on how Silverlight works from a technical perspective, if she performs well under stress (hundreds of classes, code running combined with animation running without hiccups, code actually working as the docs say it does on both platforms), then I fully believe Microsoft has something really special here.

    Don’t take my word for it; the 2 blog entries I found that were (mostly) not Microsoft lackey posts are from Richard Leggett, a very talented Flash Designer & Developer of both Flash and Flash Lite. Good stuff in the comments too. Another is from Satori Canton which he recently wrote to give a breakdown of what Silverlight really is and is comprised of. A sorely lacking blog post in the community, especially in the Flash in Flex sphere. Unfortunately, like them all, he’s too nice which makes me suspicious and angry because I want to know what sucks about it, where is it lacking, and what’s Microsoft’s story on improving those areas? Either way, both are great reads.

    TOP

    Here’s what I know, and like.

    Silverlight 1.0 is a web plug-in that works on both Windows and Mac, and it works in Internet Explorer, Firefox, and Safari. Google Analytics used on users of a variety of my company’s products makes me not care. The data clearly is there to only need to support IE and Firefox; Safari’s a nice to have… for me alone, apparently.


    Update: I still haven’t got the DLR & CLR parts totally correct yet; for better commentary, see the 3rd, 4th, and 5th comments at the bottom of this entry.

    Silverlight 1.0 uses the JavaScript engine of the browser it’s in.

    Silverlight 1.1 has will have a DLR, a Dynamic Language Runtime, that will run atop the CLR. This is similar to Flash Player’s ActionScript Virtual Machine, the AVM (AVM1, the one before Tamarin). As of today, you can write in JavaScript 1.0 style, from simple functions, to full blown classes via Object.prototype manipulation, similar to Flash Development circa Flash MX. This has some people excited because apparently enough of the DLR will be open sourced to allow other language implementations to compile to the DLR runtime, such as Ruby and Python. So, you can create animations and GUI’s in Silverlight and control them with code much like you did in the past in Flash using ActionScript 1.

    TOP

    The Silverlight DLR & CLR is not out yet; it is slated for the summer of 2008. This will be the release of Silverlight 1.1 which is currently in alpha. The CLR in .NET as I understand it is much like any runtime in taking bytecode or some other low level language and parsing/interpreting those instructions. Some are interpreted, some are compiled code. The way you get to that code is by compiling in Visual Studio 2008 (in beta currently called Orcas ). What is neat is that all the languages people currently use in .NET such as Visual Basic and C# can compile to compiled code, and thus the CLR. My guess is the speed increases one gets using the CLR vs. the DLR will be inline with what one gets using ActionScript 3 vs. ActionScript 2/1 in Flash Player. This is based on assumptions of seeing the online demo of TopBanana that Metaliq did, as well as my experience with reading about how you can only optimize dynamic, late bound languages so much compared to strongly-typed ones.

    There are no native component sets for Silverlight 1.0. Building things in Silverlight currently is perceived by me as building things in Flash 4/Flash Lite. From scratch, each time, and small enough in scale because of your 1 week or less deadline. Hence, no need for a component framework. While I think this is just fine for a lot of design agencies looking to spruce up their usage of Windows Media as separate design elements on their branded portals, it’s frikin ‘ worthless to developers who want to start building something today. Building components frameworks are a lot of time & work.

    TOP

    Silverlight has a display tree much like Flash Player 9’s DisplayList. You can have display objects all attached to each other ( a Button control with a TextField attached to it). This is great because you can create GUI elements without them having to exist on the display tree, and thus drawn taking up CPU & RAM. This helps both Silverlight’s creators because they make sophisticated, efficient frameworks around this model, and it’s great for developers because they can not worry about the designs scaling if they have a bunch of screens.

    Silverlight is built upon XAML. XAML looks and feels like XML, and is very low level. It’s low level because this is the XML that is parsed into machine instructions for WPF. XAML , however, is not software or hardware, it’s just an XML format, nothing more. You can edit it Notepad or any text editor, and easily create it in Design and Blend.

    TOP

    Comparing it to Flex’ MXML is really hard to do. MXML is very high level. The point of MXML is provide an easy way to build GUI’s with all the good things XML has to offer. It’s very high level, and abstracts a lot. This is good because the less code you have to write to get something done, the better in my opinion. Looking at the Silverlight / AIR / JavaFX Stopwatch example (HTML version here), you can definitely do custom controls, but they don’t seem to be built into the language as well as MXML is. The benefits of XAML , however, is you can pretty quickly (assuming you can find where the heck you’re going) change very low level properties on your XML document from the x position of an element to the 206th curve of a vector spline in a design.

    It gets really interesting with animation. Unlike Adobe Flash which has a timeline, XAML has timelines, aka, plural. Each one is created for a property and/or object you can manipulate over time, and thus it’s a different type of timeline. So while Blend and Flash both have a timeline panel, Blend’s XAML is writing a specific type of timeline in XAML based on what you are actually animating. These can exist either as part of a set of objects, say a custom rectangle you built that immediately moves itself, or as a set of animations you can apply later. Flex has something similar with transitions which can be abstracted away from the GUI they are animating, much like XAML. So, to me, they got this part extremely right. The GUI’s responsible for creating and editing those timelines, however, suck. Blend’s animation timeline should just copy After Effects‘ and get it over with. I told Samuel Wan this over a year ago in Beta 1 of Blend, wtf. Either way, I still love time based, non-destructive timelines like After Effect’s has using key frames as more formal objects.

    TOP

    Most interesting of all is Sliverlight’s setup. In Flash & Flex, you make a SWF and shove it up to a web server with associated JavaScript to embed it in an HTML file. The tools usually generate these for you. In Silverlight, you don’t compile anything for using the DLR. You just upload your Silverlight.js file, a CreateSilverlight.js file, your own JavaScript, your XAML files, and your own HTML. All ASCII based. While this is irrelevant at development time because you can have an all ASCII based setup using Flex and Flash for source control, you cannot easily screw with SWF applications at runtime. Since SWF’s are binary files, you cannot simple open them in Notepad to see how they are made. My favorite new feature in Flex 2 allows you to easily publish your source code for all to see. In Silverlight using the DLR, this is native and allows tools like Greasemonkey to actually change the way Siverlight applications work at runtime, even ones that you didn’t create. You cannot do that easily using SWF’s mainly because of the strict cross-domain sandbox policies, and it’s next to impossible in ActionScript 3 SWF’s since you can’t hack the prototypes of the loaded classes.

    Silverlight has an event model as well for all it’s display objects. Some of these events do event bubbling just like ActionScript 3 does. The JavaScript implementation is ok for writing an event handler, a function that receives the event. Your first parameter is the dude who sent the event, and the second is the arguments. ActionScript 3 has formalized this into 1 parameter only as a class that extends flash.events.Event. I agree with Silverlight 1.0’s implementation as it’s lighter weight, and you don’t need bloody classes when your trying to keep your applications’ file-size low. I despise the event registering, though. In Flex, you can opt-in to pass parameters to the event handler, effectively doing your own delegate like so:

    TOP

    This:

    <mx:Button click=”click(event, ‘moo goo’)” />

    Becomes this:

    private function clickListener(event:Event):void
    
    {
    
          click(event, 'some str');
    
    }

    Which at runtime will then call the function I defined when I click the Button:

    public function click(event:Event, someStr:String):void
    
    {
    
          throw new Error("someStr: " + someStr + ", event: " + event);
    
    }

    TOP

    XAML is not compiled in the DLR, thus there is no code generation going on. I fail to see how Microsoft could do code-gen in the DLR, but they have no excuse to not have this ability in the CLR. Then again, there are 50 billion closet C# guys in the Flash world, so I’m sure they’ll be itchin’ to tell me how C# already has a better way, blah blah blah.

    Bottom line, all you can do in XAML itself is someEvent=”someFunction”. Obviously you can do more in the code behind JavaScript. So, compared to MXML, XAML isn’t very flexible in this respect.

    TOP

    The mouse and keyboard events are pretty standard.

    Fonts are neat, although, cumbersome. If you’re a Flex Developer, imagine not having a SWFLoader or Image component in the Flex SDK; that pretty much describes what the Downloader is used for in regards to font files. You have to manually download the font, whether a file or in a zip, and once downloaded you can then apply the font to text objects. It takes only 5 lines to download the font, and 1 to apply it, but still, this is all stuff developers are going to be writing; you might as well create a set of framework classes that simplifies these common needs for them. Either way, light years better than Remote Shared Libraries and font wars that last long into the night when using Flash/Flex. Assuming it works as advertised; haven’t used the feature.

    It has full screen support, just like Flash Player 9.0.28.0.

    It also has Ink support (aka stylus, pen input from tablet pc’s).

    The last feature is that videos still support their embedded text tracks and time-codes. This allows messages to be played through the video at certain times, and JavaScript can handle these messages. It’s like cue points in Flash’s video players, or embedded NetStream events when you use Flash Media Server. The reason this is important is that those script tracks never worked well on the Mac. Thus, massive kludge code was written to poll the server if you were building synced slide web software for example. Nasty stuff. Now, Silverlight has this functionality working like it should on both platforms… so we’re told.

    Linux has a version that seems to actually have Microsoft’s support called Moonlight.

    TOP

    Install Experience

    When I tried the Beta 2 version of Silverlight on my Mac, I had pretty much the same experience as Sean Corfield. However, while I have seen 2 blog posts about Windows developers having issues installing the plug-in, I’ve been very impressed about the final release installation experience on both Mac and PC. It just works. That was one of the secrets to Flash Player’s early success, and was echoed by the swath of traditional developers who explained on their blogs why they chose Flex.

    It needs to work for everyone, though, not just me.

    TOP

    Documentation

    I installed the Silverlight 1.0 SDK, and read the entire .cfm file, stopping at the API. I glanced over the API to ensure it matched up with what I read, and it did for the most part. I found the documentation really good in explaining how Silverlight works. The fact Silverlight has changed so much from it’s early Alphas, Betas, and then final release made it have a few minor addendum’s that clearly spelled out corrections to earlier documentation. I did not read the earlier documentation (whatever was published at MIX 2007), so just took it at face value. These were usually in regards to performance bottlenecks and how to avoid them. While this is really cool to have that level of detail, and to ensure first apps built with Silverlight don’t get a bad rap for some developer who didn’t read the updated documentation, it wasn’t in depth enough. I want technical details like I can get from a variety of sources like Flash Player.

    TOP

    Business Decisions

    The reason I even care about Silverlight is two fold. First, I wanted to learn something new.

    Second, Windows Media doesn’t suck. Where I work, a huge portion of our customer base uses Windows Media streaming technologies, both live streaming and progressive using CDN’s. Yes real streaming, not fake streaming, hehe, nice on Ted. While the customer base is currently asking for Flash because it’s the latest greatest, there is no reason tomorrow they won’t start asking for Windows Media again, or even Quicktime when Apple fixes their severely broken Quicktime PR arm. Since we are in the business of video streaming and software solutions around them, it is in our best interest to know the ins and outs of all architectures… yes folks, even Real for the mere point of ripping it apart intelligently. Silverlight is not a video architecture like Windows Media Player; it’s an interactive runtime that allows you to create rich experiences with your Windows Media content. I’d argue Flash can do it better, not just from a technical angle, but from a community one. Keyword contraction “I’d”; I’m still learning, so while I doubt I’m wrong on the community angle since I don’t really hear much about people like Hillman Kurtis winning design awards for using Design/Blend/Silverlight together, it doesn’t mean I won’t be in the future. This is brand new software, barely out of the oven. I’m still learning Silverlight too, and Blend specifically; it took me years to get good at Flash & Flex, so I know it won’t happen overnight.

    It also won’t happen without a project, either. While I’ll definitely do the responsible developer thing, and learn on my own personal projects at night, I do so knowing it’s not a waste of time. Clients will come a knockin’, I’m sure of it.

    TOP

    Further Validations

    Silverlight has valid set of business needs. Previously, there was no easy way to brand Windows Media content easily online like you could with Flash. Now their is and to great effect. Designers can treat Windows Media content just like they can with Flash; as part of the page, not a “thing unto itself”. Granted, it’s still a plug-in, so things aren’t perfect, but plug-ins exist because browser evolution is too slow to do what businesses need to do today. One of those needs is to have a 100% branded image on some projects where millions were spent to ensure that customers are not confused about the brand image they are seeing. It’s really frustrating leading a design team to implement a new site, and customers mention in blogs “so and so brand used Microsoft video”. Dammit! No we didn’t, we used OUR video, for OUR brand! Silverlight remedies this. My video, my controls, all you need to do is design a video player around your brand, and you can then use Silverlight to show Windows Media as you want it to look and feel.

    If you didn’t know, there was some hub-bub about a lot of online viewers petitioning the BBC to convert a lot of their online content to Flash solutions to better support audience needs. I use Flip4Mac WMV Player on my Mac, but it doesn’t work very well, so I definitely know what these audience members are talking about. Compare to CNN.com, and it’s pretty blatant.

    TOP

    The BBC’s retort was quite cool, actually. They said, no and explained why they couldn’t. Mainly, it was too expensive to remove all the massive investments they had made in Windows Media to just switch it over to Flash. They then put the ball in the communities court to help them figure out a way. I never really heard the resolution to this story, but I’ve heard derivatives before. For example, a company I work near has a box they send customers. This is an encoder box, and it streams Windows Media streams live, and later uploads them to be viewed progressively later. The amount of hardware & software development and testing, both client and server that went into that setup is immense. To just “start doing Flash” is unrealistic. One needs to consider the costs and the technological validity. These are 2 scenarios, one of which I can personally attest to, where Silverlight allows those who have invested serious capital into Windows Media to capitalize on it.

    TOP

    Silverlight 1.0 vs. 1.1 (aka, DLR vs. CLR)

    While my exposure to the .NET blog-sphere is next to null, and those I’ve talked to in person and read about seem fine with either the DLR or the CLR. As long as Visual Studio 2008 supports the developer with code hinting, and other commonly accepted code tools, then a few don’t really seem to care if they are using JavaScript or C#. I don’t buy that in the long term, though. I think the .NET guys are just being patient. What I think will happen is the web geeks and the agencies will use the thenDLR, and all the .NET software shops will use managed code.

    For the latter, I thought that the .NET guys would have the same problems that the traditional programmers who came to the Flex world would have with leveraging rich media. I was partially wrong. They all picked up Flex really quickly, were passionate, and are now producing a lot of great Flex work, both public, but mostly behind the firewall. I still get some emails requesting design talent for Flex specific projects which make me really happy to know that these software shops, once they see what’s possible, appreciate what good design can bring to the table. I’ve worked with some .NET’erz in my time at a large agency and at a mid-size software shop, and now at my new job. They all have appreciated good design. There is no reason these people, who have the tools, cannot do the same the non-.NET crowd did (Java/Ruby/ColdFusion, etc.) with Flash and Flex.

    TOP

    My concern stems from the fact that Design & Blend are 1.0. I’ve messed around only briefly with Design and it worked for me. My litmus test is if you support PNG, you get a passing grade right off the bat. However, supporting PNG and having industry standard design tools such as the Adobe & Autodesk suites are decades apart, both in software evolution and community evolution. Can a community really form around these design tools to push Silverlight in a direction it needs to go? Where does it need to go? Well, to me, it needs to go where Flash goes; pushing limits of designs, pushing web application envelopes.

    I just feel like the .NET crowd is setup to fail with the design tools that Microsoft has provided. It does mean the tools are bad, nor that the .NET crowd is incapable of laying the visual funk. Rather, a DESIGNER has to learn those tools. The tools are new; they’re not like Photoshop which have gigantor communities and followings; atmospheres, attitudes, histories. That is a lot of ramp up time in an industry that already has Silverlight playing catch-up. Maybe more money will make it evolve faster?

    TOP

    What Sucks

    If you view the tutorial videos on Siverlight.net, there is a WPF slant. The marketing Microsoft originally had made it sound like Sparkle (first of 2 Silverlight alpha/beta names) was this ground roots effort done in tandem with the WPF. However, after reading the docs, and using the tools, Silverlight seems extremely reactionary. Meaning, I believe that when you show me a video about using Blend about how I can create interfaces for Windows Vista programs, yet you place this video in the Silverlight tutorial section, this is misleading and contributes to the “reactionary” perception. Either you’re trying to leverage my Silverlight experience to create Windows Vista Destkop Applications for the same bizarre reason Adobe thinks we need to port well and good web apps to the desktop, or you’re low on content that shows how Blend can be used as an interface tool for creating web applications in Silverlight… because Blend is not a tool for creating web interfaces in Silverlight. Or both.

    Heck, maybe it is. Maybe both Design & Blend are truly meant for building both desktop applications and web applications. You can do the same thing with Flex and Flash, so I can see the idea flying. Regardless, when Microsoft mention things in the SDK like “supporting most of XAML in Silverlight”, it only hammers home more of the idea that Silverlight was built atop WPF later rather than a tandem effort like the WPF/E original beta name tries to lead you in.

    TOP

    The lack of coding tools that work out of the gate, easily, is pretty bad. I never got Visual Studio 2008 (Orcas Beta 2) to actually work after downloading the 4 gigs twice in 1 weekend with the Silverlight JavaScript. I mean, if Aptana can do it in Eclipse, why can’t this greatest IDE on the planet I keep hearing about do it? I know it’s beta, so it’s all good, just curious. Just because I use a late bound language doesn’t mean I don’t like code hints. Besides, these things help me learn!

    Blend’s timeline is bleh. It doesn’t mean it isn’t intrinsically good or powerful, but rather, my expectations from other tools such as After Effects, Flash, and Live Motion carry over to Blend. Maybe once I learn it, it’ll rock the mic. Once I found the bloody thing in Blend, I figured it out pretty quickly. The concept of an embedded animation vs. a resource was really hard to wrap my head around in the actual XAML syntax. The actual concept, though, makes perfect sense. MovieClip animation vs. a Flex transition tag; one is part of the object, the other can be borrowed. Got it. Uh… so… like, I don’t know, it seems to me that this should kind of be an important part of building RIA interfaces. Why not make this more a prominent part of the workflow? I don’t really know Silverlight workflow yet, so who knows. Flex Builder currently doesn’t have a very good one for transitions; states are good, but not animations. It seems both tools could improve on this front. Then again, Flex developers do just fine without them, so, maybe Microsoft thought it was acceptable since Adobe didn’t put it inFlex Builder . Glorious assumption, I know. Bottom line, I’d prefer Blend have their keyframe editing in place like After Effects does rather than having to use the global property inspector for everything. Relevant property inspectors on the timeline, not in a far away panel.

    TOP

    I know Blend isn’t really Silverlight, merely a tool in which you can create GUI’s for Silverlight. However, the end result is greatly affected by the tools used to create it. As such, improvements in Blend will have a direct impact in improvements in Silverlight content. For example, an under-utilized, yet powerful feature in Flex is transitions. If Flex Builder is improved in future versions, Flex content will be a lot better. The functionality is already there, it’s just tedious to create, not easy to undo, and thus hard to get “just right”. Same holds true for animating in Silverlight . Maybe if I did a full blown project, I’d change my mind. I just had high expectations from Beta 1 to Beta 2, and it doesn’t seem like much changed on that front.

    There are no component frameworks that come with Silverlight. I’m sure some third party is nearly done based on the blogs I’ve read. For now, that doesn’t make Silverlight 1.0 valuable for large scale applications. Video players, however, that make Windows Media look good don’t need to be enterprise scale, so maybe that’s why. My guess is those types of things will be more polished in 1.1.

    TOP

    Conclusions

    At the end of it all, Silverlight deserves more research. The biggest challenge for me is how to build a component framework around the createFromXaml method. In ActionScript 3, you can do:

    var t = new TextField();addChild(t);

    In Silverlight 1.0 JavaScript, it’s:

    var xaml = "<textbock text='test'>";text = plugin.content.createFromXaml(xaml);
    
    object.children.add(text);

    Assuming you can create custom components this way, then I guess we’re off. If you read the SDK, the properties and methods are pretty easy to follow. I think Microsoft really has something here. Whether they do or not doesn’t really matter, though; there are tons of people who aren’t leaving Windows Media without spending mad bling, and Silverlight’s induction will help ease those frustrations. I think you’ll continue to see some losses in the Windows Media market as Flash continues it’s rise, but once Silverlight 1.1 gets out of beta, and more managed code applications come out of the woodwork, I’m sure the tide will change; or maybe not. I don’t care, I’m just glad Flash finally has some competition on the horizon.

    In the interim, I know I’ll have Silverlight project soon, namely a customizable video player. There are tons of Flash jobs right now around building custom video players, and soon there will be more for Silverlight ones. A lot of video customers ask for Flash video by name. I have a feeling once the Microsoft marketing engine kicks into high gear, they’ll start to ask for Windows Media again, or even just “Silverlight”, not really knowing what it is, but they’ll have money proving they want it. Besides, there are a lot of people out there already who are deeply into Windows Media; it’s not going away, and Silverlight gives them all the opportunity to have better offerings. In short, that’s cool!

    TOP

  • ActionScript 3 Components?

    What’s out there?

    The following list is what I know of currently.

    1. Flex 2 SDK
    2. Flash CS3 Components
    3. Jumpeye
    4. AsWing
    5. Razorberry

    If you know of any, please add them to the list. I’m looking for more alternatives, if any.

  • When Do You Let Go of 8?

    When is the right time to stop publishing to Flash Player 8 and start publishing to Flash Player 9? I’m struggling with this at work right now. All of my peers at work say “now” from engineering, design, and upper management. Engineering says it mainly from the variety of benefits Flash Player 9 gives us on the video player front:

    • run-time skinning more easily coded
    • easier to generate SWF’s server-side
    • ActionScript 3 is a better language for engineers to contribute

    Just because you move to Flash Player 9 doesn’t mean you have to use ActionScript 3. However, there isn’t much of a point if you have a team of engineers. If you’re alone, sure, you can stop getting compile warnings for Stage.displayMode, and run h.264 run-time video with confidence, all using AS2 or AS1. You can even upgrade legacy content with a simple re-compile.

    Design says it mainly from lessons learned in the past. By designing for the hear and now vs. the future, you limit your scope of what you can accomplish. By the time your efforts are done, the future is already here. Meaning, choosing not to take advantage of Flash Player 8’s design features because of your most recent Google Analytics & other tracking mechanisms was not necessarily the best choice because by the time the endeavors were done, customers were already massively upon Flash Player 8 adoption. Ease of run-time skinning helps as a motivator as well. Both Design and Engineering agree that you are not “excluding the 25%” that doesn’t have 9. Rather, the majority of them are on IE, and those that are can use Express Install without rebooting their browser. That means that those potential customers actually do the upgrade, and thus you don’t lose a whopping 25%, rather you only potentially lose a small amount OF that 25%. I’ve never seen Express Install work on my Mac, but it does work on PC, and that’s what’s important, hehe.

    Management bases it on the short life-cycles of existing content. Clients typically want new additions to existing players. Modifying the code bases to these players already underway, with new features being added, why not upgrade them to the new stuff while your adding new features anyway? Customers will soon start asking for h.264 for valid reasons (the video quality isf’ing sick and doesn’t cost the unreasonable bling that On2 asks)… and start asking for “Flash Player 9” for unreasonable reasons. Either one, however, is a valid business reason (for the most part). Customer wants, customer gets.

    So, I pretty much stand alone in my stance to remain, at least for the next 4 months, using Flash Player 8, ActionScript 2. We have a lot of legacy content that is in Flash Player 8 and below that will never go away and will continue to be supported. New stuff, however, created for a better future based on lessons learned is contentious right now since soo much is at stake. Therefore, it deserves multiple discussions, pro’s and con’s to be laid out, and ultimately up to management to drive the version decision to a conclusion. My stance is that:

    • Flash Player 8 still is king in viewership, 7 much more so
    • Clients who use our API(s) and/or component sets may be at the AS1 to Flash 6 level of coding skills; we need to provide for those customers
    • Clients who are at the ActionScript 3 and/or Flex level, we can support that code base in tandem

    Though my reasons are few, I think they are valid enough to be a strong argument, or at worst a decent devils’ advocate. For the first, the latest numbers of 86% of Flash Player 9 viewership aren’t enough to compel me.

    For the second, most blogs I read and most Flash devs working in the agency world or doing small RIA scope work keep repeating the same thing: “I can’t wait till I get an AS3 project.” Meaning, they aren’t getting AS3 projects. Meaning, those clients they work for aren’t deploying Flash content on Flash Player 9 AND ActionScript 3. The key here is Flash Player 9 AND ActionScript 3. Any Flash user who doesn’t know ActionScript 3 can easily publish for Flash Player 9 in ActionScript 1. It’s the dual requirements here that clearly set the tone. In my opinion, most Flash devs will get AS3 no problem. Package & class name instead of just class name, addChild instead of attachMovie, and stricter strong-typing. Woop dee doo; for some, 4 days, for others, 3 weeks. Both to me are reasonable time frames to get up to speed, especially in the faster paced worlds a lot of Flash devs live in. Let me ad the caveat that I think those are the few, and the rest won’t use ActionScript 3. Either that, or they won’t know that their timeline code is magically being converted to classes. :: shrugs ::

    So, by satisfying that market of customers still using ActionScript 1 and 2 code bases as well as also providing a solution for the ActionScript 3 + Flex world, the only cost is that we have 2 code bases targeted at different needs. Remember, they aren’t the same code bases; 1 written in ActionScript 2 and 1, whilst another written in ActionScript 3. Rather, 1 targets the programmers, and 1 targets the hybrids and designer crowd. To me, that seems the most conservative approach.

    To buttress this argument, Flash’ success was built on it’s scripting being added to support minor interactivity in animations. While ActionScript 1 allowed us to create full blown applications, that was a tipping point for Flash development where a lot of paths diverged. Animators, Developers, Designers… we all used the same product, but in different ways. The one thing we all had in common was lightweight scripting helped us accomplish our goals. Over the time, the developers were the ones who demanded more, especially when the scope of the projects increased, as did expectations, which in turn increased the scope. Awesome cycle.

    If you look at what Microsoft is doing with Silverlight, they are providing the very same scenario, only for a version 1 product. I can’t honestly say what Flash had in 1 and 2 in terms of scripting, but I do know it was enough. If you’ve seen anything in Silverlight 1.0, it’s more than enough. It’s JavaScript, it’s approachable, and it’s strictly targeted at the same market a lot of us Flash Developers came from. The “my animation needs some minor interactivity” market. The download API Sliverlight has is exactly like AJAX on purpose. Both Adobe and Microsoft realized (Microsoft sooner than Adobe) that they couldn’t fight the AJAX market, so instead embraced it. Microsoft knows that while a lot of the hardcore .NET guys who do full-time C# or VB aren’t going the touch the 1.0 version of Sliverlight with a 10 foot pole, there are tons who will. JavaScript never stopped the Ruby on Rails revolution, nor the rest of the swathes of AJAX programmers out there, a lot who also do heavy server-side development.

    The point is, non-strongly typed languages who support animation & rich design systems are a valid run-time environment. They are worth building tool sets and frameworks around as a business model. People will purchase them, and use them in projects. Aka, they aren’t going away. ActionScript 2 and 1 aren’t going away anytime soon, regardless of how many people upgrade to Flash Player 9. While the counter point is that it’ll be easier to find a Java chick and train her on ActionScript 3 vs. finding a Java chick and training her on ActionScript 2, this isn’t a cut and dry argument on just language semantics; it’s about target demographics, and how that demographic uses and perceives code in contributing to their projects.

    All the Flex guys have moved on from Flex 1.5 to 2. With Papervision3D’s (I am Jack’s desire for brrr) success, agency’s are using that as a hopeful tipping point to move to Flash Player 9 (Flash Player 8’s font engine was the tipping point for 7). Programmers from a variety of backgrounds are building ActonScript 3 libraries like crazy. However, I still argue Flash Player 8 to Flash Player 9 migration isn’t as cut and dry as it was in the past.

    1. I was in high-school, didn’t use computers.
    2. I was in high-school, didn’t use computers
    3. I played with it, went back to fabrication & Ultima Online…
    4. I was using Director
    5. I was using Director, but then saw Expert mode, and dropped Director like a ton of bricks; attachMovie vs. sprite channels? Um, no brainer. == yes
    6. Dude, built-in FLEM (aka, dynamic attaching of events to MovieClip’s via code) == hell yes
    7. Uh… middle mouse, fake CSS, and TextSnapshot only for FlashPaper? Well, they DID optimize XML for the 3rd time, has external FLV loading, and it has getNextHighestDepth, so… == yes!
    8. MOTION BLUR!!! Hot fonts, and new Garbage Collector. == yes
    9. Er… faster code? Less RAM usage? Run-time exceptions? I hear programmers like those things, not me, hrm. Dude, why can’t my 9 SWF talk to my 8 SWF? == no …but in Flex, my code actually scales on projects == yes!

    Obviously this entry is skewed toward my job, and my target market. Regardless, I still think the 8 to 9 bridge isn’t cut and dry. It’s complex, and more of a dramatic jump. I think we all agree it’s worth it, it’s just that you can’t assume you’ll never see F8/AS2 & AS1 content ever again, nor have to support it. If you develop API’s for other developers, this is a big deal.

    Are you a Flash Developer that’s let go of 8? How? Why?