Silverlight out-of-browser apps: Launch
Silverlight 3 offline/out-of-browser apps maintain a sticky presence on your desktop upon the initial detach (install) operation. They can be looked up and launched in an experience not unlike the one you see with conventional desktop applications. You can search for and find these apps using OS search utilities (Windows desktop search, Spotlight on OS X) where they show up in as Programs.
Application id
Silverlight uses some indirection from the shortcut to the real app binaries on Windows (however on the Mac, the bundle created on install is the app, with limited metadata squirreled away in the offline application cache). This isn’t because we drink the “architecture astronaut” kool-aid on indirection, rather because doing so in this case allows us to add runtime logic around housekeeping which is effective when updates for the app or runtime exist. If you deconstruct the shortcut to a Silverlight out-of-browser app on Windows, you’ll find a command like this:
“C:\Program Files\Microsoft Silverlight\<version>\
sllauncher.exe <app id>”
Ignore the newlines above. You’ll notice that the app id is a string made with the union of the domain of origin and some random number/text e.g. www.mysite.com.3509. During install on Windows, Silverlight creates a directory hive within your user profile so it can store the app binaries along with other metadata. It also assigns the app an identifier which is unique for a specific user on that machine. It appends this id into the shortcut, wherever the app is to be referenced.
The app launch sequence
When the shortcut is activated, the command is run, and as a result, sllauncher.exe is launched with that app id as argument. The launcher is a container program that chiefly handles the windowing logic for the app, while instantiating and deferring to Silverlight the specific function of loading and running the app. Among the things the launcher controls are the window adornments like icon and title text, a settings such as position. This is just scratching the surface. In future we expect to provide more window customization.
When sllauncher.exe hosts Silverlight, the runtime does a reverse lookup of the XAP file using the app id, additionally collects all metadata persisted in the offline application cache and then initializes Silverlight core services to the provenance URI of the XAP. This is the app’s original site of origin, not the location it was loaded off disk. This cascades into the correct (i.e. original) networking and security settings being applied to the app. All fallback lookups for relative URIs get resolved against the right base URI. All policy settings for cross-domain and cross-scheme access get applied properly; and the app has access to the same local persistence store (Isolated Storage) as its in-browser sibling. If not for the ExecutionState data exposed by the Silverlight runtime, the app would “think” it was running within the browser like it did prior to install. If updates to the XAP were successfully downloaded in a previous app launch, Silverlight will scavenge the old bits and use the updated bits instead. It is now ready to launch the app.
Was the app locally activated?
Upon launch, Silverlight applications can detect whether the current activation was from within a browser, or locally as a standalone window (aka out of browser). This is done by looking at the RunningOffline property of the Application type. When the value is true, the app was locally activated. When false, the app was activated via an OBJECT tag within a web page in the browser.
public partial class App : Application
{
public App ()
{
...
this.Startup += this.App_Startup;
}
void App_Startup(object sender, StartupEventArgs e)
{
if (Application.Current.IsRunningOutOfBrowser)
{
this.RootVisual = new OutOfBrowserPage();
}
else
{
this.RootVisual = new PageToBeDisplayedInBrowser();
}
}
}
Note: we’re changing API names to better reflect behavior; so expect the code snippet to change with Silverlight 3 RTW, but the principles will more or less remain true.
In the next post we will look at network awareness in offline/out-of-browser Silverlight apps. See you then.
Previous posts in this series:
- Introducing Offline and Out of Browser support in Silverlight
- Silverlight out-of-browser support: What kind of apps can you build?
- Silverlight out-of-browser apps: The Install
[Update 10-Jul-09]: Code snippets updated for Silverlight 3 RTW.
Labels: Offline, Out of Browser, Out-of-browser, Silverlight
7 Comments:
Wow very nice article. Can't wait to try it out!
By David Tosi, at April 21, 2009 at 7:59 PM
Amazing and much awaited stuff!,Just like to ask,I tired out running that OOB SL app on different machine where plug-in is not available,Don't you think in such case that offline app should show Install SL? or are all OOB SL are just another shortcuts of sllauncher with certain params? This looks somewhat similar to the old Desklighter utility :) ..thanks for this gr8 article !
By Vikram Pendse, at April 22, 2009 at 2:06 AM
Vikram: we thought about that scenario but figured that if you uninstalled Silverlight, that operation would remove sllauncher.exe as well. This limits what we could do in response to shortcut activation.
By Ashish Shetty, at April 22, 2009 at 4:38 PM
I am of the same opinion as Vikram. I tried the .lnk on another connected machine and it would not activate. What is the ultimate use of this OOB? If you are activating it on the same machine, what is the difference? Also the out of browser switch should be right in the Tools rather commented out in another file. This article is nice as it explains what is happening.
By mysorian, at April 28, 2009 at 1:09 PM
Jayaram: the app is local to your machine. To use on another machine, you need to install it locally there. This assumes Silverlight exists on your machine.
As to what use, this post has details on the kinds of apps you can build with Silverlight's offline and out of browser support.
We're following up with tools support shortly. It will be a simple switch :)
By Ashish Shetty, at May 3, 2009 at 7:22 AM
Ashish: Nice article. Thanks for explaining the internals.
Vikram,Jayaram: OOB works out great when you have a hosted application and would like your users to access like a normal local application. The offline support (basically the network status monitor) helps you in giving additional features (like storing the data in isolated storage when offline and syncing it back to server when online).
If you are looking for portability (copying the application to another computer), then Desklighter is still a good tool, provided all your app content is available within the xap and there is no external dependency (like data/service access). Desklighter supports 'No Silverlight' experience as well.
By Sameer C. Thiruthikad, at September 1, 2009 at 5:45 AM
Hello and thanks for a great article! I'm tackling my first OOB app and the first question that came to mind was, "How will it know what domain was associated with the original XAP?" It was harder to find on search engines than I thought it would be, but then I stumbled across your article. Thanks again!
By Darren Mart, at February 12, 2010 at 1:40 PM
Post a Comment | Home | Inference: my personal blog