Interacting with embedded Flash content in Flex

I've been doing some Flex development lately (sorry Microsoft), so I though I might share a little discovery of mine in return to numerous advices from the community.

While creating a complex Flash application, it is a common situation that the graphical content and animations created by designers in Flash, while developers load them into a Flex application. While loading is pretty straightforward, often you need to manipulate them, i.e., play a different clip, detect then a clip reaches a certain label, etc. What you usually do is have your flash content have a certain base class (called Document class) which is known to your flex app, and cast loader.content to this class once it's loaded.

The problem is, the above solution doesn't work with embedded content. Don't know whether it is a bug or a feature, but the content cannot be cast to the document class. The docs say, use embedded content for static stuff like images or static swfs. Well, my content was an intro to a module, and I had to detect it's finished playing in order to hide it and show the actual content. On the other hand, I wanted it embedded so that my preloader would work correctly. In addition, the module had a base class, and I wanted to have the intro-related code in the base class, while embedding the intro into the actual module.

So, utilizing some hints from the community plus a little debugging session, and here's my solution (I still don't see any reason why it works this particular way).

1. Embed the flash content via the metadata tag:
   [Embed(source="../../flex_bin/someflash.swf", mimeType="application/x-shockwave-flash")]
   private var SWFBytes:Class;
2. Use it in your SWFLoader (note the source):
   <mx:swfloader id="introLoader" source="{new SWFBytes()}" scalecontent="false" creationcomplete="intro_complete(event)">
3. Handle the CreationComplete event like this:
   var content:MovieClip= this["introLoader"].content as MovieClip;
   var loader:Loader = content.getChildAt(0) as Loader;
   var intro:RoomIntro = RoomIntro(loader.content);

Here's the "intro" variable we're interested it, RoomIntro is the document class of the flash movie. Note that the content of our loader is a movie clip, but it's not what we need: it has a child, which is another loader, and the content of *this* loader is what we actually need. In short, we need the content of the first child of the content of our loader.

Tricky, eh?

Get a free TypeMock Isolator + Ivonna

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.

Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

Unit testing private methods.. not again!

This is a question often raised on TDD forums. How do I test a private (protected, internal, Friend) method. Those not so bold ask, should I? A typical answer is, if you want to test a private method, extract it into another class and make it public, and make the first class hold a private instance of this new class.

I think that this answer is too general. While newbies generally want a universal recipe (and this one is good enough), I'd start gathering more info. Like a Zen master wannabe, I'd ask a question which should be an answer to the original one. Oh, and then I'd ask some more.

So, why do you want to test it?

Is it just the idea that every method in a class should be tested? Then resist this temptation.

Another option is that your public method that calls your private method just started acting weird. Well, the next question, what portion of the code just changed that caused this behavior? Still another option, that you dared to write some code without writing the test first, and now you're trying to cover your ass. My humble advice would be to delete the bastard and start all over.

But there are several other important questions to ask. Does the private method have a well defined semantic meaning? If yes, why do you resist making it public? Are you afraid that someone will call it? Why? Are you lazy to document it?

The only reason I can accept here is that your private method puts a system into an inconsistent state. For example, you can have a public Transfer method, which takes money from one account and moves it to another. The two private methods would be manipulation the two respective accounts. If you call one of them, some money would be, say, taken from one account but not moved to the other. In this case, it is unacceptable to move the method to another class and make it public: calling it from outside would be a disaster. In this case, I would simply refactor the system so that no such method exists.

As this begins to sound very confusing, I'd give some reasons for choosing what to test.

• A test is a usage example, a documentation in an executable form. A unit test is, more or less, a feature: you provide a code example on how to use your product. This might be wrong for desktop or Web applications, but the essence remains the same. It would be weird to provide a usage example for a private method.
• One of the main reasons for hiding a method is "encapsulation", as the proponents put it. In other words, you want to hide the implementation details. This is usually a good idea, given that you have a solid reason to do so. Typically, the reason is that you might change it in the future. So, the simple logic conclusion is that you shouldn't test it, since it makes your tests brittle. On the other hand, if you make it public, nothing prevents you from making a changed version later, and keeping this one unchanged (or maybe enhanced, but keeping the same functionality).
• Still another reason: if I make all these methods public, my API will be bloated, and my customers confused. This is a valid reason only for those who are lazy enough to write a good doc. Other possible solutions are: use the EditorBrowsableAttribute; move this method to another class (here we go again!), and place this class in the Internals namespace (or invent some ever more scary name).