If you can do it in JavaScript, you can do it in managed Silverlight .NET code
Just because you can do something doesn’t mean that you should do something. Just because you can get Quake to run on your iPhone doesn’t mean that’s the best way to do things. But it’s pretty cool!
Now that we’re clear on that one, this is the part where I show you that you can do a ton of stuff in Silverlight, through the JavaScript interoperability features.
Reaching out to the browser can help you improve the fit and finish of your Silverlight application and to integrate with existing services.
So, if you can do it in AJAX/JavaScript, you can totally do it in your Silverlight application when it is hosted in a web browser.
Reasons not to use the “HTML DOM bridge” (JavaScript interoperability features) in Silverlight:
- Feels “Hacky”
- Leads to spaghetti code – the calls are very procedural and you lose the nice strongly typed features of your .NET language of choice
- One line of JavaScript often takes 3 or 4 lines of managed code to accomplish the same thing via the interop syntax
- The rich presentation framework in Silverlight is pretty awesome – you should use it!
- Potential performance implications having JavaScript – native code – managed code all involved with timers, marshalling, etc.
- Can just use JavaScript without requiring the Silverlight 2 runtime
Reasons to use it:
- Interact with the web browser host: set the page title, alter the plugin, add dynamic HTML content on the fly
- Bridge classic web applications, AJAX apps, and rich Silverlight
- Can replicate the experience of a server-side application, with web forms, HTML elements, and more – all on the client-side, without having to go back to the server to run an ASP.NET or PHP application
- A lot of analytics and advertising systems are exposed great in JavaScript
What follows is a list of some previously covered articles and examples. They may be out of date; for instance, in the Release Candidate of Silverlight, you now use the ScriptObjectCollection instead of the HtmlElementCollection. Mike Snow has a nice list of the breaking changes.
Access and create JavaScript arrays from managed code
You can access JavaScript arrays, but because of the loosely-defined, “do anything you want in JavaScript” way that things work, it leaves you with pretty unattractive managed code.
VB samples are here. Some C# samples:
// Create an array
var array = (ScriptObject) HtmlPage.Window.Eval("[10, 9, 8, 7, 6 ];");
// Get the length of an array
int length = (int)((double)array.GetProperty("length"));
// Return a single element by index
var singleElement = array.GetProperty(index.ToString())
Resize the Silverlight plugin
You can change the size of the plugin and its host element. Here’s some Visual Basic that makes a “zero-pixel” plugin:
Imports System.Windows.Browser
Namespace System.Windows.Browser
Public Class ZeroPixelPlugin
''' <summary>
''' Resizes the Silverlight plugin and its host element to be zero pixels
''' in width and height. Only really useful for HTML
''' </summary>
''' <remarks></remarks>
Public Shared Sub HideSilverlightPlugin()
Dim plugin As HtmlElement = HtmlPage.Plugin
Dim host As HtmlElement = plugin.Parent
plugin.SetStyleAttribute("width", "0")
plugin.SetStyleAttribute("height", "0")
host.SetStyleAttribute("width", "0")
host.SetStyleAttribute("height", "0")
End Sub
End Class
End Namespace
Get information about the browser and physical screen
Wondering what the color depth is of your end users? Want to work with the available screen size? All this information is exposed by JavaScript and you can easily read the values in C#.
Here’s a simple static class that does the work for you. The class takes care of the differences between the NPAPI web browsers and Internet Explorer, so your application doesn’t need to worry about it so much.
Store text in the clipboard
If you have information that you want your end users to be able to copy into the clipboard, you only have a few options:
- Place the text in a TextBox control, allowing a user to select and press Control + C or Command + C to copy it into their clipboard
- Use interop features to talk to the web browser, or other plugins
Here’s a solution that uses the browser APIs in IE, and another plugin if you’re on a non-IE browser. It isn’t perfect, but it’s an interesting hack.
Generate an entire HTML/AJAX-style user interface
You can write complete applications, just like an AJAX app, using managed code. Your business logic and other components benefit from strongly typed, easy-to-edit C#. Your application can be delivered through a .Xap, and doesn’t have any server side dependencies if it is written just right.
Here was a homepage “link cloud” app. It hasn’t been updated in a while, but most of the code should work without changes in the release candidate.
Some of the things the app and the post show:
- Creating and managing HTML elements in .NET
- Attaching and working with HTML DOM events
- Using IsolatedStorage for saving information on the local machine
Interface with web analytics software
A while back (yeah, Silverlight 1.1 days) I posted about interfacing with Google Analytics / Urchin. Although the information is still useful, Google did make some major updates to the APIs, so I’d recommend not using the Urchin implementation in the post.
Anything else cool?
If you’re using the DOM bridge to do some interesting stuff, feel free to post a link here – I’d like to post about the neat uses at some point in the near future.
Well, I hope that gets you started working with the interop features a little more. Done right, you can start wearing a T-shirt the says “I do it in JavaScript… AND in .NET!”
Hi Jeff,
I’m a big fan of the HTML bridge, and have done lots of interesting stuff with it. I think the most fun example is my webcam proof-of-concept application that uses the HTML Bridge + JavaScript + Flash to capture Web Cam still images.
(http://jonas.follesoe.no/WebcamInSilverlight2NdashSlidingPuzzleGame.aspx)
I’ve also written a post explaining how to use the new History Management feature in ASP.NET AJAX 3.5 SP1 with minimal use of JavaScript (http://jonas.follesoe.no/BackAndForwardNavigationInSilverlight2UsingASPNETAJAX.aspx).
One of the issues I ran into is that the ASP.NET AJAX client library has it’s own “type system”, and does type validation of parameters passed into functions. If I pass a CLR type from Silverlight to the ASP.NET AJAX client library (in the addHistoryPoint function) I get an error saying my type is a ‘Function’ and not an ‘Object’. Other than that it works just fine
Would it be possible to use the bridge to communicate with a Java applet? Say I have a Silverlight game that it makes sense to use UDP as my network communication, but Silverlight does not support UDP. However, I can write a little Java applet that does support UDP and can act as my proxy. Could I then use the bridge to allow my Java UDP proxy applet to communicate with my Silverlight game client and visa versa? Just trying to think outside of the box and stretch the technology.
Another reason to use it:
Because sometimes you have to! Silverlight 2 RTM won’t include native printing. So if you want print out of Silverlight, you have no choice but to leverage the HTML bridge. Other uses include getting some info that Silverlight doesn’t have access to: i.e. list of files on the c:\ drive or your example of the screen resolution.
I think you left an important reason NOT to do it: There’s a huge overhead in making calls between the JavaScript and Silverlight spaces.
What if your Silverlight app isn’t running in a browser? If you start depending upon the browser and specific Javascript and DOM functionlaity how will these fair on a mobile or Mesh application or something else down the track?
@Jonas: Awesome! History management is a nice browser perk, good post.
@Chris: Well, I’m not sure what level of communication there is between Java and the browser host, but if you can bridge that gap, it can be done. Jonas posted a Flash + Silverlight system to integrate Flash’s webcam support into a Silverlight app, for instance.
@Bart: Yup, good one.
@Morton: I briefly mentioned the performance implications of native/managed/script interaction, but it should be bold. At one point I ported the ASP.NET AJAX toolkit animation library to the DOM bridge, and it worked fine for my needs… but the native/CLR transitions are expensive for the reason you point out.
@SoulSolutions: Yeah, these are only useful when hosted in the real browser. You should be able to check (on the Silverlight 2 runtime at least) the System.Windows.Browser.HtmlPage.IsEnabled property to know if your host supports the browser extensions.
It is important if your app or components will be opened in Blend that you check this property before doing too much, since you really are assuming it is a part of a larger system that you control at the point you use interop.
[...] Jeff Wilcox said in his blog article, just because you can do something, doesn’t really mean you should do it. This is directly [...]
Rich Text entry is another reason. There are third party RTE’s, but the html versions are better right now.
They are capable of import/export with Word and other applications through the use of a standard format. All of the Silverlight RTE’s appear to have no interop with HTML/RTF, ro even XAML.
it’s difficult to save the file to the user’s computer(prompting the file save dialog), while it’s pretty easy with asp.net.
yes, you can involve a webservice to simulate, but not straight forward.