I've just finished work on upgrading my Silverlight based amazon search engine app "Tarantula" to use the final release of Silverlight 2.0. Its taken a year and a half since what was first known as Silverlight 1.1 was released as an alpha (and coincidentally my first blog post here) to this latest release. In that intervening time I've had to upgrade the application 4 times to alpha refresh, beta 1, and beta 2 and finally to the release version.

To be honest, this latest upgrade was probably the simplest, as there were relatively few breaking changes between beta 2 and the final release, owing to the fact that Silverlight had become pretty mature and fully featured by the time the second beta rolled around. If your interested, check out Tarantula here and see the results of my efforts and frustrations :)

I finally got around to updating my silverlight Amazon.com search engine Tarantula to work with silverlight 2 beta 2 (see it in action here). This update included some relatively minor (as opposed to the wholesale changes from 1.1 alpha to 2.0 beta 1) though essential enhancements. Most of the changes that have been made have been in the area of control templates which were a bit lacking in the first beta release. The introduction of the visual state manager is great and allows for smooth transitions from one control state to another, so I could re add the nice button highlight effects present in the original alpha version of tarantula but which I had to remove in the first beta.

However the reason that I took so long to update Tarantula to work with beta 2 is that Microsoft in their wisdom decided to change the format of remoteaccess.xml files which silverlight applications will accept. To cut a long story short this means that the remoteaccess.xml files used by the amazon.com web services and many other web service providers is now incompatible with silverlight beta 2 clients, rendering those services inaccessible.

So to remedy this I had to write a proxy for the amazon.com services that was hosted on an accessible domain. However I could not be bothered writing a wrapper for the Amazon.com web services (like I did for the alpha version of silverlight) So I wrote a general purpose soap proxy component to do the work for me.

It works as an ASP.Net httphandler and maps local proxy endpoints to their real locations elsewhere on the net. To get it working all you need to do is have an ASP.Net website that will operate as the proxy, add a few config elements to the web.config, then point the silverlight client to the proxy address, and it will all just work as if you were communicating with the services hosted on an inaccessible domain.

In addition to the usual web.config changes to add an httphandler (detailed in the instructions bundled with the soapproxy components download) I had to add the following config entry to the apps.junkship.org site to map the proxy end point to the real amazon service endpoint

<soapProxyComponent>
  <endPointMappings>
    <mapping proxyEndPoint="amazon.ashx" remoteEndPoint="http://soap.amazon.com/onca/soap?Service=AWSECommerceService" />
  </endPointMappings> 
</soapProxyComponent>

Then in Tarantula I had to change the service endpoint in the ServiceReferences.ClientConfig to point to the proxy address instead of the real endpoint.

<endpoint address=http://www.sharpoblunto.com/amazon.ashx
    binding="basicHttpBinding" bindingConfiguration="AWSECommerceServiceBinding" 
contract="Tarantula.AmazonWebService.AWSECommerceServicePortType" name="AWSECommerceServicePort" />

In practice it's worked perfectly and I've bundled the component up for download (either binaries or source code) here, hope it comes in handy for those trying to access third party web services from silverlight beta 2 apps.

After my earlier experiments with the alpha releases of Silverlight 1.1 I was extremely keen to give the newly released Silverlight 2.0 Beta 1 a run for its money and port my Tarantula silverlight application from Silverlight 1.1 to silverlight 2.0.

 

 

 

Now This was easier said than done, not because silverlight 2.0 is difficult to work with (compared to the alphas its a breeze) but because pretty much everything has changed.

 

The addition of user controls (no need to create custom text boxes anymore!) has meant that the xaml markup is a lot closer to what you'd find in WPF, with grid and stackpanel layouts, control styles, and control templates. This means that you can now separate style from structure in the xaml much more effectively and apply consistent styling to user controls. Unfortunately there is a lack of events that control templates expose, for example on mouse exit is not exposed for button templates meaning that fade out effects on buttons are not possible without custom code/markup.

 

Whereas before silverlight app's were deployed as a collection of DLL's and xaml files, they are now deployed into a .xap package, which is just a zip file containing the DLLs, but its a lot tidier and shrinks the download size for silverlight app's.

 

Web service support has drastically improved since the alpha releases. In 1.1 cross domain http requests were not allowed meaning that in order to create a silverlight mashup utilizing external web services you had to actually implement a server side web service proxy to the external services. This was a huge hassle and has thankfully been done away with in 2.0 as you can now make cross domain requests provided that your domain is permitted by their cross domain policy file. Another annoyance in 1.1 was that only JSON web services could be consumed. this has been changed and now it is possible to consume WCF and standard SOAP web services.

 

 

 

The result of all these changes was that I had to pretty much rewrite all my xaml, and the back end web service code. However thanks to the wonders of the Model View Presenter (MVP) pattern, In particular the Passive View variation of MVP I didn't need to change any of my application logic. The other great thing about the Passive view pattern is that because the View can easily be implemented as mock objects (using Inversion of control and dependency injection) the controllers can be completely unit testable (though I was to lazy to implement any tests :)).

 

The final result is that my application is functionally identical to the original application, though it was much easier to get it all up and running this time than it was the first time, Silverlight is progressing nicely and I am looking forward to the next release. You can find my application here and source code is available for download here

After hearing a lot about Microsoft's Silverlight recently (that and the possibility of loot to be had via a Silverlight coding competition at work :)), I decided to try my hand at a bit of Silverlight development. Basically the idea was to try and build a small demo app that showed off some really wacky stuff that isn't really possible (or practical) to implement using existing web based technologies.
I pretty soon settled on the vague idea of interacting with some sort of third party web service in order to test out Silverlight's ability to leverage existing services and visualise them in strange new ways. Once I'd decided on this I pretty quickly decided to do something with Amazon.com's e-commerce API as I had had some previous experience using it. At the same time I was also fooling around with creating a game based around swarm intelligence (and since got bored of before finishing) which had me thinking about cells and networks.
Combining these two thoughts gave me the idea of writing an application which could search over Amazon's catalogue of books and visualise the results as a group of physical nodes. The user would then be able to drill down into the nodes to find books that were similar, where similar nodes would be connected to the original node creating a visual network.
So after coming up with the idea I looked into actually implementing it and to my dismay I found that Silverlight 1.1 was designed only to work with the upcoming Visual studio Orcas, not Visual Studio 2005. However with a bit of jiggery pokery I was able to get it all running fine in Visual Studio 2005 sans the ability to debug (but my programs contain no errors anyway so that was no problem!).

The web service

Silverlight 1.1 has the ability to with asmx web services using JSON, however it (as of the alpha release) allow you to make cross domain web service calls. This meant that in order to query Amazon's services I would have to write a proxy web service sitting on the same domain that forward the requests on to Amazon then send the results back to the Silverlight client. Though this makes accessing 3rd party services more work, it is relatively painless as there is no difference in writing a Silverlight accessible web service from a standard asmx web service apart from tagging the service class with the [ScriptService] attribute.

Rag-doll physics?
Since I was going to create a visual representation of nodes and links, I thought that the whole app would function much better if everything had a physical tactile feel to it and that the nodes would self arrange in to easily viewable formations, and that meant adding... physics. In the end I decided to model the system as a series of particles which repel one another (meaning that they would arrange themselves nicely on screen) and can optionally be connected by springs (for related nodes).
I implemented this physics model using a simplified Verlet integration scheme (sounds very elaborate but its actually quite straightforward - there's a good article on implementing it here). This method used to be quite popular in the games industry for simulating cloth and rag-doll effects and was used in titles such as Hitman: codename 47 before the industry moved toward more advanced techniques such as inverse kinematics and constrained-rigid-body approaches.
A handy thing I found while developing the physics engine was that because Silverlight uses the same CLR as the full .net framework I could write the physics engine as a standard .net 2.0 class library and test it using a simple Winforms client (as I couldn't do any debugging with Silverlight) then when I was happy with it, I could import it straight into my Silverlight solution, and after changing some references from the standard .net assemblies to the silverlight assemblies it ran fine.

Silverlight client
After implementing the web service back-end and the physics model it was time to hook it all up with some Silverlight eye-candy. Due to the fact the I was working with an alpha release, there is very little in the way of user controls available. This means that unfortunately many standard components such as text boxes and buttons have to be made from scratch. In saying this though, Dave Relyea has produced a controls framework (found here) containing many of these standard controls and though I didn't use his framework I did use some elements of his text-box control when developing my own.
While most of the effects found in WPF are present in Silverlight there are still a few omissions which I found to be a bit annoying, in particular the bitmap effects such as blur are not included in Silverlight which meant that I couldn't add in all the effects I had originally planned, hopefully these effects will be added in for the final release.
On the plus side, I was impressed by Silverlight's rendering speed even at this early stage in its development, as I went out of my way to fill the whole screen up with as many shiny gradients and subtle animations as possible (in addition to the physics modelling) and it still ran along at a decent clip and was responsive to user input even on lower spec machines. 

 
Not just eye candy
In addition to the draggable books and physics already in-place I wanted to try and implement something that would at least hint at the fact the having all this rich client functionality allows developers to create experiences that are not only more attractive, but also more responsive and in some ways fundamentally different to what is possible using traditional web technologies. My attempt at this was to implement some gesture based controls into the application such that if you shook a book that was connected to another book it would break the link between them, this made it much easier to keep books you wanted on screen and delete unwanted items in a way that felt natural given the physical representation of the books on-screen. While I didn't have the opportunity to pursue further gesture based controls, It certainly would have been possible to remove almost all the buttons from the GUI and have an entirely gesture based interface. 

 
While its very debatable whether my application is useful rather than just fun to play around with, I think it does illustrate the point that Silverlight has a lot of potential to create some very interesting and powerful experiences on the web, and while there are certainly some issues present in the current releases, I can only see it getting better from here.
If you want to check it out my app, I've got a demo here. If you want to take a look at the source code I've got a copy here (updated to run with Silverlight)