Rants Tagged with “Silverlight”
I just finished up with my four talks at the SDN Conference outside of Amsterdam and I had a great time. For anyone who missed it, you missed a great time.
I had four sessions ranging from cloud computing to Silverlight 2. For the attendees I wanted to give you a chance to download the demo source code I wrote for the sessions. You can find it here:
If you have any questions, drop me a line.
In building my Silverlight RC example using ADO.NET Data Services for Entity Framework and NHibernate I ran into what I think is a common pattern. I am writing an editor for XBox game data. The model for this data uses decorator tables in the database which are modeled as a common "Product" class and derived "Game", "Console" and "Accessory" classes. In the application I am using paging to only look at fifty results at once. This works fine on both sides.
But one of the pieces of information I wanted was a list of all the Game Genre. This became problematic as ADO.NET Data Services wanted me to retrieve all 880 games in order to get a list of these Genres (of which there are only 20 some odd). The whole idea of using paging is go avoid the huge overhead of bringing down the whole entity. Interestingly when I executed a LINQ query that used projection into non-entities, the query wasn't supported as projection isn't allowed in the ADO.NET Data Services URI model (which the client uses).
What ADO.NET Data Services does allow is to create Service Operations (e.g. WebGet or WebInvoke) on the Data Service to extend the model for specific cases. There are some limitations (must return IEnumerable<T>, IQueryable<T> or void) but this works pretty well. The difference between returning IEnumerable and IQueryable is whether system queries can be applied to them. Returning a fixed list (my need) meant to return a IEnumerable<T> list. Intersting that ADO.NET Data Services support returning an IEnumerable<T> of primitive types. For example my operation was spec'd as:
[WebGet]
public IEnumerable<string> Genres()
{
}
This works and returns a simple XML file with the primitive values. But alas the Silverlight Data Service Client doesn't support non-entities. I tried using the DataServiceContext.BeginExecute() to call this service and it threw an exception that it couldn't materialize non-entity classes. Hrmph!
This was a case where adding a quick web service call to get this data on the server and return it would have been the easy road, but that's not how I roll, is it?
After confirming this behavior with the Data team, I decided to write an extension to the DataServiceContext class to support this. In this little piece of code, the same pattern of calling DataServiceContext.BeginXXX is used. To make this work I simply use the HttpWebRequest class to do a simple GET to the server's URI syntax and use LINQ to XML to convert the data into the simple types (String in my case).
I've started to help out with some new ideas on the CodePlex SilverlightContrib project so I thought this was the perfect place for this code. Its not packaged up yet in a build (and probably won't be until sometime after RTW ships) but if you want to grab it you can grab the latest checkin I made:
SilverlightContrib ChangeSet 41005
I'll be shipping this new demo as soon as RTW ships (its not done yet). Look for the announcement here.
If you deployed a Silverlight 1.0 application and are having trouble with it working well in Firefox 3.0, Tim Heuer has a fix for you. The fix is to replace the Silverlight.js from the Silverlight 2 SDK with the old 1.0 one. Its a little more elaborate than just that, and go to Tim's blog entry to read about how it works.
In case you didn't catch it, I participated in a webcast called geekSpeak. This webcast was hosted by Glen Gordon and Chad Brooks. The topic today was "Silverlight and Line of Business Applications". While geekSpeak's usually focus on hands-on examples of creating code, we took a different tact today and discussed the larger topic of where Silverlight fits in the development ecosystem (at least Microsoft's ecosystem).
For my money, the real benefit in Silverlight is for applications that cross the firewall. This means Line of Business applicaitons are really for B2B and B2C solutions. Unfortunately, what I hear from the community is that people see Silverlight as a solution for porting their desktop and traditional 3-tier applications to the web. Is this a good idea? I don't think so. The problem is that desktop development usually involves business objects that tend to have a direct connection to the database. Moving these sorts of applicaitons to the web means that you need to create an extra layer of communications and serialization. There is a cost both in development and performance for these extra layers.
It comes down to a key question...why are you moving to a web model for your application? If you want to expand the reach of your application to more users and clients (outside your organization), Silverlight is still a great story. Unfortunately many organizations see web applications as a deployment solution. No install, no framework, etc. While clearly this isn't true for Silverlight per se, its also a bad reason to go to a web application. Technlogies like Click-Once and XBAP are a great solution for a better deployment story than traditional desktop applications.
Since I brought up XBAP, let's plug it a bit. I notice that even amongst WPF guys, XBAP is a lost story. If you're not familiar with it, essentially its an in-the-browser WPF applicaitons that is deployed via manifest files (e.g. like ClickOnce). This means you can have the richness of UI, the better data binding story and interactivity that WPF/XAML affords you without having to deal with the limitations of Silverlight. I suggest that many organizations that want to use Silverlight for internal applications (inside the firewall) should be doing XBAP instead.
So what about ASP.NET/AJAX? The big story here is that HTML-based interfaces still have the longest reach of all the Internet enabled applications. HTML just works on many more platforms and browsers than Silverlight or Flash. Before you commit to moving away from HTML-based UI's, spend some time with your server logs. Understand who is really using your existing application before you leave anyone in the dust. A better strategy is often to include fall-back functionality. For example, in my Silverlight Tour website (http://www.silverlight-tour.com), I decided that developers may have Silverlight installed so I wanted to give them a better experience by showing an interactive map of tour stops. But their bosses and accounting departments were unlikely to have it installed. In that case I made a design decision to never prompt to install Silverlight, but instead if it wasn't installed to show a simple table of the classes instead of the Silverlight app. This is a great solution to moving forward without leaving old users in the dust.
Why is Silverlight not a good solution inside the firewall? The two issues are infrastructure and security. In order to build solid line-of-business solutions with Silverlight, you need to have a way to communicate data with the server. Building this infrastructure can be labor intensive, but more importantly adds complexity. More moving parts == more than can go wrong. Security is the second issue. Silverlight (for good reason) is pretty locked down. This means you will need to often learn to work in tighter confines (limited access to storage, no access to file system, registry, ports). If your application is meant to work in trusted scenarios (e.g. Integrated Windows Authentication), the limitations of the high-security environment will be a real limiter.
So what does this all mean? I still think Silverlight is still the solution when you need to *extend* the HTML model in the browser. Line of Business applications across the firewall still need to be web driven in my opinion, but enhancing that story with Silverlight for soutions like data visualization, user interactivity or media is a great solution. While I think that creating whole-browser solutions make sense for some applications, it doesn't for many many more. My fear is that we will move from monolithic desktop apps to monolithic Silverlight apps. The web is still a disconnected model and deciding on building a single huge Silverlight app (instead of page-based functionality) just doesn't make much sense. If you are planning on building one of these monstrocities, please also read my recent blog about linkability in Silverlight:
http://wildermuth.com/2008/06/25/Doesn_t_Anyone_Bookmark_Anymore.aspx
When I teach Silverlight 2, I stress an important lesson that I thought that we (as developers) had learned the importance of linkability of the web. Early usage of Flash was the first time I noticed this. A number of those sites would create nested functionality that never changed the URL. If the URL doesn't change, i can't bookmark it. Most Flash guys learned their lessons pretty quick, but now I am inundated with AJAX driven sites that try hard to not to do post-backs. That's cool, but if the URL doesn't change I can't link to it.
I've noticed this happening a lot with support sites. The first time I saw with an AJAX site was using the Intersoft's Developer Portal (http://www.intersoftpt.com). They treat the developer to a desktop-like experience, but if I can't send a link to my other developers for the latest patch, why bother making it on the web?
The latest is the game Spore's forums. Trying to help a friend figure out why its crashing, I found some good posts on workarounds but the site's address is always http://www.spore.com/forum. What's the point?
This post is a request...a pleading...begging even. Think about the usability of your sites. If it lives on the Internet, it should be linkable. Now if your site doesn't have state, this doesn't apply to you, but for the other 99.999% of the sites out there, don't get too caught up in the frenzy of AJAX or RIA to make your sites usable. The reality is that you can do this with Silverlight, Flash, AJAX or any web page. It might be more work, but the level of frustration for users is well worth your time.
(NOTE: Microsoft is working on a new version of their AJAX toolkit to enable URL changes during partial page updates. This will help some of you, but the rest of you will still need to do some of the hard work yourselves.)
Adam Kinney has created a new Silverlight 2 Application to show off your XBox Gamercard on your site. I like his design and it is not static so it shows what you're doing at any specific time. What do you think of mine:
Do you like?
The Silverlight SDK contains a couple of interesting gems that aren't appearent in the docs. I'll let everyone espouse the virtues of the runtime for the time being, I'd like to introduce you to a couple of tools in the SDK:
- Chiron: (\program files\microsoft sdks\silverlight\v2.0\tools\chiron): A command-line tool for generating .xap files. If you are building your projects without VS 2008 or want more control over the xap creation (including adding your own files), this is a valuable tool.
- Silverlight.js (\program files\microsoft sdks\silverlight\v2.0\tools\): This file still exists in the v2.0 SDK. Unlike most demos that use either the object tag or the ASP.NET silverlight control, some projects still need a client-side browser detection (and other features) of this JavaScript file. Notably the Silverlight.IsInstalled is a godsend for anyone that needs to optionally show Silverlight content.
What's missing?
- Seadragon: There does not seem to be any Seadragon tools or examples out of the box. Hopefully this is coming soon. To be able to create your own multi-scale images would be really useful right now!
- silverlight.xsd (or wpfe.xsd): You can use the Design surface in VS 2008 to edit your XAML by hand (and get intellisense) but it would be great if we could get the .xsd so we can use the XML Editor (you need the xsd to get intellisense) as its a lot faster than the "Cider" editor.
Now that Silverlight 2 has been released I can announced a re-launched Silverlight Tour site that includes a new outline for the Silverlight 2 classes. All stops of the tour are now all Silverlight 2. For a complete outine visit:
We will be teaching our first Silverlight 2 course in Dallas from March 17th to 19th, 2008 and soon after we'll be in Seattle from April 9th - 11th, 2008.
Mary Jo says that Microsoft and Nokia are working together to get Silverlight working on Symbian phones. It will be a fun next couple of years playing with Silverlight on a variety of devices...
More details on News.com:
http://www.news.com/8301-10784_3-9884398-7.html?tag=nefd.top
This story includes a quote that Silverlight will run on Windows Mobile by the end of the year...yum!

There has been a lot I couldn't talk about these last 4-6 weeks. Suffice to say that coming up Tuesday or Wednesday, I will be opening the floodgates of information that will be released at MIX 2008 this week. If you're going to be there, please look me up. I be around all four days if I am not at the poker tables.
I am very excited about this upcoming release of Silverlight and I will let you know what I think of it all. Please watch here if you're as interested as I am and i'll try to give you the gory details (without a minute by minute update that some websites are apt to do).