During my presentation at Microsoft DevDay a few days ago I promised to share the code I was showing there. Here’s the first set, with more to follow (maybe in a few days, depending on my schedule).
During the presentation I was talking about how users do not care about what technology was used for making the application (obviously), and instead they just expect the application to behave like other similar or related applications. So, to a user, a Silverlight application is just like any other web application because they use a browser to access it. If the technology itself has certain limitations that is of no interest to the user.
Because Silverlight is heavily sandboxed you can only get access to some of the things going on in the browser, and the back- and forward-buttons (and history management) is not among those. Still, being able to use the back- and forward-buttons is something users expect to be able to do. There’s different ways to solve this, but many of them end up being either browser-specific in one way or the other. However, a month or so ago I came across a post by Jordan Knight that shows an implementation based on features introduced in ASP.NET as part of .NET 3.5 SP1. The code I showed in my presentation was more or less directly influenced/copied from his approach, so all the credit for this approach belongs to him.
For the DevDay-presentation I made a simple sample application, pictured on the right. There are three buttons, with which the user moves to different parts (modules) of the application.
When the user presses one of the navigation buttons the new position gets added to the browser history.When the user clicks the forward- or back-buttons (or uses the browser history to select a previous position) the application is notified of this and shows the appropriate module.
So how does this work? For a full explanation I really recommend that you read Jordan Knight’s original post, as the sample I made doesn’t really add anything new to it and his explanation is very detailed and easy to follow.
The principle behind the technique Jordan describes is that a bit of JScript is used as glue between the browser and the Silverlight application, and this enables the Silverlight to react to history-related events in the browser.
Download the code here.
The interesting parts are in the following files:
- SilverlightBrowserNavigationTestPage.aspx
Here the History.js is loaded, and the OnPluginLoaded-event on the Silverlight plugin is wired up to an event handler in History.js. - HistoryManager.cs
Used for interfacing between JScript (History.js) and the rest of the Silverlight application. - App.xaml.cs
Here the HistoryManager is instantiated, and a new property is introduced (History) to expose it to the rest of the application. - Page.xaml.cs
Events fired by the HistoryManager when the user uses Back/Forward are handled here, and the appropriate module is shown.
Enjoy the sample.
Comments