Monday 5 September 2011

Silverlight Application Life Cycle

In the previous article I attempted to explain What Silverlight is and how it is being used more and more to develop business applications. In this article I will try to explain Silverlight Application Life Cycle. Building apps with Silverlight is more or less similar way of building Desktop apps, for example WinForms or WPF apps.
When you embed the Silverlight plug-in in a Web page, you specify the location of the application package that the plug-in should download. The whole process is as follows:
  1. A User requests a Web page that hosts the Silverlight plug-in.
  2. If the correct version of Silverlight has been installed, the Web browser loads the Silverlight plug-in and creates the Silverlight content region. The plug-in then begins downloading your .xap file.
  3. The plug-in extract the contents of the .xap file and read the AppManifest.xaml file from the XAP to determine the assemblies your application uses.
  4. The plug-in loads the Silverlight core services and the Silverlight runtime environment (CLR) which then creates an Application Domain for your application.
  5. When the package is downloaded, the plug-in then loads your application assemblies and dependencies (if any) into the AppDomain. The CLR uses the metadata in .xap to instantiate your Application class and the default constructor of the Application class raises its Startup event.
  6. The Startup event handler is handled to display a user interface page and that is how you view your UI. This event occurs once the Silverlight plug-in has finished loading the .xap file. Once the UI is loaded, other events occur in response to user actions.

ASP.NET and Silverlight

There are many differences between ASP.net and Silverlight.
ASP.net generates the control (client side scripts to build UI) and send to client for rendering. It requires two processes, dynamic generation of code at server, rendering of server generated code at client inside the browser. Even the code is generated at server by ASP.net worker process, it gets executed as script on the client as it gets downloaded in form of script (html, CSS, js etc).
On other hand, Silverlight contains pre-compiled intermediate language code (MSIL) for controls and only create instance to display that. A single process of instantiation of control is sufficient to render the information in browser. All Silverlight codes are pre-compiled so loading is faster than ASP.net. It requires less data transfer between server and client. There are no "server round trip", no javascript, no Ajax.
Silverlight is just like a Flash app... A server file is request by the plug-in on client computer, your server sends this file (.xap for Silverlight) and the plug-in runs it locally.
ASP.NET is stateless and everything is executed and handled on the server-side, Silverlight is not stateless and everything that is executed is executed by default on the client-side, only when you make call to the server, code on the server-side will be executed. So no refresh, no reloading of pages, no page life cycle, ViewState, just a beautiful rich client that holds state;

Page Life Cycle

Remember that Silverlight is running on the client, not on the server as normal ASP.NET pages... there is no such as Page Life Cycle in Silverlight. But there are some events that will be executed on the client side in a specific order.
  1. First the App constructor in the App.xaml file.
  2. The App's Applicaiton_Startup event which will be executed every time you open your Silverlight app.
  3. The Main page's Constructor..  It will be the constructor of the page assigned to the RootVisual properly within the App's Application_Startup event.
  4. InitializeCompnent, only to make sure the components are singed to variables so you can use them. I hope this one will be removed in the future and be handled elsewhere.
  5. If you have hooked up to the Loaded event within the Main Page Constructor, that event will then be executed, same with the rest event listen in the order they will be executed if you have hooked up to them.
  6. Then the SizeChanged event.
  7. Then the LayoutUpdated event.
  8. Then GotFocus if you mark the Silverlight app.
  9. If you navigate from your Silverlight app or close the Browser the App's Application_Exit event will be executed.
As you may figure out, There is No Life Cycle. If you have a button control on the Silverlight app and press it, there will never we a post back, back to the server. The click event will just simply be fired of on the client-side; it's where the code is executed. To get data from a server, you can for use a WCF service, Web Service, Web Client, .NET RIA Services etc... They will make the call to the server from the client side for you.

Control Initialization Order

There are some subtle differences between instantiating a control in XAML, and instantiating it via code that I've called out, but most of the lifecycle is the same.