Application Extension Services
Microsoft Silverlight will reach end of support after October 2021. Learn more.
Application extension services enable you to extend the Silverlight application model. You will typically use extension services to encapsulate functionality used by multiple applications in a particular feature domain. For example, you can use extension services to implement specialized media handling or a custom data access layer.
The Application class provides services common to most applications. For more information, see Application Services. You can provide additional services by creating a custom Application subclass, but this could lead to unnecessary complexity. For example, creating a subclass would require that applications derive from your subclass, which prevents the use of multiple extension frameworks at the same time.
Instead of creating a custom Application subclass, you can add application extension services through the Application.ApplicationLifetimeObjects property. This enables you to combine multiple services and implement complex service dependencies.
Application extension services must implement the IApplicationService interface. This interface provides support for service initialization and cleanup. Services can also implement the IApplicationLifetimeAware interface if they require deeper integration with application lifetime events.
This topic contains the following sections:
Registering Extension Services
Accessing Extension Services from Application Code
Implementing the IApplicationService Interface
Implementing the IApplicationLifetimeAware Interface
Registering Extension Services
You register application extension services by adding them to the Application.ApplicationLifetimeObjects list. You can do this in the application XAML, in procedural code, or both.
Services are registered in the order that you specify. This enables you to create services with dependencies on previously-registered services.
Service registration must occur in the application constructor. If you specify the services in the application XAML, they are registered when the constructor loads the XAML by calling the generated InitializeComponent method.
The following code example demonstrates how to register two services in the App.xaml file. This code assumes that you have defined an XML namespace named svc that refers to the namespace and assembly that contains the service classes.
<Application.ApplicationLifetimeObjects>
<svc:ApplicationService1/>
<svc:ApplicationService2/>
</Application.ApplicationLifetimeObjects>
The following code example demonstrates how to register the same services by using procedural code in the application constructor.
this.ApplicationLifetimeObjects.Add(
new SilverlightApplicationService.ApplicationService1());
this.ApplicationLifetimeObjects.Add(
new SilverlightApplicationService.ApplicationService2());
Your service classes can implement properties that you can set in XAML or initialize in the service constructor. A default constructor is required to register a service by using XAML. Therefore, if you implement a constructor that takes parameters, you should also explicitly implement a parameterless constructor.
Accessing Extension Services from Application Code
You can retrieve the registered service objects from the ApplicationLifetimeObjects list. However, this list requires an integer index, and the index for a particular service will change if you add, remove, or reorder services. Therefore, you should provide some other form of access in your service implementations.
One convenient pattern is to implement a static Current property on your service classes. You can set this property in your service initialization code. This makes the instance easier to access in the application code and in the initialization code of any additional services to be registered.
The following code example demonstrates how to access a service instance through a Current property, and then access an instance property of the service.
ApplicationService1 service1 = ApplicationService1.Current;
String param1 = service1.InitParams["param1"];
The following section includes example code that implements and initializes these properties.
Implementing the IApplicationService Interface
Silverlight application extension services must implement the IApplicationService interface. This interface defines two methods: StartService and StopService.
You will typically implement the StartService method to initialize your service and acquire any necessary unmanaged resources.
Before the Application.Startup event, the application calls the StartService method for each service in the order in which they were registered. This makes each service available to the StartService method of later services in the registration order. Additionally, all services are available for use by the Startup event handler.
The StartService method has a single argument of type ApplicationServiceContext. This type exposes an ApplicationInitParams property, providing access to the InitParams values specified in the host HTML.
The following code example shows a StartService method implementation that initializes a static Current property and stores the initialization parameters in an instance property.
public static ApplicationService1 Current { get; set; }
private Dictionary<String, String> InitParams { get; set; }
public void StartService(ApplicationServiceContext context)
{
Current = this;
InitParams = context.ApplicationInitParams;
}
You will typically implement the StopService method to shut down your application and dispose of any unmanaged resources.
After the Application.Exit event, the application calls the StopService method for each service in the opposite of the order in which they were registered. All services are still available for use by the application Exit event handler. Additionally, each StopService method still has access to any services that have earlier positions in the registration order.
Implementing the IApplicationLifetimeAware Interface
The IApplicationLifetimeAware interface inherits the IApplicationService interface, and defines methods to handle the following four additional application lifetime events:
As the names imply, these methods are called immediately before and after the application Startup and Exit events.
You will typically implement the IApplicationLifetimeAware interface for services that have complex dependencies on other services and on application code. For example, the Starting method of a service can access any other registered services, regardless of the registration order. Additionally, the Started method can access anything initialized in the application Startup event, such as the RootVisual property value.
The following list indicates the order in which application lifetime events occur and the IApplicationService and IApplicationLifetimeAware methods are called:
The application calls the IApplicationService.StartService method for each application service.
The application calls the Starting method for each IApplicationLifetimeAware service.
The Application.Startup event occurs.
The application calls the Started method for each IApplicationLifetimeAware service.
The application runs until the stop sequence is initiated by user action. This typically occurs when the user closes the application or browser window, or navigates the browser to a new Web page.
The application calls the Exiting method for each IApplicationLifetimeAware service.
The Application.Exit event occurs.
The application calls the Exited method for each IApplicationLifetimeAware service.
The application calls the IApplicationService.StopService method for each application service.
The application calls each service method one time per service. These methods are called in the order that the services were registered, except that the StopService methods are called in the opposite order. This enables orderly cleanup as described in the previous section.
See Also