|
This post originated from an RSS feed registered with .NET Buzz
by Ashish Shetty.
|
Original Post: Silverlight out-of-browser apps: Launch
Feed Title: Even a chimp can write code
Feed URL: http://nerddawg.blogspot.com/rss.xml
Feed Description: Ideas on software and elsewhere by Ashish Shetty: erstwhile chimp and occasional re-inventor of the wheel.
|
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Ashish Shetty
Latest Posts From Even a chimp can write code
|
|
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.RunningOffline)
{
this.RootVisual = new OfflinePage();
}
else
{
this.RootVisual = new SomeOtherPage();
}
}
}
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:
Read: Silverlight out-of-browser apps: Launch
Previous Topic
