Vous êtes sur la page 1sur 18

Silverlight Tutorials

The Silverlight 2 Tutorials


Tutorial 0: Road Map
By Jesse Liberty

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, Ill 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,

3/5/2008
Page | 1

Silverlight Tutorials

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 Ttest Page.

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

3/5/2008
Page | 2

Silverlight Tutorials

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).

Ive numbered 12 areas in the IDE. Though youve no doubt been working with Visual
Studio 2008 for some time, lets review them very quickly (moving counter clockwise
from the upper left,

1.

The Silverlight Controls Tab if youve installed


tab, your toolbox now has a tab for the Silverlight controls. Well come back to
these.

3/5/2008
Page | 3

Silverlight Tutorials

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.

7.

Solution Explorer Buttons

Solution Explorer

3/5/2008
Page | 4

Silverlight Tutorials

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,

3/5/2008
Page | 5

Silverlight Tutorials

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, Ive 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. Id then flesh out the concept, add to the example, and so forth.
In this Road Map, however, what Ill 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 Im 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
Ive written a couple dozen programming books and the one thing Ive 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:

3/5/2008
Page | 6

Silverlight Tutorials

3/5/2008
Page | 7

Silverlight Tutorials

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 dont write applications with Dogs and Cats and they perfectly legitimately hate
examples like this. They want to see

3/5/2008
Page | 8

Silverlight Tutorials

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

3/5/2008
Page | 9

Silverlight Tutorials

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.

Libertys rules for examples


After years of thought, working with developers and trying different approaches, Ive
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.

Dont show off how clever you are, break the code down into small digestible
parts.

4.

Use interim variables; theyre 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 dont convince
yourself that means you dont need any.

7.

Show the output

8.

Make no apologies (except when youre wrong)

The Example Program


The program were 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 well 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 were 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:

3/5/2008
Page | 10

Silverlight Tutorials

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

Note: There is a spelling error (Zune was misspelled) Well 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.

3/5/2008
Page | 11

Silverlight Tutorials

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 well 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. Ive left the line
numbers in to indicate clearly that Im showing only the names of the properties, and not
their implementation (yet).

3/5/2008
Page | 12

Silverlight Tutorials

Designing the controls based on the properties.


The properties dictate (to some degree) the controls that well 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
TextBlocks 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.

3/5/2008
Page | 13

Silverlight Tutorials

The Grid Layout Control


Lets start by creating the grid into which well place the controls. We do this in
Page.xaml with Grid RowDefinitions and ColumnDefinitions. Youll note that Ill add a
first, small row to create a little head-room for the application,

Ive 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. Ive 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, Ill 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.

3/5/2008
Page | 14

Silverlight Tutorials

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,

3/5/2008
Page | 15

Silverlight Tutorials

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 dont yet

3/5/2008
Page | 16

Silverlight Tutorials

know what the data source is. Thats good, because this is created at design time, and we
dont want to set the data source until run time. We also indicate here that we are creating
a OneWay binding that is, well 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,

3/5/2008
Page | 17

Silverlight Tutorials

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". Weve 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.

3/5/2008
Page | 18

Vous aimerez peut-être aussi