Silverlight in JavaScript (1.0) vs. Managed Code (2.0, formerly 1.1a)

I have recently begun work on a Silverlight 1.0 project and for the first time had the (un?)fortunate opportunity to write a significant amount of JavaScript. I am not sure how hotly this topic is debated, or if it is even debated at all, but I wanted to come out and discourage anyone thinking about building a Silverlight RIA from doing it in JavaScript.

Now I am not knocking the JavaScript implementation of Silverlight. It works well enough. But JavaScript is a clunky and cumbersome development environment. Browser consistency is a problem, performance is exponentially slower than managed code, and the language has huge deficiencies like a lack of type safety and nothing close to the facilities provided by the .NET framework.

Unfortunately 2.0 is still in alpha, and I know that building anything with alpha technology is a scary prospect. While it isn’t much consolation right now, I think the beta will be a much firmer platform, and one that can be carried forward into release. If you can hold off till it hits I think you will be in a much better position. If you absolutely can’t wait, use Flex.

-Casey

Debugging Silverlight 1.1 Alpha Refresh in Visual Studio

I have gotten back into some Silverlight code and have been playing with the new version of Visual Studio 2008 and the Silverlight 1.1 alpha refresh. Since picking it back up I have run into some interesting speed bumps that were not there my first time around.

The 1.1 alpha refresh introduced a stricter Silverlight security model which completely disables access to any asset on the local file system. This means if your app utilizes external resources, you have to debug it via a web project of some sort. I was already using an IIS project for deployment so switching over wasn’t a big deal for me, but I had to go through some rigmarole to get it set up initially. For ASP web developers, it is probably all old hat, but for someone with no prior experience, it is an annoyance to have to set it up just so you can debug a Silverlight application. Plus you have to be running certain versions of Windows. Overall not a very friendly way to get your feet wet with Silverlight.

So what is the answer? Well there is an internal web server built into Visual Studio called Cassini. Using it and VS you can quickly create a web project that you can then link to your Silverlight application and test locally.

The process goes like this: right click on your solution that houses your Silverlight application and select Add -> New Website. In the dialog box that appears, select ASP.NET web site as the template, make sure the Location combobox is set to “File System”, and enter the path you would like the site created in. Once the project for the site is created, right click on it and select Add Silverlight Link. A dialog should appear that lists your Silverlight projects within the same solution. Click on the one you want linked in. If it asks you if you want to enable Silverlight debugging, say YES! You should now see the files for your application that are set with a build action copied into your web application. All that remains is to right click on your start page and select Set As Start Page. You should now be able to launch your Silverlight application locally and do anything you need to for testing.

If for some reason you find that the debugger isn’t loading your symbols for your application, or inexplicably skips over your break points, check that the debugging properties are correctly configured. Right click on the web project and select Property Pages. In the dialog box, select Start Options on the left side. At the bottom you will see the debuggers that are enabled for your project. If Silverlight is already checked and you still can’t debug it properly, try enabling Native Code as well. I have run into several instances where I have had to do this to get the debugger working.

-Casey

Reflections of Style

I’ve been playing around with the new Reflex Utility from Alon Kandov. It is a very useful little application that allows Flex authors to easily examine and modify the properties of any visual component at runtime. You can experiment with styles and designs similar to the Flex Style Explorer while your application is running. It has obvious general utility, but especially so for those that cannot or will not use the Flex Builder design editor.

There are several different ways to get it into your app, including direct compilation. However I prefer the modularized version that was just added. You can load it via a ModuleLoader when it is appropriate and don’t have to worry about changing your code around when it isn’t.

There was only one gotcha that I experienced integrating it. I use Ant to compile my Flex 2 applications and in order for Reflex to be able to show style information, the compiler must be told to preserve the related metadata, which by default it does not. The command line syntax to do this is listed on the Reflex code site, but the Ant syntax is a little more enigmatic. So after a little bit of digging and some trial and error, I finally pinned it down. Here you go:

<!– compile application –>
<mxmlc file=”${mySourcePath}/MyApplication.mxml”
output=”${myBuildPath}/MyApplication.swf”
default-background-color=”#FFFFFF”
actionscript-file-encoding=”UTF-8″>

<load-config filename=”${FLEX_CONFIG}”/>
<source-path path-element=”${FLEX_FRAMEWORKS}”/>

<keep-as3-metadata name=”Bindable”/>
<keep-as3-metadata name=”Managed”/>
<keep-as3-metadata name=”ChangeEvent”/>
<keep-as3-metadata name=”NonCommittingChangeEvent”/>
<keep-as3-metadata name=”Transient”/>
<keep-as3-metadata name=”Style”/>
</mxmlc>

I hope that helps get Reflex going for you because it is a big chunk of cool.

-Casey

Leopard Attacks

I am one of the many, many Flash developers hit by the now infamous Leopard upload bug. I don’t have a complete solution for anyone but I do have a small amount of advice on how you can get your apps to at least fail gracefully when faced with this game breaking bug.

In AS3 you can use the Capabilities class to detect the operating system your user is running. In Leopards case, the Capabilites.os property will have the exact value “Mac OS 10.5.0”. Once you are aware, you can then do whatever it is that might be appropriate for your app.

Hopefully this bug won’t be around long, but until it is fixed, happy cajoling!

-Casey

!super

I recently spent a good deal of time debugging an issue that one of our Flex apps was having with TileList extensions. Eventually I worked it all the way down to the collectionChangeHandler in TileBase. The handler was setting the horizontal scroll position regardless of whether or not the direction of the TileList made it appropriate. On a side note, I also found out later that this bug is now fixed in FB3 Beta2.

Anyway, my problem with this bug was the available options to fix it. My first and most obvious attempt to resolve it was to override the collectionChangeHandeler in my extensions. Unfortunately this failed due to the fact that the code in TileBase is fairly tightly coupled to the code in ListBase, its parent. This meant that if I wanted to override the function in my TileList extension, I had to rely on the super function in ListBase. But there is the catch! It isn’t the super function, it is the super.super function. And guess what, that isn’t supported in AS3. You cannot skip over the implementation of a function in an inherited class if you want an even earlier one. You can only override the previous instance in the chain. If you can’t get around having to write the override you have to then override all the functionality in all the super functions. Major Bummer.

{Confusion}

I’ve been doing more work in Flex recently and I have become increasingly dissatisfied with some of the features. The technology itself isn’t the problem. It’s the design trap that it creates.

Binding makes it seemingly so easy to feed data into your view that you can get very carried away with it. You can end up with mxml components which declare other components and use so many bindings to set various properties that you create an explosion of binding execution at runtime.

At this point I think class based “code behinds” that use property invalidation are much cleaner. You can ease the performance hit of your app by cutting down on the overhead of binding. You can eliminate all the script you would otherwise put in a script node to make your component more readable. You can also avoid actually writing business logic in your bindings. This leaves a very clean mxml component almost entirely dedicated to layout code. It may not be everything that Adobe envisioned but it’s certainly easier to read, understand, and maintain.

-Casey

Flex is not Flash

The Fisix engine that I mentioned in a previous post is actually distributed as a Flex 2 compiled library.  Much to my dismay, I learned that this library is not compatible for use in a Flash CS3 movie and it doesn’t seem like a compatible library will be forthcoming anytime soon.  For my project, we didn’t want to give up the engine, so that meant finding a way to build an animated “conventional” style Flash movie in Flex. 

The entire dilemma, as well as the research required to find a solution, really illustrated to me how different the Flex and Flash products really are.  Before now I had built Flash movies, and Flex applications, but I had never tried to use Flex as a development environment for a Flash movie.  I had heard so many times that “Flex is Flash” that I was under the assumption it would all just work.  I was so young, so naïve. 

The problem is that normally when embedding external swf assets into a Flex application, you have no control over or access to the timeline that might have been in the asset.  Adobe’s solution to this is apparently the Flex Component Kit.  This extension to CS3 allows you to export a Flex compatible swc that houses your assets in class form.  They extend a new Flex class called UIMovieClip which can operate as a Flex component as well as provide access to the timeline.  The component kit got my project back on track, so I am grateful to Adobe Labs for providing it, but there are still issues with it and how Flash and Flex coexist. 

First of all, the component kit is prerelease software.  I haven’t noticed any serious bugs with it, although I have had trouble embedding Flex exported components in the timeline of other Flex exported components.  I have had to do that in code.  Secondly, the documentation is provided in a zip file.  This beats no documentation at all, but I sincerely hope this gets moved into the api for Flex 3.  I don’t enjoy hunting around my disk when I want to look at the properties of UIMovieClip.  My last and most important gripe about the component kit is that it is distributed as an extension.  This functionality needs to be a baseline of both the Flash and Flex products.  I don’t want to jump through hoops to make these products interoperate.  Make it easy, make it seamless. 

Now after complaining about the current state of affairs, I do see good things on the horizon.  There is a presentation linked on the component kit page that describes some of the ways they are improving the integration of Flash and Flex 3.  I think they are steps in the right direction and I will probably migrate to Flex 3 sooner rather than later. 

-Casey  

2nd Interview Online.

Just a quick post to let everyone know that the second Silverlight interview I did is live.  You can watch it here.  Be forewarned that it is pretty long, weighing in at a hefty 28 minutes.  I hope you enjoy it. 

-Casey

Let’s Get Physical

I am back in the Flex/Flash world and working on more games. This time around I have had the opportunity to work with a 2D physics engine in ActionScript 3. Our current choice is the Fisix engine which like the last technology I worked in, is very much in development. Just for context, I have never worked with such an engine and this is my first exposure to this type of modeling.

My first impression is that physics in games is a lot of fun. Experimenting with ideas about structures and interactions is a blast. Unfortunately, if you do not already know the principles behind these engines discovering how to properly model something can be a bit of a chore, especially in a system like Fisix which has inadequate documentation. I am now at the point where I know enough to be dangerous and have found a couple of quick tricks that other users of the engine might find helpful.

The engine has a tendency to allow quickly moving objects to penetrate surfaces, which is not desirable. There are three things that I found that you can do to try to limit this behavior. The first is the most straightforward. You can specify the collision detection mode via an enumeration defined in the DetectionModes class. Setting this to a non-default value can give you better results. I went all the way up to RAYCAST and with only a few objects moving at any given time the performance was fine. The documentation says this detection mode prevents tunneling, but I beg to differ. I had to find a few other workarounds to limit its likelihood.

The second solution I found is to increase the width of the colliding surfaces. In my instance I was freely able to increase the width on one, but not both. It was sufficient though. Instances of penetration dropped dramatically. However, I know that for some applications this just won’t be possible, and there is a third option.

The last option I found is the most risky and should be used with the most discretion. It has to do with the number of instances the collisions are solved each frame in the engine. You modify this property via the setIterations method of any FisixObject. The real gotcha with this is that the iterations value of each FisixObject multiplies the number of iterations its parent must perform. If you aren’t careful you can end up with FisixOjects performing hundreds of solutions every frame and that is no good.

After working on this project for a time I am excited about the possibilities this type of modeling brings to the flash world. The interactivity and realism you can get from the physics interactions is just fun and games can always use more of that.

-Casey

Intertron Superstar

I went down to Redmond recently to do a few interviews about the game we just built in Silverlight.  The first one is available now over at on10.  Overall it was a good experience, and I will link the other interview once it is online.

-Casey