SilverlightShow and Gill Cleeren start a series of materials aimed at helping you get prepared for taking Microsoft Silverlight Exam 70-506. Through this series we will try to structure the resources available on the internet, grouping them by topic covered in the exam. Any feedback would be much appreciated! Thanks!
This article is Part 6 of the series on Microsoft Silverlight Exam.
This 6th part is the before last part in this article series on getting ready for the Silverlight exam. I hope you kept up with all the material we have covered so far. If you’re feeling confident, why not take a look at this part and get a bit more ready to successfully complete the exam!
In this part, Structuring applications, we’ll look a few topics that relate to application-level tasks, such as handling how an application starts up or responds to an error happening, translating Silverlight applications to make it appear in more than just one language and using resource dictionaries.
For your convenience, the following list contains links to the other parts of the article series which have been finished already:
Part 6: Structuring applications
We have extensively covered how we can build Silverlight applications in the previous parts. Writing code is one thing though, doing it right is another one. It’s often important to take a step back before starting the coding and take a look where things should go.
Styles are a great example of this. If we place all our style information for an entire application in the App.xaml, we’ll end up with a XAML file of several thousands of lines of code. This is all but a fun thing to start searching through, not to mention the fact that it costs a lot of memory of your machine to edit such a file. Merged Resource dictionaries are exactly what we need in this case. They allow us to split up the code in more than one Resource Dictionaries and allow them to be merged, making it a lot easier to manage these files.
I live in Belgium, a small country. Why is this relevant you may be thinking? Let me explain. Although we are a small country, people in the northern part of the country speak Dutch while in the southern part, they speak French. In Brussels, our capital, both languages are mixed. Finally, there’s also a small part that speaks German. In a country like mine, most applications need to be localized. Since most Silverlight applications are web-facing, chances are that you will get other than native-English visitors. If you want to welcome them in their own language (or give the option to switch languages), your application needs to be structured in a way that it easily allows for localizing (read: being translated in more than one language). Next to translations, applications may also need to be adapted, so that things like thousands and decimal separators are like the user expects them. We’ll look at how we can localize and globalize Silverlight applications further.
The last thing we’ll look at in this part are application events. Via the App.xaml.cs file, we have access to several application events. If we want to perform tasks in the startup of the application, we can do so through the Application_Startup method. We can write code that executes when the application is shutting down as well. This can prove valuable to save state of the application to isolated storage so that when the user visits our Silverlight application again, he will get the application in the same state as he left it.
Let’s take a look at these topics in some more detail.
Create and consume resource dictionaries
We already looked at styles and we saw that they are a great solution to make sure that your application’s markup remains clean and doesn’t contain UI-related properties. Secondly, they promote re-use: when defining a style instead of inline markup XAML, we can make use of the style in several places throughout an application. Styles are placed in resource dictionaries.
A resource dictionary is a dictionary where we can place objects in. These objects can be styles as mentioned, but other objects can be place in there as well, including Brushes, Transforms and even instances of our own created classes. Since they are dictionaries, we can access the elements using a key.
Resource dictionaries are available on several levels. They exist on controls (such as a Grid), on the Page/UserControl and on the application level. They can also be defined in a separate file. When a control has a specific styles attached to it, XAML tree walking will happen, searching up the XAML tree for the first instance of the style within a resource dictionary. This means that first the resource dictionary (if any) of the parent is observed, then its parent and so on. At some point, we’ll arrive at the Page/UserControl level where the resource dictionary is searched as well. If nothing is found, the application-level resource dictionary is searched.
As mentioned, in many cases, we’ll place most resources (such as styles) at the application level, resulting in a fairly large App.xaml file. This can be solved by using the concept of merged resource dictionaries. This allows us to split the resource information in several files and merge them into one large dictionary at run-time. This makes things a lot more manageable!
One final other thing that resource dictionaries can be used for is the use of sample data at design-time. While creating applications inside Visual Studio or Blend’s designer, the lack of test data inside the designer can make things harder to visualize. For example, it’s hard to create a custom item template for a ListBox if you can visualize the template (unless you run the app of course). We can however define a resource dictionary that contains sample data for use at design-time, making this task a whole lot easier!
Take a look at the following links to learn more about resource dictionaries:
- Utilizing sample data
Sample data can be defined inside a resource dictionary. This data can be used inside the designer.
- Creating sample data: http://msdn.microsoft.com/en-us/library/ff602279(v=vs.95).aspx
- http://blogs.msdn.com/b/wpfsldesigner/archive/2010/06/30/sample-data-in-the-wpf-and-silverlight-designer.aspx#consuming
- Selecting resources
- ResourceDictionary class on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.resourcedictionary(v=vs.95).aspx
- http://www.silverlightshow.net/items/Application-Events-in-Silverlight.aspx
- http://msdn.microsoft.com/en-us/library/cc903952(v=VS.95).aspx
- http://www.c-sharpcorner.com/UploadFile/dpatra/ResourceDictionaryInSilverlight3UsingBlend307262009124855PM/ResourceDictionaryInSilverlight3UsingBlend3.aspx
- http://forums.silverlight.net/forums/p/204265/478131.aspx
- Merging resource dictionaries
Implement localization and globalization
When we want to reach a global audience with our application, we can do 2 things: create the application with an English interface or localize the application. This localization can be done in any number of languages you want. As with other types of applications in .NET, localization is most often done through the use of resource files. For each language we need to support, we can create a resource file. Some cultures even read and write from right-to-left. This ability is natively built into Silverlight. This feature was added with the release of Silverlight 4 and is also supported on controls such as the RichTextBox.
To learn more about localization, take a look at the following links:
- Translating strings
- Configuring right-to-left language support and FlowDirection
The FlowDirection property, defined on FrameworkElement, allows us to specify the direction of text and other interface elements.
Handle application-level events
Do you know how the Silverlight runtime figures out how to start your application? The following steps describe what happens:
- The Silverlight plug-in downloads the XAP file, opens it (remember, it’s nothing more than a ZIP file) and reads the AppManifest.xaml.
- Inside that file, it searches for the EntryPointAssembly and EntryPointType. The EntryPointAssembly refers to the assembly (a DLL part of the XAP file) that Silverlight should take to search for the core of the application. EntryPointType refers to the type within that assembly that contains code to initialize the application. The latter by default will refer to the App type inside your application.
- Inside the App class, most often via the constructor but sometimes via XAML, 3 events are being registered:
- Startup
- Exit
- UnhandledException
These events known as application-level event are used as hooks in the lifecycle of the application.
The Startup event is fired when the application starts. The accompanying event handler (Application_Startup) runs and by default sets a control as the RootVisual of the application. If we want however, we can write code that does other initialization work, such as setting up an IOC container, downloading additional XAPs or capturing parameters sent via HTML (through the object tag).
The Exit event fires when Silverlight is shutting down, no matter what the cause of this shutdown was. It could have been caused by the user closing the browser, navigating to another page or an unhandled exception that took place. This event is however really important, as we can use it to capture state data. Assume for example that the user has to fill in a form with lots of data. All of a sudden, something goes wrong and the application is shut down. We can write code in this exit that saves the data, for example to isolated storage. Upon next run of the app, we can the restore that state.
The UnhandledException event is triggered when an error wasn’t caught by our code. We have the ability to mark the error as handled, allowing Silverlight to continue running the application. However, this should not be abused for this: we should still write code that handles exceptions gracefully.
To learn more about these events, take a look at the following links:
- Startup event
- Application.Startup on MSDN: http://msdn.microsoft.com/en-us/library/system.windows.application.startup(v=vs.95).aspx
- http://www.silverlightshow.net/items/Application-Events-in-Silverlight.aspx
- Capturing parameters via InitParams: http://www.silverlight.net/learn/videos/all/using-startup-parameters-with-silverlight/
- http://www.willasrari.com/blog/set-silverlight-startup-page/000343.aspx
- Exit event
- UnhandledException event
Summary
In this part, we looked at working with resource dictionaries and merged dictionaries. We also looked at how we can localize our application and finished off by looking at the different application events. Stay tuned for part 7, the last part of this article series!
About Gill
Gill Cleeren is Microsoft Regional Director (www.theregion.com), Silverlight MVP (former ASP.NET MVP), INETA speaker bureau member and Silverlight Insider. He lives in Belgium where he works as .NET architect at Ordina. Passionate about .NET, he’s always playing with the newest bits. In his role as Regional Director, Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd Berlin 2010, TechDays Belgium, DevDays NL, NDC Oslo Norway, SQL Server Saturday Switserland, Spring Conference UK, Silverlight Roadshow in Sweden… He’s also the author of many articles in various developer magazines and for SilverlightShow.net. He organizes the yearly Community Day event in Belgium.
He also leads Visug (www.visug.be), the largest .NET user group in Belgium. Gill recently published his first book: “Silverlight 4 Data and Services Cookbook” (Packt Publishing). You can find his blog at www.snowball.be.
Twitter: @gillcleeren