InitParams in Silverlight Live Streaming services

One of my favorite implementations is to leverage the initParams feature for the Silverlight plug-in.  This enables you to send parameters to your application prior to it starting up.  These parameters are in plain text and can be seen in the HTML source of your page, so obviously you wouldn’t want to include any sensitive information there like passwords, connection strings, etc., etc.  But it can be very helpful for re-using application logic while providing an configurable experience.  You can view a video demonstration of this and other methods of using initialization parameters on the Silverlight Community site here: Using Startup Parameters with Silverlight 2.

Media is one obvious example here as you could re-use a media player and simply provide the source of the media as an initParams value and then you’ll only have to deploy one player.  This works extremely well and enables you to leverage a content delivery network for the distribution of your app and just provide a different URI for the media each use.

For Silverlight Streaming (SLS) services, however, there is yet a parameter in the manifest.xml file that exposes a mapping of this initParams element to the loader for your SLS application. 

Microsoft® Silverlight™ Streaming by Windows Live™ is a companion service for Silverlight that makes it easier for developers and designers to deliver and scale rich media as part of their Silverlight applications. The service offers web designers and developers a free (please read terms and conditions upon registering) and convenient solution for hosting and streaming cross-platform, cross-browser media experiences and rich interactive applications that run on Windows™ and Mac. Combined with the ability to create content with Microsoft® Expression and other 3rd party tools, web designers and content publishers wishing to integrate Silverlight applications into their online properties can enjoy complete control of the end user experience.  You can sign up for an account that will give you 10GB of hosting space for your Silverlight applications.

Here’s some ways you can still leverage that method.

Method 1 – Bootstrap it

This method really would be considered when you are using some Silverlight application that is parameter driven and you want to simply use the XAP and provide the parameter.  Let’s use the media player scenario here because we can leverage a real application, the SL2VideoPlayer project on CodePlex.  This player is driven by parameters, namely one to set the media URI called “m.”  We’ll concentrate on that one.

Let’s say we want to use SLS to host our player application and we want to simply grab the XAP and upload the player and our media.  As I mentioned, SLS doesn’t yet provide a way to tell it in the manifest that there are startup parameters.  But here’s what you can do, provide a “bootstrap” method to instantiate the Silverlight application.

Step 1 – Create the bootstrap function

Just create a file of whatever you want, let’s call it launcher.js for this demo.  In launcher.js we need to write two functions: one that creates our Silverlight object, the other to call that function.  Let’s see what it looks like, then explain.

   1: function launcher(parentId) {

   2:     var parentElement = document.getElementById(parentId);

   3:     Silverlight.createObject(

   4:         "VideoPlayerM.xap",

   5:         parentElement,

   6:         "playerObj",

   7:         {

   8:             width:'800',

   9:             height:'600'

  10:         },

  11:         {

  12:             onError:null,

  13:             onLoad:null

  14:         },

  15:         'm=<your-media-uri>',

  16:         null);

  17: }

  18:  

  19: function StartApp(parentId, appId) {

  20:         launcher(parentId);

  21: }

If you look at the first function called “launcher” this is the one that does the heavy lifting.  Because SLS will include the Silverlight.js file for us, we can use that API to create the instance of the plugin.  The Silverlight.createObject function generates the plugin tag for us and emits the platform/browser-specific code for the plugin.  Line 15 above shows us how we are passing the initParams argument to the function, which is a parameter of the createObject call in the API.  The second function “StartApp” is what we will tell SLS to use when loading the hosted application.  StartApp matches the required signature for SLS using the parentId (the element of the plugin) and the appId (the SLS application ID) we will need to use it.

Now in our manifest file for our SLS application we can have this:

   1: <SilverlightApp>

   2:   <version>2.0</version>

   3:   <loadFunction>StartApp</loadFunction>

   4:   <jsOrder>

   5:     <js>launcher.js</js>

   6:   </jsOrder>

   7: </SilverlightApp>

SLS will look at this manifest and do two things.  First it will ensure that the Javscript file “launcher.js” is included.  Second it will tell the system to run StartApp as the function to start first. 

That’s it – we package the manifest.xml file, launcher.js, VideoPlayerM.xap and our media file up as a zip and upload to a new application using the web administration of our SLS account.

I mention this as an option, because it does work.  However the nature of this is still pretty much a one-time use because the bootstrap function is a part of the application and thus your “parameters” are coded as a part of the launcher, coupled to this application instance.  This still does, however, help you if you want to use an app that requires it and the parameters won’t change…you’re just trying to re-use some Silverlight application!

Method 2 – QueryString params

The other option is a little work-around.  Whenever you have an SLS application you will have an endpoint to that application.  The format of that will be something like this:

http://silverlight.services.live.com/invoke/accountId/applicationName/iframe.html

Where the accountId is your SLS account id, and the applicationName is the name you’ve provided for the app you uploaded already.  Let’s assume our app was called HostedMediaPlayer and my accountId is 217, it would be this:

http://silverlight.services.live.com/invoke/217/HostedMediaPlayer/iframe.html

Now since our application requires startup parameters, clicking on the link (or using it) would generate our nice Silverlight application that does nothing.  So we need to send it the media source (the “m” parameter).  To do that we can pass in our initParams as QueryString parameters like this:

http://silverlight.services.live.com/invoke/217/HostedMediaPlayer/iframe.html?m=MoonlightInstall.wmv

This translates to the initParam that we need.  So now we could also do something like this:

http://silverlight.services.live.com/invoke/217/HostedMediaPlayer/iframe.html?m=http://silverlight.services.live.com/217/bearee2filerename/video.wmv

And we have re-used the same application, but for a different source, still using the parameter-driven nature of it.  I’ve tested this only using very minimal parameters and ones that are simply (i.e., string based with no funky characters, etc).

Summary

Initialization parameters are an awesome and easy way to create and re-use Silverlight applications that are parameter driven.  I hope these two methods for Silverlight Streaming services help you understand the initParams relationship better with the SLS hosted model.  Of course if you aren’t using SLS and you are hosting your own application, then you ultimately have complete control on how to send those parameters and as previously noted, there is a video on some options with that regard.

Hope this helps!  If you found this post helpful, please consider subscribing to my RSS feed or also subscribing via email.