Application is a class that encapsulates a Silverlight application and provides the following services:
The entry point in a Silverlight application is the class in your application assembly that derives from Application. This class is known as the application class. When the Silverlight plug-in starts, Silverlight uses metadata in the application package to instantiate the application class. At this point, the application's lifetime starts. The lifetime of an application occurs in the following order:
By handling the Startup event, you can retrieve and process initialization parameters from the InitParams property of the StartupEventArgs object that is passed to the Startup event handler. Initialization parameters are configured by using the initParams property of the HTML object element that is used to configure and instantiate the Silverlight plug-in.
During startup, you can also specify the main application UI to show by setting the RootVisual property.
Once an application is running, the Application object and its state can be accessed from the static Current property. The singleton pattern ensures that state managed by Application, including shared resources (Resources) and custom properties, is available from a single, application-scoped location.
XAML Usage Notes for the Application class
In practical XAML usage, Application is almost always the root element of the App.xaml file and therefore a practical usage would include the client and XAML xmlns values, as well as an x:Class value for the code-behind that initiates the root visual, as shown in the following XAML fragment.
<Application
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="namespace.class"... >
...
</Application>
Technically the XAML usage for any member of the Application class that supports XAML applies both to the Application class and also to any Application subclass that does not specifically disable XAML usage by shadowing members or changing the access level of its constructors. However, the XAML usage for Application members shows the literal Application rather than the placeholder application because subclassing Application is not necessary for most Silverlight application model scenarios, and the XAML usage shows the most common usage patterns whenever possible.