Download the tutorial in PDF formatBy Jesse Liberty  Download the code

A Whirlwind Tour

In his wonderful sneak peek blog entry, Scott Guthrie provided a great introduction to Silverlight 2. The tutorials themselves will dive deeply into each topic.

In this short Road Map, my goal is to give you a sense of what the tutorials will be like, without duplicating what is to come. To do so, I’ll collapse and summarize information from the first three tutorials into a blitzkrieg example, with the assurance that all of what you are about to see will be explained in depth in just a few days when the three promised tutorials are made available.

To begin, open Visual Studio (once you have Silverlight 2) and create a new Silverlight Application,

When you do, Visual Studio will offer you three alternatives, A Web solution, with a Web Site, A Web solution with a Web Application or an HTML test Page.

In this case, click on the lower button to choose an HTML Test page; the simplest choice.

Exploring the Visual Studio Solution

Visual studio will set up your solution. The default, at the time of this writing is that six windows will open (your screen may vary based on which release you have and how your copy of Visual Studio is configured).

I’ve numbered 12 areas in the IDE. Though you’ve no doubt been working with Visual Studio 2008 for some time, let’s review them very quickly (moving counter clockwise from the upper left, 

1.        The Silverlight Controls Tab – if you’ve installed tab, your toolbox now has a tab for the Silverlight controls.  We’ll come back to these.

2.       The Design Surface. In Beta 1 the Design Surface is read-only; it will reflect the changes you make in XAML but you can not drag controls onto it.

3.      

The toolbar has not been changed by Silverlight

4.         Tab controls to switch from Design view to XAML view and to swap the position of the two

5.        Controls to split the Design/XAML windows vertically, horizontally or to close whichever is on the bottom

6.        Solution Explorer Buttons

7.        

Solution Explorer

8.        Properties Window

9.         Output Window

10.     Status Bar

11.      Tabs for Tool Window

12.     Controls (I split them in two to fit) 

The Example Program

The full example program (if we were to build it) would provide complete on-line management of all my favorite music and would let me keep an eye on what music I like, and share some or all of it with others. Over time I might modify it to work with any number of commercial music and/or social networks.

For now, what I want to build is a form lets me look at the details about a particular song and to edit some details.

For this application, I’ve chosen to build a simple 3 tier application:

·         The User Interface – in Silverlight

·         The Business layer – in C#

·         The Persistance Layer – In pseudocode and hand-waves

Not A Typical Tutorial

In a typical tutorial the flow would be to introduce a concept, explain it and then illustrate it with a small example. I’d then flesh out the concept, add to the example, and so forth. In this Road Map, however, what I’ll be doing instead is quite different.

Since the plan is that you will have this in your hands before Silverlight is released, and since the purpose of this introduction is not to be a tutorial but more to show you a bit of what the first few tutorials will cover, what I’m going to do is build a piece of an application and point out the concepts and issues that we run into, as we run into them; explain just enough for a programmer to grok what they are about and then tell you which tutorial will explain them in detail.

My hope is that rather than this being frustrating, it will give you a good sense of what it will be like to program in Silverlight and what is coming in the initial tutorials.

Goldilocks Examples

I’ve written a couple dozen programming books and the one thing I’ve learned is that you can never get the complexity of the examples right to please everyone. Some folks (like me) like dead simple examples that illustrate one concept and nothing more. If you are teaching me polymorphism then your example should be:

 

For me, as a learner, this is perfect. I know what a mammal is, I know what a Dog and a Cat are, and I immediately get the idea that Dogs and Cats are specific kinds of Mammals,  that Dogs specialize the concept of making noise in a different way than Cats do, and that there is no such thing as a Mammal instance. From ehere it is easy to teach me about abstract types, and all the other complexities. 

For others, this is a terrible exercise. It has nothing to do with what they do for a living. They don’t write applications with Dogs and Cats and they perfectly legitimately hate examples like this. They want to see

Ah, much better, real life.  (Pretty funny that we think of CheckBoxes as real life and cows as not, but that is for another day).

Then, of course, there are the developers who reject both examples as simplistic drivel, and want to see the complexity of real programs; gladly wading through hundreds of lines of code (complete with bullet proofing, exception handling, etc.) because otherwise it is just a toy, and modeling bad programming to boot. 

The problem of course, is that the thing you are trying to exemplify gets lost in all that code.

Liberty’s rules for examples…

After years of thought, working with developers and trying different approaches, I’ve come to the following conclusions

1.       Keep it simple enough that the example totally focuses on what you are trying to illustrate (but no simpler)

2.       Try to use something like business objects rather than cute animals or game objects

3.       Don’t show off how clever you are, break the code down into small digestible parts.

4.       Use interim variables; they’re easier to catch in a debugger

5.       Strip away all exception and error handling and bullet proofing unless you are teaching exception handling, error handling or bullet proofing.

6.       Use great variable names so you need fewer comments, but don’t convince yourself that means you don’t need any.

7.       Show the output

8.       Make no apologies (except when you’re wrong) 

The Example Program

The program we’re going to write (fasten your seatbelts) will manage my growing music collection. As those of you who read my personal blogs may know, I go through music fads (in the 90s it was Jazz and Opera, lately it has been grunge and heavy metal to the chagrin of my entire family, including the dog).

The program will do it all, but the tiny piece we’ll work through together will be a single Silverlight page that lets me examine the details about any song.

The Finished Application

Given the speed with which we’re going to run through this, you really need a specification, so you know where you are going. The best specification I can imagine is to see the finished product:

As you can see, this application displays vital information about the greatest music ever written.  

Note: There is a spelling error (Zune was misspelled) We’ll  fix that  in the next release of the Road Map.  

The Change Song button stands in for the idea of picking a song from a vast collection; it is a hack. When you click Change Song I create a second song and populate the interface.

Clearly much more could be done, and the hacker in me wants to go off and fix and fuss, but there is plenty here to explain; in fact we’ll touch on all the issues that are covered in depth in the first three or four tutorials.

The Business Object

We begin by examining the interface to the Song Class that will act as the business class for our application. It will have six public properties, as shown here. I’ve left the line numbers in to indicate clearly that I’m showing only the names of the properties, and not their implementation (yet).  

Designing the controls based on the properties.

The properties dictate (to some degree) the controls that we’ll use to create the interface, 

Property	Read-Only?	Control Type
SongName	Yes	TextBlock
SongAlbum	Yes	TextBlock
SongBitRate	No	TextBox
IsOniPod	No	CheckBox
SongArtists	Yes	ListBox
SongRating	No	Slider

 

Each control will be paired with a TextBlock that will act as its label and that TextBlock’s name will be the name of the control appended with prompt. Thus, the SongName control will have a matching SongNamePrompt control of type TextBlock.

All prompts will be in “normal” weight text Comic Sans Ms Font, 14; all values will be in bold, Verdana, 16, and Blue. 

The Grid Layout Control

Let’s start by creating the grid into which we’ll place the controls. We do this in Page.xaml with Grid RowDefinitions and ColumnDefinitions. You’ll note that I’ll add a first, small row to create a little head-room for the application,

 I’ve chosen to vary the MaxHeigth of the rows to assist in the spacing of the controls. There are many other ways to do this as well. I’ve also created three columns; the middle acting as a spacer, as the prompts will be flush right and the values will be flush left.

Data Binding

The second tutorial explains Data Binding in great detail. Here I will simply say that the controls can act as the target of the binding and an instance of our Song class can act as the Source (as can any CLR object).

The Song, acting as a data source for the UI will implement INotifyPropertyChanged which requires the PropertyChangedEventHandler event, an instance of which is named PropertyChanged by convention,

Each property will invoke the event when its value is set. To simplify this, I’ll factor out the testing of the event and the calling of the delegated function into a member method called NotifyPropertyChanged, as suggested in the Silverlight Documentation. 

 

Creating Style Objects 

Each control will replace all its attributes with a Style, which will be defined at the top of the XAML page, and will replace its value with a Binding object and the name of the Property to which it is Binding,

Here we see two controls, both of type TextBlock. The first acts as the prompt. Its attributes (other than its position in the grid) are replaced by the Style, which it retrieves from the StaticResource named TextBlockPrompt. That is found at the top of the file,

The Grid.Resources section holds all the Style definitions. A Style is defined with the keyword Style. The TargetType indicates that this style can be applied to TextBlock objects (as we have done). The key identifies this style (so that we can have more than one style which we can apply to the same type of control).

Within the Style are Setter elements, each consisting of Property/Value pairs. Here we see six Property/value pairs, setting the Vertical and Horizontal Alignments, and the Font family, size, and weight as well as the foreground color. By applying this one style, the control is set with all these attributes.

Why Styles?

This has many advantages over setting the styles in the control itself, the two most important of which are

1.       A much greater likelihood of a uniform look and feel

2.       A greatly reduced risk of errors when changing the style of a control and thus a much greater ability to handle larger applications.

In the code shown above, we created two TextBlocks, one was the prompt and the other had the name of the Song. Here is the code again,

Notice that the second TextBlock also has a style, but this time the style is not TextBlockPrompt, but rather, TextBlockValue. As you may guess, there is a definition for that above which sets the target as TextBlock, but the key as TextBlockValue, and changes the Font style.

The second line of this TextBlock sets the Text property to be a Binding object. That Binding object is bound to the SongName property of some data source, but we don’t yet know what the data source is. That’s good, because this is created at design time, and we don’t want to set the data source until run time. We also indicate here that we are creating a OneWay binding – that is, we’ll display the song name but the user will not be able to write changes back to the source. 

Implementing Other Styles

The Artist and Album are nearly identical in form to the song name,

Two Way Binding

Things get a bit more interesting (you should pardon the pun) when we get to the SongBitRate. Here, instead of the value residing in a TextBlock, we place it in a TextBox, and we set the binding to TwoWay. This allows the user to modify the bit rate if, for example, a better bit rate is obtained,

In Silverlight the only change you have to make to implement two way binding is to change the mode!

Binding to a List

The SongArtists property of the Song is a list of the singers. In the case of Whole Lotta’ Love by Led Zeppelin, that is "John Bonham", "Robert Plant", "Jimmy Page", "John Paul Jones". We’ve chosen to display these names in a list box, yet to bind to the Song object.

We populate the list box by Binding the ItemSource property of the Listbox to the SongArtists property in the Song class.

There is Much More Detail

Yes, that was too fast, and too much was left out. So why did I run through all this here? Because this is exciting stuff, and getting a sense of how it might all fit together is just too great not to take the opportunity to put it in front of you and whet your appetite. Check back often as we add more tutorials, videos and other great content to www.silverlight.net.