Life Cycle Silverlight Application 4.0

The page life cycle of Silver light Application . The whole process is bellow.

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. Read more about Event Handling in Silverlight here. 

Action	Control instantiated in XAML	Control instantiated in code
Control ctor	As soon as begin tag is parsed.	When you call it.
Explicit Style applied	If the Style property is set in XAML, it will be applied as soon as the end tag is parsed.	As soon as Style property is set.
Built-in Style (from generic.xaml) applied	As soon as the end tag is parsed, after the explicit Style (if any) has been applied. Will not override explicit Style.	When the control enters the tree. Will not override explicit Style.
Properties set	When the attributes are parsed.	When you set them.
Loaded event	Posted when the element is been added to the tree. Fired before the next frame. Happens before layout.	Same.
Template applied (i.e. control's visual are created from the Template)	In the Measure pass of layout. The Template property will be applied if the control has no visual tree. The control starts life with no visual tree, and the visual tree will be cleared when the Template property is set. You can also call ApplyTemplate yourself.	Same.
OnApplyTemplate called	Whenever the Template is applied. It is not necessary to call the base OnApplyTemplate for the Template to be applied, but inherited types might be relying on it for their implementations.	Same.
Visuals first available	In OnApplyTemplate. Use GetTemplateChild.	Same.
MeasureOverride called	In the Measure pass of layout. If the Template was expanded during this Measure pass, MeasureOverride will be called after the Template has been expanded.	Same.
ArrangeOverride called	In the Arrange pass of layout, which occurs after the Measure pass.	Same.
SizeChanged event	After the Measure and Arrange passes have completed.	Same.
LayoutUpdated event	After SizeChanged events have fired.	Same.

---