Silverlight Application Lifecycle

Analogy categoryAnalogies

Overview

When a browser finished loading a page containing the Silverlight <object> tag, the plugin initialized its embedded CLR, downloaded and unpacked the referenced .xap package, read AppManifest.xaml to locate the entry-point assembly, and instantiated the Application-derived class defined in App.xaml.cs — at which point it raised the Startup event, where developers conventionally assigned Application.Current.RootVisual to a MainPage instance, the UserControl that would actually become visible on screen.

🏏

Cricket analogy: The sequence from plugin load to Startup is like the toss ceremony before a match: the pitch report is checked, the manifest, the captains are confirmed, the Application class, and only once the coin lands does the umpire signal play can begin, the Startup event.

Once running, a Silverlight application handled several lifecycle events beyond Startup: Application.UnhandledException fired for any exception escaping managed code, and leaving it unhandled in early Silverlight versions could crash the plugin silently, so production apps always wired a handler that logged the error and set e.Handled = true; the Frame control's Navigated and Navigating events supported page-to-page navigation within a single .xap, mimicking multi-page browsing without a full page reload; and the host page's resize behavior combined with Silverlight's own SizeChanged event let a Canvas or Grid adapt its layout whenever the browser window changed size.

🏏

Cricket analogy: Application.UnhandledException catching a stray exception is like the DRS catching a bat-pad edge the on-field umpire missed, a safety net that reviews and corrects a problem before it wrongly ends the innings, the whole plugin session.

Shutdown: Application_Exit and Cleanup

When the user navigated away from the host page or closed the browser tab, the plugin raised Application.Exit, giving developers a final, brief opportunity to persist state — typically into IsolatedStorageSettings.ApplicationSettings, a synchronous local write — since anything relying on a pending network call was best-effort only, as the plugin could be torn down mid-request. Unlike a WPF desktop app, which had a comparatively generous and predictable shutdown sequence, a Silverlight application had no guarantee of a lengthy graceful exit, because browser navigation could terminate the plugin process abruptly at any point.

🏏

Cricket analogy: A match abandoned for bad light gives the umpires only a brief window to record the exact score and overs bowled before players must leave, mirroring Application_Exit's brief, unguaranteed window to persist state before the plugin is gone.

csharp

public partial class App : Application
{
    public App()
    {
        this.Startup += this.Application_Startup;
        this.Exit += this.Application_Exit;
        this.UnhandledException += this.Application_UnhandledException;

        InitializeComponent();
    }

    private void Application_Startup(object sender, StartupEventArgs e)
    {
        this.RootVisual = new MainPage();
    }

    private void Application_Exit(object sender, EventArgs e)
    {
        var settings = IsolatedStorageSettings.ApplicationSettings;
        settings["lastSessionEndedUtc"] = DateTime.UtcNow;
        settings.Save();
    }

    private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
    {
        e.Handled = true;
        LogError(e.ExceptionObject);
    }
}

IsolatedStorageSettings.ApplicationSettings is the most reliable place to persist state during Application_Exit because it is a synchronous, local write. Anything relying on a pending network call inside Exit is best-effort only — the plugin can be torn down before an in-flight request completes.

The plugin loads the .xap, reads AppManifest.xaml, and raises Application.Startup before anything is visible.
Developers set Application.Current.RootVisual, conventionally to a MainPage instance, inside the Startup handler.
Application.UnhandledException lets developers catch and log exceptions before they silently crash the plugin.
The Frame control's Navigated/Navigating events support page-to-page navigation within a single .xap.
SizeChanged combined with the host page's resize behavior lets layouts adapt to browser window changes.
Application.Exit gives only a brief, non-guaranteed window to persist state before the plugin is torn down.
IsolatedStorageSettings.ApplicationSettings is the recommended, synchronous way to persist data during Exit.