Jesse Liberty - Silverlight Geek

Re-organizing This Site

Taken from a comment on a previous blog entry: "Please see to it that, these [materials on Silverlight] become an organized set of materials in one location, rather each person does it on their own blog without any sequence. Right now, I had to hunt so many web sites to get materials on Linq, and if I wasn't serious about Linq, I'd have given up by now. And that goes for new users of SL."

 We are working hard to reorganize Silverlight.net so that the learning material is highly organized. Our goal is that we meet the needs of two specific audiences: those who want a systematic sequence for learning, and those who wish to find out about a specific topic. For either of these, we hope to offer (at a minimum) a set of videos, tutorials, possibly white papers, samples, and forum discussions.

I think you will see dramatic organizational improvement in coming months, and in the meantime I will be blogging about all the videos I create, providing a road map not only to their content but to how the various videos all fit together. My request to you is to combine patience with high standards: give us time, but let us know if you don't think we're getting it right.

Thanks!

One, Two, Many

I'm told that some primitive counting systems count as follows: one... two... many.

This actually makes a great deal of sense.  There are numerous things in life of which there is only one. One planet. One self. One sun. One now.

Then there are numerous occasions where the number two is uniquely useful. It takes two to tango, to mix DNA, to use a see-saw....

After two, however, there is a sense that if you can do something three times you can do it twenty times. (Yes, I simplify). 

In our videos on  Silverlight 1.0 I think we've covered a good bit of "1" -- that is, your first program, your first animation, your first, transformation, etc. There are some lacunae, but we're closing in on covering 1 pretty well.

We've covered "many" pretty well, but there is much more to do. These are the videos in which we show you how to string together these building blocks to do something useful; something that isn't just a toy. I'd point to our videos on creating a video player and on data analysis with animation as a start in this direction. 

But today I realized that we've neglected "two."  A user wrote with serious confusion about how to add a second object to a canvas. Where does the second story-board go? Where does the event handler go? These are perfectly reasonable questions, and, of course, once you get 2, it is much easier to move on to "many"

So, dear reader, here is my question: should we have some videos on 2? Would that intervening step be helpful?  That is, rather than jumping from "here is how you add an object and animate it" to "and now here is how you do something useful with animation" would it be useful to add an in-between video on "here is how you add a second object, and animate two objects and then more" to focus on the issue of 2 (and then 3, 4, and more)?

I understand that 2 is implicit in many; but sometimes stripping things down to their most simple form makes it easier to understand them; and the simplest form of many is not 1; it is 2.

Your reactions are eagerly awaited.

Creating XAML Objects in Code

One of the advantages that Silverlight 1.1 does bring to the party is the the isomorphism between XAML and CLR object that is found in Windows Presentation Framework (WPF). Thus, you can create a rectangle declaratively,

<Rectangle x:Name="myRect" Width="120" Height="50" Canvas.Left="10"
              Canvas.Top="10" StrokeThickness="2" Stroke="Black"  >
    <Rectangle.Fill>
      <LinearGradientBrush>
        <GradientStop Color="Red" Offset="0.0"/>
        <GradientStop Color="Orange" Offset="0.2"/>
        <GradientStop Color="Yellow" Offset="0.4"/>
        <GradientStop Color="Green" Offset="0.6"/>
        <GradientStop Color="Blue" Offset="0.8"/>
        <GradientStop Color="Purple" Offset="1.0"/>
      </LinearGradientBrush>
    </Rectangle.Fill>
  </Rectangle>

or you can create the same object programatically,

// declare the rectangle
Rectangle myRectangle = new Rectangle();

 // add it to the canvas  
parentCanvas.Children.Add(myRectangle); 

// set properties
myRectangle.Width = 120;  
myRectangle.Height = 50;
//... 

// set dependency properties
myRectangle.SetValue(LeftProperty, 150);  
myRectangle.SetValue(TopProperty, 10);

// create a Linear Gradient Brush
LinearGradientBrush lgb = new LinearGradientBrush();

// Create a series of GraidentStop objects
GradientStop gs1 = new GradientStop();  
GradientStop gs2 = new GradientStop();
// ...

// Set the color for each stop object
gs1.Color = Colors.Red;
gs2.Color = Colors.Orange;
//...

// Set the offset for each stop object
gs1.Offset = 0.0;
gs2.Offset = 0.2;
// ....

// Add the Gradient stops to the Linear Gradient Brush
lgb.GradientStops.Add(gs1);
lgb.GradientStops.Add(gs2);
//...

// Set the Fill property of MyRectangle to the LinearGradientBrush object
myRectangle.Fill = lgb;

The advantage of being able to create the object programmatically of course is that it makes it much easier to create objects dynamically, in response to events that arise while your program is running.  In  my latest video I explore this aspect of the relationship between XAML and managed code and more.

Reach Out And Touch HTML

I've posted a new video that shows how Silverlight 1.1 lets you create custom controls that can reach out to the HTML host page. In the example, we not only touch HTML controls, but we also respond to events (a button press) on an HTML control. The enabling technology is in the name space System.Windows.Browser.

The work turns on creating HtmlElement objects as member variables of your class.  These objects have an AttachEvent method that takes the name of the event and an event handler as arguments, as shown in this snippet:

private HtmlElement newMessageTextBox;
private HtmlElement updateButton;
private HtmlElement fontSizeTextBox;

public void Page_Loaded(object o, EventArgs e)
{
    InitializeComponent();

    HtmlDocument document = HtmlPage.Document;
    newMessageTextBox = document.GetElementByID("messageInput");
    updateButton = document.GetElementByID("update");
    updateButton.AttachEvent(
        "onclick", 
        new EventHandler(this.updateButton_Click)
    );
}

The HtmlPage is able to get the current (HTML) Document and from that we can get the (HTML) TextBox that was placed on the Document. With the document in hand, we can get the button, declared in TestPage.html as

Hypervideo 2

We recently posted a video I'm very proud of: the second part of the series on HyperVideo. However, even though the landing page says "Presented by Jesse Liberty and Tim Heuer" you will note that in the video itself I say "I did this" and "I did that" and Tim disappears!  This is particularly outrageous because nearly all the innovation was his!. He is the person who created the spiffy control, he is the person who showed me that you can use encoder to create the running start of the application code. Tim! Tim! Tim I tell you. <slap!>  

This video is actually a very cool video because what we did was to create an application that consists of numerous interacting parts (some implied, some implemented):

1.  A video with embedded markers
2. A Silverlight control to play the movie and offer a control for more information when a marker is hit
3. A database that ties URLs to markers
4. A web service that the Silverlight control can contact to find out which URLs go with which markers for the current movie

Thus, neither the movie nor the Silverlight control knows what URL will be linked to a given marker; that is entirely data driven, and the data is delivered (as JSON) through a web service using AJAX to facilitate the data transfer.  This brings us a giant step closer to a reusable Silverlight Hypervideo control. We will continue to refine this idea as Silverlight 1.1 matures; I'm convinced that there are numerous applications for Hypervideo and that there is much more this control can do.

Sincerely, 

Rodion Romanovich Raskolnikov.
Silverlight Geek

Better sound for better videos

I've been getting a lot of good feedback about our "How Do I" videos and I've decided (with the blessings of my boss) to invest in improving the sound quality. I can't stand listening to the "pops" I get on percussive p's and other consonants. So, starting with my next video I'll be using new equipment (described below) but the interesting question is whether you'll be able to tell. Since I have a few videos already recorded I'm not going to say which video marks the transition; but feel free to let me know if you notice a dramatic change (or not!)

I bought the Samson CO1U USB Condenser Mic (plugged it into my USB port and Vista said "fine!") with a 19mm diaphragm, heavy gauge grill and Cardoid pickup (eh?) paired with the Samson Shock-mount and (most important) a pop filter that mounts to the OnStage Euroboom Mic stand that holds everything in place while I record.

I'm going to have to start recording podcasts to make this worthwhile.  What, I wonder, could I put in a podcast that would be worth listening to?  I think I might start by bringing a pocket recorder to TechEd and recording the first episode of....  "Silverlight Geek TravelBlog."

Hey! That could even be worth doing.  You were here, right now, just as I thought of it!   I could combine first hand impressions with impromptu interviews. (I'm beginning to feel like Mickey Rooney: "I know, let's put on a show! Yeah, it'll be great...")

The Great Asynchronous Learning Experiment - Beginning 1.1 with Drag and Drop

As you may know, I've been tracking the learning process through this "diary" of learning Silverlight with periodic blog entries.

 I recently began working with Silverlight 1.1 (Alpha) in anticipation of my presentation at Tech Ed, and while I was very excited to do so, when I sat down to write my very first 1.1 application I suddenly realized that I wasn't quite sure where to begin. I understood it all in principle, but I used to work for a very smart guy named Pat Johnson who was fond of saying "In theory, theory and practice are the same, but in practice, they never are."

My solution was to recreate the Drag and Drop application I had built in 1.0 as a new application in 1.1 and the result is posted under our How Do I videos for 1.1.  This turned out to be a great way to break through the inertial barrier to 1.1 and to get a visceral feel for the differences between 1.0 and 1.1.  I recommend this approach to those of you who have been programming in 1.0 and are ready to start tinkering with 1.1; start by rewriting something you've done in 1.0 (but make sure it is something you are very familiar with). The subtle differences are very illuminating.

The first thing you notice is that the "sample application" (the button and its animation) are no longer provided for you. Just as well - less to clean out.

The next thing you notice is that the XAML works "same as it always was."  On the other hand, every XAML object can be represented as a CLR object (explored in a subsequent and forthcoming video). 

The code-behind is different. In the original Scene.XAML the code behind was a js file, In my new version, it is a .cs file and thus I move into a fully type-safe object-oriented program and "mind set"  Thus, I no longer use untyped variables, but instead I use member variables, controlling their visibility and their type (e.g., private double beginX).  If you are already a C# programmer (you are, aren't you?) this is a wonderful change. (If you are not, you face an interesting question: should you buy a C# book now, or wait for the new books on C# 3?  Personally (speaking as an unbiased author of a C# book) I'd buy both!)

Another nice thing in 1.1 is that when you create an object in the XAML file and you save the file, it shows up in Intellisense in the .cs file, complete with its properties, event handlers, etc, and Intellisense makes adding event-handlers absurdly easy (see the video).

There will, eventually be three major changes from 1.0 to 1.1:

1.  The ability to write in managed code languages (e.g., C#)
2. The inclusion of a subset of the CLR and thus the ability to create XAML objects in code
3. The addition of numerous controls

We see items 1 and 2 today, and I'll be posting videos in the next few weeks to illustrate them. As soon as I'm able, I'll provide you with a timetable for #3 and then will explore each of them as they become available.

 A Final Note 1.1 vs. 1.0

I want to emphasize that 1.1 is in alpha and 1.0 is in release. Even while spending time in 1.1 and enjoying coding in C#, I keep returning to 1.0 because, so far, there is nothing I can do in 1.1 that I can't do in 1.0 and I believe it is very important (at this moment in history) to be proficient in 1.0 (at least) or to be "bilingual" -- that is, if I had to choose, I'd personally recommend:

• Know Silverlight 1.0 and 1.1
• Know Silverlight 1.0
• Know Silverlight 1.1

in that order

That will change, but not for a while (nope, we haven't said when yet) but right now, that would still be my recommendation.  I know that there are many who believe, strongly, that 1.0 is not useful to them; I can't offer an opinion because I don't know their particular circumstances but I can say that every time I've sat down with a developer who started out with that position, we've been able to conclude that the decision to eliminate 1.0 was premature. That said, 1.1 is surprisingly useful for an alpha product, but it is in alpha.

Animation is not a toy

One of the frustrations of creating "How Do I" videos is that to keep them simple enough to be useful educationally, they must often be useless from a real-world perspective. Nothing makes me crazier than when I go to a sample application and it is more of an example of "look what a clever programmer I am" than it is of "look how easy it is to use this."  That said, if you can't make the leap from the example to the problem you're trying to solve, the example is equally worthless.

Animation in Silverlight presents a particular challenge: how do you show how to animate a figure simply enough not to confound the user and yet trigger the user's imagination into "ah! I could use this to..."  In my latest video I tackle that challenge: using animated bar graphs to show how the relative percentage of sales changes for a set of books over the 12 months of a year.

To keep the example simple, I "fake" the part that is not relevant: downloading the data from the web service. Since I know I can get the data as a JSON structure, I simply create a 2 dimensional array representing 12 months of data for 6 books. In a real-world scenario, I'd get N months of data for M books.

Similarly, to keep the example simple, I hard code the 6 storyboards,  with their 6 animations and then call them individually. But that duplication of code gives me the willies, and so I will follow this up with a new HDI video on how to generate these storyboards and animations programmatically, based on the data retrieved from the web service, thus creating a much more dynamic and robust program (there's always more to do )

A second place that I can see animation making a real difference to an application is combining it with "hyper-video" as shown in this first attempt and an improved version to be posted soon.  In both of these versions we supply links to web pages with "more information" but one can well imagine opening an animation that illustrates the point being made. Imagine, for example, that you are looking at a movie on cellular biology and you come to a part that confuses you. An indication appears on screen that there is supplemental info available. You click on it, the movie pauses, and an animation begins that opens up the cell and explores and points out the specific area of the cell under discussion. Sometimes animation can illustrate things that words or even actual movies can't; stripping away complications and yet using movement to provide enhanced understanding.

Should I commit to Silverlight 1.1 or Flex?

I recently received the following email (abridged and identity disguised)

The other side (FLEX) is developing very sophisticated apps. I mean for example Buzzword or Sliderocket....My question: Will the Silverlight framework allow us to create a Rich Text Editor in the near future?

A couple things to note about his message. The importance was marked High. I don't think he did that lightly; this is a very important question for a lot of folks. Second, he refers to Flex as "the other side."  I don't see it that way, but a lot of folks do, and perception matters.

I won't bore you with my entire response (I thanked him for writing, put him in touch with the right people, etc.) but will reproduce the parts of my response that I think may be relevant to this blog...

Silverlight 1.1: What Have You Learned Dorothy?

Well, I - I think that ...- if I ever go looking for my heart's desire again, I won't look any further than my own back yard. Because if it isn't there, I never really lost it to begin with! Is that right?

It is actually a great deal of fun, mostly because there is the instant realization that for now (given that the soon-to-be-released toolkit-items are not yet available, we're still just dealing with XAML and code, but the code, of course, is C#, which (for me) is ever so much more satisfying than working in Javascript (both because I know it better, and because it is type safe and fully object oriented. I admit, I did find getting started a bit intimidating, but it turns out to be pretty simple, especially if you read the label and follow the directions; that is, if you just click on Silverlight Project in Visual Studio 2008. What you start out with is a nice XAML file that is unencumbered by a sample (no click button!) but which does have a very simple code-behind file, and an HTML file with a Javascript code-behind file. As you might expect, the HTML file creates the Silverlight control inside a div and the HTML code behind file calls CreateObjectEx, not unlike what we did in 1.0.  What's new, of course, is that the code behind for Page (not Scene).XAML is a C# file, and in there the default is to have a Page_Loaded method but no constructor, but we are free to write our own constructor, and we get wonderful support from Intellisense.

My first venture was to reproduce an application that I had already written in 1.0, exploring brushes, and fills and the code that goes with them, and comparing that to 1.0. It was pretty interesting but held few surprises. 

One of the features that was not in 1.0 but is in 1.1 (as well as in WPF) is that every XAML object is isomorphic to a CLR object; that is, anything you can create in XAML you can create in code. That was too cool not to play with, and that became my second video on 1.1

In 1.0 if you match up HTML and Silverlight and you want to convey information from an HTML control (e.g., a button or a text box) to that Silverlight control, the HTML object must send the information into the Silverlight control. In my third video, I explore how the Silverlight control can make a reference to the HTML objects and then "reach out" and grab what it needs, including creating event handlers for the HTML objects (very cool).

That lead me to the idea of creating a custom control in Silverlight 1.1 and that in turn lead me to a dilemma.  What custom control could I possibly create that didn't run the risk of being absurdly obsolete by the time we release all the nifty toolkits that are on the way.  Which lead me to thinking about why we create custom controls in the first place, and one good reason is if we need a bit of UI that has custom behavior or properties, that we want to use again and again and that we want factored out and cleanly encapsulated.  What could be more fun than to take the opportunity to factor out and encapsulate a bit of UI from Conway's famous cellular automata Life.

Those four videos will be coming out soon (and I'll provide more information about them when they are posted) but I wanted to keep you up to date. The short story is this: I will have no trouble going back to creating applications in 1.0 (rather than 1.1) because they are so similar, but, once 1.1 controls hit, then it will be harder to tear me away.

In the meantime, enjoy the new videos once they are posted and let me know about your experiences moving back and forth between 1.0 and 1.1.

Writing about 1.1

Over the next few weeks I'll be creating a number of How Do I videos on Silverlight 1.1.  There are a number of reasons why I'm making this departure, including,

• Multiple requests from developers who would like a little help getting started with the alpha version
• Curiosity about the differences in building 1.1 vs. 1.0 applications and

...the real reason: I am scheduled to give a presentation on Silverlight 1.1 at Tech Ed in November, and I'd like to be a good bit more comfortable with programming in 1.0 and 1.1 by then.

 It turns out, of course, that the hard part is just getting started. Once you write your first Silverlight 1.1 application, the rest is easy.

In fact, my first video on the subject will be on porting a 1.0 application (drag and drop)  to 1.1 and comparing the differences. I won't make you wait, here's what I found

• The XAML is identical
• The code is type safe and object oriented, just like you want it to be
• If you know 1.0 it is shockingly easy to code in 1.1

 So now it is on to new challenges in 1.1 while I eagerly await the features that we'll be adding in coming months. I look forward to your feedback about these videos before I return to 1.0 and explore the relationships between Silverlight and AJAX.

Where to find the code from my presentations at Ajax World

The Ajax world presentations were relatively brief (45 minutes) and scattered (there were 10 tracks) and so we were not able to dig as deeply as I had hoped. That said, we did delve into the following topics:

• How to draw shapes and use fills in XAML by hand (attached)
• Drag and Drop
• Basic Animation (attached)
• Animation for Data Analysis (will be uploaded to video site soon)
• Basic Transformations
• Hypervideo Part I