• 5 Simple Steps for MVVM
• Keeping up with the community
• Top blogs
• MVVM Light
• Ward Bell’s photos

Grok. Verb: To fully understand.  See Stranger In A Strange Land by Robert Heinlein.  1961

Listen | Return to Yet Another Podcast

Call in comments:  1-347-YAP-CAST

This is often just fine, no harm done (other than to our self-image as rational geeks) but some of these totemic-rituals are stumbling blocks in our ability to produce reliable software.

From time to time we might want to stop and question our most cherished assumptions to see if we’ve fallen into any of these traps:

• Secrecy and Mystery
• Ancestor Worship
• Apophenia
• Argument From Authority

Secrecy and Mystery: Data Hiding

I’ve been writing in and teaching C++ and C# for twenty years. I know well the iron-clad rule of object -oriented programming that class data should be hidden (private) and accessed through either a property (C#) or an accessor function (C++). Thus:

public class Employee
{
    private string name;
    public string Name
    {
       get { return name;}
       set { name = value;}
    }
}

There are good reasons for this rule. Data hiding makes for a better decoupling of classes, and allows the programmer to intercept the access of private data and apply rules or other processing. It is possible, for example, to check whether the client accessing a value has the correct permissions to see or modify that value, and also to massage the data in appropriate ways.

But look closely at the example shown above: it is not unusual. The backing data is stored as a private local variable, and full access is provided with a get and a set accessor, neither of which do anything but return or set the value. That is, the accessors add no immediate value at all. The typing penalty is solved with automatic properties,

public class Employee
{

    public string Name
    {
       get; set;
    }
}

But to some degree this just hides the problem.  After all, why not write

public class Employee
{
    public string Name;
}

Don’t panic when you see this; consider that there is little difference from the automatic property and it is a heck of a lot more straight forward.

The last, desperate excuse, as you will find in many computer books, including my own (I add with some chagrin), is that making the backing variable private (or using automatic variables, and changing them when needed) allows you to change how you store the data without breaking any client of your Employee class. You could, for example, decide some time in the future to retrieve the name from a database.

The rational  part of me suspects that the number of person hours wasted, both by all the hocus pocus of properties  is swamped by any possible benefit. And, yet, I can’t quite bring myself to eschew the properties.

The problem is that can’t justify my reluctance rationally. Either this is a superstition, or more likely, it is the Asch conformity effect, in which students were shown three lines,  one distinctly longer than the other, but confederates of the experimenter in the audience insisted that the shorter was longer. If three confederates or more made the false assumption, the subjects were likely to go along more than a third of the time(!)

Ancestor Worship

Let’s take an example where we are not only being irrational, but also making our lives harder and our code more expensive to write and to maintain.

You may want to sit down for this one, but I’m going to dare to ask: why do we insist that C-derived languages (such as C#) continue to be case sensitive?  Other than paying homage to Kernighan and Ritchie I believe I can safely say after 20+ years of writing in C, C++ and C# that the disadvantages of case sensitivity swamp the advantages.

The only clear advantage I have ever found is the ability to have make the name of a property be the PascalCase version of the camelCase name of the backing variable

private int age;
public int Age { get { //... } set { //.... } }

In exchange for that convenience, we enjoy hours of debugging, trying to find where we inadvertently introduced a new variable or method name because of a misplaced shift-key.

And even in the best case, the argument is obsolete,  as the convention now is to use an underscore

private int _age;
public int Age { get { //... } set { //.... } }

Has any bright graduate student done research on the cost/benefit of case sensitivity? Is there any rational reason that in 2010 C# continues this ‘“tradition”’ that was established 30+ ago? Or might it be a lingering fear of showing disrespect to the icons of our industry; the mighty heroes who created the C family, defeated Troy and bequeathed us the scriptures by which we live?

Or Maybe Not…

There is an argument that case sensitivity makes more sense with some human languages other than English, and may even make sense as an optimization for some data structures, such as hash tables. Such arguments, however, speak to the need for an optimizing compiler to handle the issue; there is no reason for the language to do so.

C++ programmers like to suffer anyway, so this just feeds the beast.

Ancestor Worship II

Here’s another example of latent ancestor worship (or at least of very old habits dying hard). There is a wonderful myth that American standard rail road tracks are the width they are (4 feet, 8.5 inches) because that is the way they built them in England, which the English did because that is the way they were gauged by the first tramways, which in turn was done because that is the width of wagon wheels created to fit in the wheel ruts in old English roads that were in turn dug by by Imperial Roman Chariots.

The myth has tremendous lasting power (you can find it all over the net) because it feels right (expectation bias?) . We do that kind of thing a lot; we build the streets of Boston on old cow paths; we unconsciously follow old patterns, even when  those patterns no longer make sense or are necessary.

How many times have you seen (or written) code like this:

for ( int i = 0; i < innerArrayLength; i++ )
{
    for ( int j = 0; j < outerArrayLength; j++ )
    {
        myArray[i][j] = i * j;
    }
}

Why are the counter variables i and j? Old cow paths. It turns out that in Fortran (remember Fortran? Remember Eisenhower?) the integer variables were the letters I through N (which comes from an even older tradition of mathematicians using i to n as subscripts for integers), and, well, we just got into the habit. This one is fairly harmless, a ritualized and vestigial part of the programming mind that we’re surprisingly reluctant to let go of.

Pattern Recognition

One of the most powerful forms of magical thinking is Apophenia: seeing patterns or connections in random data. The tendency towards Apophenia is probably hardwired into the human brain; it is the price we pay for the very advantageous  human ability of pattern recognition (an adaptive part of our intelligence that helps us know when to run and when to hunt) but it can also lead us astray (arguably it is the basis of our belief in many pseudo-sciences).

Apophenia is certainly pervasive in consulting. A classic example was the tendency to study “’excellence’” in successful companies in the 1980s; trying to extract those apparent essential elements that lead to success.

Unfortunately, not only was it far more complex and difficult for other companies to reproduce success following these patterns, even the iconic companies themselves felt the worm turn over time. They kept repeating their patterns, but the outcomes were different. What went wrong?

It was not clear that the patterns of ‘“excellence”’ we were “seeing” in successful companies (great customer service, their caring attention to employees and attention to details) were as easily connected with success as we had thought. Correlation is not always causation, as we so often learn (post hoc ergo propter hoc).

Argument From Authority

Argument from Authority, to disagree with Samuel Johnson, is the true last refuge of scoundrels.

Some years ago I testified as an ‘“expert witness’” in a civil lawsuit, at which the opposing ‘“expert witness”’ asserted that the ‘“failure”’ of the project could be attributed to a lack of strict compliance with the ISO 9000 standard.

Smart people can have a reasonable discussion about whether ISO 9000 will improve the likelihood of success on very large projects (e.g. , the software for the mission to Mars). I personally would not like to work on a software project that is managed using anything like such a bureaucratic, heavyweight, inflexible, document-intensive, rigid processes, but that does not necessarily mean that I can prove that no project would ever benefit from it.

I had no hesitation, however, in asserting under oath, that the fact that various authorities asserted this was the right process for every project was abject nonsense.  I went on, at the arbiter’s insistence, that my personal assessment was that  a project with ten developers would benefit from strict adherence to ISO 9000 like a drowning man would benefit from being thrown an anchor. It was my opinion that knee-jerk reliance on a process like ISO 9000 to guide you through each project is a form of Apophenia; the connection between the pattern of ISO 9000 compliance steps and success, however measured, is imaginary. And, I concluded, supporting that theory with Argument From Authority was, at the least, irrational.

Looking where the light is

There is an old joke about a man searching for his keys under a street lamp. He lost the keys in the alley behind him, but this is where he can see.

In our desperate attempt to gain control over very complex processes, with so much money at stake, and so many examples of previous failures, we often fall victim to seeing apparent patterns (be they processes or otherwise) where they do not exist. We examine various projects and say:

“’Ah ha! I see why this project worked and that one didn’t: the difference was too much/ (too little)  analysis (/ design) (/ documentation) (/ process) (/ oversight) (/ communication).

And all we have to do is increase/  (decrease) the number/ le (length) (/ duration) (/ sequence) (/ complexity) (/ formality) of the meetings (/ documents/ ) (diagrams) (/ studies) (/ sign-offs) , etc.

These false patterns lead us astray; offering us the promise that if we paint by the numbers, we too can be Renoir.  It may be, however, that the variables of successful process are far more complex; including, if we are terribly unlucky, factors over which we have little or no control; or, only marginally better, factors over which we will have no control until our tools and technologies mature.

Or, it may just may be that some developers are better at the ‘“art”’ of programming and shipping product; and that the old adage ‘“’tis a poor carpenter who blames his tools”’ applies to software as well as it does to other crafts.

The Scientific Method

Over the years, at least to some degree, society has given up many (though not all) of its superstitions when presented with more compelling alternatives. One of the most effective techniques for distinguishing between superstition and truth (or some approximation of truth) is the scientific method; in short, controllable, measurable, reproducible effects that are disprovable.

It’s hard to do that sort of thing when you’re trying to hit a deadline, and it’s particularly hard to sort out all the alternatives when there are so few objective comparisons.

When was the last time you were able to find anything like an objective answer to the question “which is better: Java or .NET?” (Please don’t write in, my mailbox fills quickly).

It is particularly interesting that the work done at Universities and Research Centers is often not only unrelated to, but totally disparaged by, the folks who write code for a living. That is not the way things work in other Engineering fields and I’m not convinced we can afford the disconnect for much longer.

We seem to be writing 21st century software with a 12th  century mindset and that can’t be good.

• Comments rust faster than code, even when you’re careful
• Well written code can be read, and comments are annoying footnotes
• Comments make for lazy coding

Now, setting the bar at no comments at all seems a bit fanatic, but any value greater than zero is an invitation to using comments when better approaches are available, and like any addiction, I bet you can’t stop at one.

The Traditional View

In Programming C# 4, we write,

“…so even if your code is sufficiently clear that it’s easy to see what it does, it may not be at all clear why it does certain things….

We then go on to give an example,

Frobnicator.SetTarget("");
Frobnicator.SetTarget("Norfolk");

and then suggest that a comment will clarify the purpose of the code,

// Frobnicator 2.41 has a bug where it crashes occasionally if
// we try to set the target to "Norfolk".  Setting it to an empty // string first seems to work around the problem.
Frobnicator.SetTarget("");
Frobnicator.SetTarget("Norfolk");

You can, however, eliminate these comments by being willing to put that information into the method name,

private void SetTargetToEmptyStringToWorkAroundBugInFrobnicator()
{
   Frobnicator.SetTarget("");
}

SetTargetToEmptyStringToWorkAroundBugInFrobnicator();
Frobnicator.SetTarget("Norfolk");

What I prefer here is that the code and comments cannot get out of sync, and if the bug goes away, I just remove the obviously redundant code.  Since I started this approach I’ve not found the need for comments (nor the need for such absurdly long method names).

NB: I’m not advocating (yet), just experimenting.

Beware of the temptation to refactor,

When I first wrote this, I was tempted to factor out the common code:

private void SetStringToEmptyToFixBugThenSetStringYouWant(
                                string newString)
{
    Frobnicator.SetTarget("");
    Frobnicator.SetTarget(newString);
}

SetStringToEmptyToFixBugThenSetStringYouWant("Norfolk");

While this has appeal, the problem is that when the bug is fixed, I’d have to change every call to this method everywhere, rather than just eliminating the call to the fix. Ugly.

Of course, I could add comments to explain why the code no longer makes sense:

The last thing you want is to end up with code like this!

// no longer need to set the empty string private void SetStringToEmptyToFixBugThenSetStringYouWant(
                                string newString)
{
    //   Frobnicator.SetTarget("");    Frobnicator.SetTarget(newString); }

SetStringToEmptyToFixBugThenSetStringYouWant("Norfolk");

Yikes!

The advent of Windows Phone 7 is particularly exciting to current Silverlight programmers, because Silverlight (along with .xna) is the development platform for the new phone.  I recently recorded two Silverlight TV episodes, and in one I created a typical form that might appear in any LOB application, but I created it simultaneously on both the phone and for the web using identical Xaml and C#.  (This is not to deny that there are some differences in coding for each, but the overlap is very very high).

Link to SLTV video

But does it make sense to create the same application on the web and on the phone?

Certainly that is the default assumption… you take your application and shrink it down to the form factor of the phone.

This crude migration never makes it to market (or dies a quick and painful death) because a phone has (surprise!) a much smaller screen.

The    improvement is to re-envision the UI to be easier to use on the smaller screen.

And, frankly, that is where most developers stop.  Not that this is bad; there are many applications that have been modified so as to have an excellent phone UI and I’m certain that Windows Phone 7 will have many exemplary migrations.

It is not that this is bad, but it may be a missed opportunity.  The phone offers different opportunities, different use-cases and different capabilities than a browser or desktop application.  Is it possible to create a second, complimentary application that stands on its own but together with the web application make for a greatly enhanced experience?

Transmedia Storytelling

The premise of Transmedia Storytelling is to tell the same story on various media, but to use each medium to its own advantage.  According to Wikipedia, the concept of Transmedia Storytelling was first mentioned in 1991 by Marsha Kinder in her seminal work Playing with Power in Movies, Television, and Video Games: From Muppet Babies to Teenage Mutant Ninja Turtles She asserted that this approach  “works to position consumers as powerful players.”

Some ten years later this was picked up by Dr. Henry Jenkins at the  MIT Media Lab. He said,

The coordinated use of storytelling across platforms can make the story more compelling

Is there a lesson to be learned here for Win Phone 7 developers?  It is early days, but the Silverlight Hypervideo Project provides a great test bed for this concept.  Rather than simply migrating the HVP to the phone, we will pursue the idea of creating a separate, phone-based and phone-directed application that when used in tandem with the HVP will create a (you should pardon the expression) synergy that should make each more valuable.

Much more on this soon, and you can follow the progress of this effort on the HVP site.

[ Revised with C# and VB.NET code]

Okay, first, understand that I’m in the position of running through the streets yelling at folks “c’mere! ya’ gotta see this!” and what I’m pointing to is the incredible new invention of… a laptop computer. Something that is undeniably amazing and cool, but everyone else on my block has already got one.

Second, and much worse, I’m about to show you how I used a “pattern” that you either have already embraced, or that you’ve been avoiding like the plague because the folks who are running around shouting “MVVM! MVVM!” sound just like the folks who were running around shouting “MVC! MVC!” and “OOP! OOP!” and “COM! COM!”…  you get the idea.

Many of us are still recovering from the last five fads that caused us to go out and buy dozens of books and break our head on the latest/greatest trend, only to have it be “oh so last year” by the time we fully grokked it.

Drinking The Kool Aid*

But this is different. Honest.

Here are three heretical assertions about MVVM:

1. It is not all that different from what you are already doing
2. It is not hard to understand or to do
3. You will write better code, and you’ll write less code.

Typically, when a pattern or practice comes along, there is a steep learning curve, and the cognoscenti will tell you that it takes a very long time to truly master the approach. Feh. And not so, at least not this time. Let’s go over the assertions above, and I’ll explain, briefly, what you need to know to profit from MVVM.

It’s Not All That Different and It’s Not That Hard

We’ve been talking about n-tier development, decoupling, scoping, visibility and related topics since at least 1990. I’m pretty sure that when they were cracking the Enigma machine in World War II, they discussed decoupling the code-breaker module from the UI (did they have UI then?)

MVVM, at its heart has three core concepts, only the third of which is new, but that difference is all the difference in the world when you’re writing a Silverlight application that you want to be able to maintain and create unit tests for (Yes, I owe a blog post on Test-Driven design, but one glass of grape juice at a time).

Core Concept #1:  Separate your User Interface concerns (View) from your Business objects and behaviors (View Model) and from your data/persistence layer (Model).

Core Concept #2 Don’t Look Up.

We tend to conceptualize the View (User Interface objects) at the top, the ViewModel (objects that provide the UI with its data and behaviors) in the middle and the model (often the persistence layer) at the bottom.  The View can know about the ViewModel, the ViewModel about the Model, and the Model, like the cheese, stands alone.

Core Concept #3 – And this is the killer: Binding.

In MVVM the mechanism for the ViewModel to provide data to the View, is for the View to set the ViewModel as its DataContext.  That is so cool; it takes a while to realize the implications.  Further, we don’t just bind data, as I’ll show below.

Why Would You Want To Do That, & What Does It Cost?

The huge advantages of using binding and making the VM the datacontext for the View is that you write less code and, equally important, your behaviors and state are all separated from the UI and thus you have enormously increased the testability of your application. (It is a bear to try to test a UI object because the pesky UI gets in the way. ViewModels have no UI, they have just the things you want to test: “does it behave as expected? and is the data correct at any given instant?”

So, the cost is negative; that is, by adopting MVVM you don’t work harder, you work less, and in exchange for doing less, your code is easier to write, to read, to maintain and to test. Not bad.

Names

Simplifying is one thing, over-simplifying another, and there is an elegance in the chosen names.

The Model is that which the application is modeling. Calling this the database layer or the persistence layer loses site of the fact that the  model might be virtually any time of information in virtually any format.

Calling the top layer the View, rather than the User Interface is important both to emphasize that it is just one of many possible views of the model, and to keep clear that the User Interface comprises both the appearance and the behaviors and the View is concerned only with the appearance.

The ViewModel is the bridge between the Model and the View; and the ViewModel thus owns responsibility for binding the relevant data to the view and for handling user actions appropriately, whether the response is in the widget, elsewhere in the View or in other parts of the application.

A Practical Example

To see this at work, we’ll start by creating a new Silverlight Application. (Complete source code is available here)

Immediately add a new UserControl and name it PeopleView. Here is the Xaml for the UserControl:

C#

VB.Net

We start by defining a Person (lines 6-15) and then we give the PeopleViewModel class a property People which is an ObservableCollection of Person objects.  The constructor (lines 24-27) calls a method that mocks up getting data from the Model; in this case I just generate ten names on lines 30-48   The final code implements INotifyPropertyChanged, which is not required yet, as the only property we have is an Observable collection.

Binding

ItemsSource="{Binding People}"DisplayMemberPath="Name"

and then add this to the constructor in the code behind:

C#

VB.Net

Behavior

c:\Program Files (x86)\Microsoft SDKs\Expression\Blend Preview for
.NET 4\Interactivity\Libraries\Silverlight\
System.Windows.Interactivity.dll

C:\Program Files (x86)\Microsoft Expression\Blend 3
Samples\Silverlight\Design\Expression.Samples.Interactivity.dll

xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=
System.Windows.Interactivity"xmlns:si="clr-namespace:Expression.Samples.Interactivity;assembly=
Expression.Samples.Interactivity"

and finally, you modify the control (the listbox) to add the trigger and behavior

The EventTrigger has a property for the EventName; indicating that this trigger will fire when the event SelectionChanged is raised for the ListBox.  The CallDataMethod has a property Method for the name of the method to invoke. Since the ViewModel class is the data context, you don’t need to indicated which class supplies the method, any more than you need to indicate which class has the property People to which the ListBox’s ItemsSource is binding.

Just add that method to the ViewModel class…

C#

VB.Net

… and start your program. When you change the selection, the method you’ve bound to will be called.

In the Silverlight HVP this will allow us to bind the event notification to the SelectionChanged event, further decouples the control from its data and logic. The technical term for this is “good.”

Overall Impact of Refactoring for MVVM

While this  is not an exhaustive understanding of MVVM by any means, with these fundamentals, it became obvious how to break up my code, and I found that there was less of it, and it was more intention-revealing.

In fact, the code-behind for my View classes have no code at all except setting the dataContext; and the ViewModel code is short and extremely readable.

All in all, I find MVVM well worth the small cognitive startup costs; yielding a very natural separation of concerns, and perhaps equally important, exposing far more of the program to unit tests, and thus driving down the overall time to release.

———————————–

* In 1978 cult leader Jim Jones induced 900 followers to commit “revolutionary suicide” by knowingly drinking cyanide-laced grape Flavor Aid. To the chagrin of General Foods, the cultural memory of the event is that they drank Kool Aid and the expression. To drink the Kool Aid has evolved to mean “to embrace without reservations, the ideas of a strong leader”

Executive Summary

This article continues the design and exploration phase of the Silverlight HVP project by beginning to examine the role the Managed Extensibility Framework (MEF) will play in solving a number of challenges in the project.

Goal: Creation of an Extensible, Modular, Reliable, Robust application

The Silverlight HVP poses the challenge of accommodating the different functional requirements that different audiences will want built into or added onto the player. Further, we know that if the Silverlight HVP is a success the requirements will evolve over time as the player is adopted and adapted in unanticipated ways.

This, of course is not unusual in software development, and a number of “patterns” have emerged to handle shifting requirements and the need to be able to add and remove parts of an application over time or across deployments. Key to this are certain well understood approaches:

• Decoupling of the various tiers: presentation, business logic, data, persistence, etc.
• Loosely coupled functional modules
• Composite Applications

To achieve the decoupling we desire, as well as to create a highly reliable, performant and robust application, we’ve decided to integrate the Managed Extension Framework (MEF)  from the very start. [We will look at adding Prism after R1].

In addition to providing crucial loose coupling among functional modules, MEF will help significantly with:

• Improved performance by allowing on-demand delivery of modules, and creation of smaller .xap files (and thus faster load)
• Extensibility through Discovery (the core program need not know all the available modules)
• Post-production plug-in capabilities.  (E.g., if we want the HVP to be a plug-in for other programs that were not designed with MEF, we can accomplish this by creating a wrapper around the other program and then plugging in some or all of the HVP)

There is a good bit more, but this already is a lot to consume.  In this (and possibly a few subsequent tutorials) as well as a forthcoming video or two, I will walk through using MEF in the project exactly as I would were I doing this on a paid project as an independent consultant.

Goal Based Successive Approximation

My approach to new technologies is typically successive approximation, driven by the goals of the project. To begin, I’ll want to understand how I can add a simple visual component to my application without the author of the application knowing in advance what I’ll be adding.

MEF will allow me to take one of two approaches to placing the control onto my page:

• The hosting application knows about the new component, allocates space and tells the component where to display itself, or
• The hosting application does not know about what components may or may not exist, but provides a place for each discovered component to display itself

(You can certainly imagine a somewhat more complex combination of the two in which all modules are discovered, each describes its own layout requirements and requests (I need 50×200 but want 250×400) and then the host provides panels.)

In this case, what I hope to do is to build a fairly simple MEF proof-of-concept within the HVP shell, and then add more capabilities in upcoming Mini-tutorials,  that are successively of greater complexity and utility.

To begin, I’ll check-out and open the HVP Source Code (for now, I’m using Subversion to manage the source. If you are interested in contributing the the project, please contact me and I’ll add you as a Developer). [See note at the bottom of this posting on the versions involved]

Handling Complexity of Opportunity

In MEF as in many of the technologies we’ll be using, there are often many ways to accomplish the same thing. My general approach will be:

• Start with whatever is simplest
• Explore more complex options when they meet a need of the project or are so incredibly interesting I can’t resist the tangent

Within this approach, I will typically explore simplified versions of any approach (stripped down, with minimal supporting infrastructure or error handling) until I grok what is required, and then I’ll go back and make it work for the project. Specifically, I have sketched out this design using Expression Blend with Sketchview

The top row consists of the Table of Contents and the List of Links flanking the running video. The bottom row has four panels into which MEF can place visible objects.

In the first iteration, I’ll create a Part that might be added to the HVP; specifically a note taking area so that you can jot down notes when you are watching the video and then copy and paste them to another application later. So as not to get distracted by side issues, I’ll use the Rich Text Area control, but I won’t, at this point, get caught up in the details of supporting rich text.

While I will want to experiment with downloading the module on demand, and discovering where it wants to be (left, center or right), and quite a bit more, I like to start simple, hard-coding as much as I can to focus on the issue at hand: adding a new control to my existing application.

My first modification is to the Home Page where I’ll add three columns and two rows, and place a TabControl into the middle of the lower row. What follows is an excerpt showing the relevant declarations. (For complete source code, please see the bottom of this posting)

<controls:TabControl Name="MefTabs"

                     Grid.Column="1"

                     Grid.Row="1"

                     Margin="5"

                     HorizontalAlignment="Stretch"

                     VerticalAlignment="Stretch">

   <controls:TabItem Name="tabItem1"

                     Header="Tab 1"

                     FontFamily="Georgia"

                     FontSize="12" />

   <controls:TabItem Name="tabItem2"

                     Header="Tab 2"

                     FontFamily="Georgia"

                     FontSize="12" />

</controls:TabControl>

Creating the Part

We’ve specified that the new module will provide note-taking capability. We’ll start by creating a control to do just that, but let’s think ahead just a bit about what we’re going to tell the TabControl about what we’ll be adding to it.  We could create a NoteTaking object and then tell the TabControl that it will take a NoteTaking instance, but that would tightly couple the hosting container to the new module, a bad idea especially since we anticipate that there will be new modules created after we release the application.

What we want is to signal that we’ll be adding some sort of new part, but that the host does not need to know any of the details (which is a good thing,  because by the time the host is completed, the new part may not yet be conceived!)

Terminology

It is imperative we agree on certain common terms,  or confusion will quickly take the wheel and drive us off a rhetorical cliff.

In our example, SilverlightHVP is the application and the TabControls will host the new Parts.

We’ll define a Part as an object that can be added to our application using the Import/Export mechanism of MEF.

We will need to tell the TabControls the type of the Parts we’re adding. We can do that in any number of ways, but two are most common as they afford the most flexibility:

• Define the new Part to be a UserControl and tell the TabControls to expect UserControls but not what sub-type of UserControl.
• Define an interface, (e.g., IPart), and have every Part implement that interface. Tell the TabControls to expect objects that implement the interface.

We’ll choose the latter as I’m wary of deciding today that every part we will ever create or host will be a UserControl.

NoteTaker

Our new part, which will extend the HyperVideo Player, will be the note taking region described above, encapsulated within a new UserControl: NoteTaker.

In a future iteration we’ll define NoteTaker in a class library. For now, to keep this a bit easier on my brain, I’ll add a new project to the current solution, named SilverlightHVP_Extensions.

To do this, click on Add->New Item and select Silverlight Class Library; delete the class.cp that Visual Studio creates and add a new User Control named NoteTaker.xaml. Since I want this class to implement the IPart interface, I need to define that interface, and I will do so in yet another proejct. which following convention I will name SilverlightHVP_Contracts. That entire project consists of IPart.cs / IPart.vb

C#

namespace SilverlightHVP_Contracts
{
  public interface IPart
  {
    // marker interface
  }
}

VB.NET

Namespace SilverlightHVP_Contracts
  Public Interface IPart
    ' marker interface
  End Interface
End Namespace

I can now return to to my NoteTaker class and define that it implements IPart. For the class to recognize the interface, it will need a reference to the SilverlightHVP_Contracts project. That allows me to write

public partial class NoteTaker : UserControl, IPart

though IPart will still have a red underline as I’ve not added the Using statement. I can do so by hand, or I can click on IPart and enter ^. (control dot) which brings up a context menu offering to add the using statement or to modify the reference to IPart to include the namespace,

Exporting NoteTaker

The heart of MEF is that a Part can be marked for Export, allowing any consumer to Import it.

To mark the NoteTaker for Export, however, we need to add a reference to the required DLL:  System.ComponentModel.Composition   You’ll find that in  …Microsoft SDK’s –> Silverlight –> v4.0 –> Libraries –> Client as shown.

The code-behind file (NoteTaker.xaml.cs/vb) now looks like this:

C#

using System.Windows.Controls;
using SilverlightHVP_Contracts;
using System.ComponentModel.Composition;

namespace SilverlightHVP_Extensions
{
  [Export( typeof( IPart ) )]
  public partial class NoteTaker : UserControl, IPart
  {
    public NoteTaker()
    {
      InitializeComponent();
    }
  }
}

VB.NET

Imports System.Windows.Controls
Imports SilverlightHVP_Contracts
Imports System.ComponentModel.Composition

Namespace SilverlightHVP_Extensions
  <EXPORT (GetType(IPart))>
  Partial Public Class NoteTaker
      Inherits UserControl
      Implements IPart
    Public Sub New()
      InitializeComponent()
    End Sub
  End Class
End Namespace

Adding NoteTaker To The Application

The challenge now is to add the NoteTaker to the application when the Application doesn’t know NoteTaker exists. You’ll remember, however, that we did agree that our TabControl would know that it will take something that implements IPart. That is all we need, we can ask it to bind to a collection of IPart objects, and then distribute the IParts appropriately.

In Home.xaml.cs be sure to add references to

• System.ComponentModel.Composition
• System.ComponentModel.Composition.Initialization
• SilverlightHVP_Contracts
• SilverlightHVP_Extensions

with these in place, and the three corresponding Using statements at the top of the file,

• using System.ComponentModel.Composition;
• using System.Collections.Generic;
• using SilverlightHVP_Contracts;

You are ready to rock and roll.  There are two steps:

1. Tell your Home page that you will have a collection of… (what?)  The type we have designated is “objects that implement IPart”:

C#

[ImportMany]
public IEnumerable<IPART> parts { get; set; }
</IPART>

VB.Net

Private privateparts As IEnumerable(Of IPart)
<IMPORTMANY>
Public Property parts() As IEnumerable(Of IPart)
 Get
    Return privateparts
 End Get
 Set(Byval value as IEnumerable(Of IPart))
    privateparts=value
 End Set

While we happen to know there is only one, MEF allows for any number of IPart implementing extensions.

The ImportMany attribute signals that this host will import all the IPart objects it can find.

2. Signal that now is the time to import since you have a class that imports but does not export (Home).  You do that by calling

C#

PartsInitializer.SatisfyImports(this);

VB.Net

PartsInitializer.SatisfyImports(me)

Once you have invoked PartsInitializer.SatisfyImports, the parts collection is populated, and we can iterate through it, obtaining each part in turn. In this first iteration, we just grab the part and assign it to the Content property of the first tab.

C#

PartInitializer.SatisfyImports( this );
foreach ( var part in parts )
{
  tabItem1.Content = part;
}

VB.Net

PartInitializer.SatisfyImports(Me)
For Each part In parts
  tabItem1.Content = part
Next part

Source Code

The complete source code for the starting application is available at http://slhvp.com – click on Source Code.

The Silverlight HyperVideo Project has made two guest appearances on Silverlight TV. 

In the first, I talk with John Papa about the project itself and how it has evolved.

Then, during Mix, Tim Heuer and I sat down with John to discuss What’s New In Silverlight 4, and I managed to sneak in a few comments about the HVP as well.

Silverlight TV has numerous great interviews, and is quickly becoming a valued asset throughout the Silverlight community. 

Tens of thousands of people view each episode. Check it out here.

Then take a look at John Papa’s site as well.

Then come back here, because the last thing I want is for you to decide you like JP so much you stop visiting. Next thing you know, I’m sitting in the dark.

This mini-tutorial is part of the SLHVP documentation

One of the goals of the Silverlight HyperVideo Project is to demonstrate best practices.  So when is it okay to throw in a quick hack to get things working?

Case in point: as I approached the release this week for the latest alpha,  I noted that the player was not updating when the user clicked on a topic, though the links were appearing as if the player had been advanced.

To make the issue clear, in this image you see a cut down version of the player. Each item (video) has its own set of topics and links. The topics are shown as soon as the video starts, the links appear as the video plays.

If the user clicks on a topic (lower left) what should happen is that the video (middle) jumps to that topic and the scrubber  (below the video) should advance to indicate where in the video the topic begins, relative to the start of the video.

(Click on image to see it full size)

After a bit of debugging (and some frantic calls to the Vertigo folks who wrote the Silverlight Media Framework, we were able to see that the problem was in the binding:

<SmoothPlayer:Player Style="{StaticResource SLHVPTemplate}"  x:Name="smoothPlayer">
    <hvp:HVPCoreMediaElement x:Name="corePlayer"
    SmoothStreamingSource="{Binding URI, Mode=TwoWay}"
    AutoPlay="True"
    Position="{Binding Offset, Mode=TwoWay}" />
</SmoothPlayer:Player>

Checking the source code for the SMF (available here) we found that Position is a dependency property and was not responding to the Binding as we expected.

Since the folks at Vertigo owned that code and were convinced they could fix this in the next release, I opted to take their change an copy it into my project. To encapsulate the hack, however, I created the HVPCoreMediaElement, derived from the CoreSmoothStreamingMediaElement.

C#

using System;
using System.Windows;
using Microsoft.SilverlightMediaFramework.Player;

namespace SilverlightHVP.View
{
   public class HVPCoreMediaElement :
           CoreSmoothStreamingMediaElement
   {
      public TimeSpan PositionOverride
      {
         get { return ( TimeSpan ) GetValue( PositionOverrideProperty ); }
         set { SetValue( PositionOverrideProperty, value ); }
      }

      public static readonly DependencyProperty PositionOverrideProperty =
             DependencyProperty.Register(
                "PositionOverride",
                typeof( TimeSpan ),
                typeof( CoreSmoothStreamingMediaElement ),
             new PropertyMetadata( HVPCoreMediaElement.OnPositionOverridePropertyChanged ) );

      private static void OnPositionOverridePropertyChanged(
            DependencyObject d, DependencyPropertyChangedEventArgs e )
      {
         HVPCoreMediaElement source = d as HVPCoreMediaElement;
         source.OnPositionOverrideChanged();
      }

      private void OnPositionOverrideChanged()
      {
         // Hack!!, to databind to Position
         Position = PositionOverride;
      }
   }
}

VB.Net

Imports System
Imports System.Windows
Imports Microsoft.SilverlightMediaFramework.Player

Namespace SilverlightHVP.View
   Public Class HVPCoreMediaElement
       Inherits CoreSmoothStreamingMediaElement
      Public Property PositionOverride() As TimeSpan
         Get
             Return CType(GetValue(PositionOverrideProperty), TimeSpan)
         End Get
         Set(ByVal value As TimeSpan)
             SetValue(PositionOverrideProperty, value)
         End Set
      End Property

      Public Shared ReadOnly PositionOverrideProperty As DependencyProperty = DependencyProperty.Register("PositionOverride", GetType(TimeSpan), GetType(CoreSmoothStreamingMediaElement), New PropertyMetadata(AddressOf HVPCoreMediaElement.OnPositionOverridePropertyChanged))

      Private Shared Sub OnPositionOverridePropertyChanged(ByVal d As DependencyObject, ByVal e As DependencyPropertyChangedEventArgs)
         Dim source As HVPCoreMediaElement = TryCast(d, HVPCoreMediaElement)
         source.OnPositionOverrideChanged()
      End Sub

      Private Sub OnPositionOverrideChanged()
         ' Hack!!, to databind to Position
         Position = PositionOverride
      End Sub
   End Class
End Namespace

I could then modify the binding

<SmoothPlayer:Player Style="{StaticResource SLHVPTemplate}"  x:Name="smoothPlayer"     >
    <hvp:HVPCoreMediaElement x:Name="corePlayer"
    SmoothStreamingSource="{Binding URI, Mode=TwoWay}" AutoPlay="True"
    PositionOverride="{Binding Offset, Mode=TwoWay}"
</SmoothPlayer:Player>

And all was right with the world.   This was minimally intrusive, and I was very pleased with it.  I should have known.

In For A Penny…

The problem, of course, is that now that I’m binding the new PositionOverride I’m reading wonderfully, but writing, not so.  There are a lot of ways to fix this, but the easiest, fastest and perhaps ugliest is to add a second binding. After all, binding to Position was working great for setting, and PositionOverride is now working great for reading.

<SmoothPlayer:Player Style="{StaticResource SLHVPTemplate}"  x:Name="smoothPlayer"     >
    <hvp:HVPCoreMediaElement x:Name="corePlayer"
    SmoothStreamingSource="{Binding URI, Mode=TwoWay}" AutoPlay="True"
    PositionOverride="{Binding Offset}"
    Position="{Binding PlayerPosition, Mode=TwoWay}" />
</SmoothPlayer:Player>

If this were the only change, maybe okay, but unfortunately we have to hack the VM as well,

C#

public TimeSpan Offset {  get { return state.Position; } }

public TimeSpan PlayerPosition
{
   get { return state.Position; }

   set
   {
      if ( value > previousPosition + Interval )
      {
         previousPosition = value;
         state.Position = value;
      }
   }
}

VB.Net

Public ReadOnly Property Offset() As TimeSpan
    Get
        Return state.Position
    End Get
End Property

Public Property PlayerPosition() As TimeSpan
   Get
       Return state.Position
   End Get

   Set(ByVal value As TimeSpan)
      If value > previousPosition + Interval Then
         previousPosition = value
         state.Position = value
      End If
   End Set
End Property

Oh What A Tangled Web We Weave…

This is so ugly, and so likely to end up being a headache when we are ready to undo it, that I’m very tempted to find a cleaner solution. On the other hand, I know that we’re actively working on SMF version 2, and that even before that I may have an interim release that makes the whole problem go away, so my Faustian bargain is to comment the hack

/*   HACK!! We are binding the getter of Offset to the Position of the CoreSmoothStreamingMediaElement
     but we are binding the setter to the PositionOverride property of the (temporary) class HVPCoreMediaElement that
     derives from CoreSmoothStreamingMediaElement.  Also note that this is two way binding and we need both the getter
     and the setter.
     To Fix:
        1. Combine move get and set from PlayerPosition to Offset and remove PlayerPosition
        2. Change Binding in SmoothStreamingPlayer to bind to Offset, two way
        3. Remove file (and class) HVPCoreMediaElement.cs
*/

 public TimeSpan Offset {  get { return state.Position; } }

 public TimeSpan PlayerPosition
 {
    get { return state.Position; }

    set
    {
       if ( value > previousPosition + Interval )
       {
          previousPosition = value;
          state.Position = value;
       }
    }
 }

VB.NET

'HACK!! We are binding the getter of Offset to the
'Position of the CoreSmoothStreamingMediaElement
'but we are binding the setter to the PositionOverride
'property of the (temporary) class HVPCoreMediaElement
'that derives from CoreSmoothStreamingMediaElement.
'Also note that this is two way binding and we
'need both the getter and the setter.
'To Fix:
'1. Combine move get and set from PlayerPosition to
'   Offset and remove PlayerPosition
'2. Change Binding in SmoothStreamingPlayer to bind to
'   Offset, two way
'3. Remove file (and class) HVPCoreMediaElement.vb

 Public ReadOnly Property Offset() As TimeSpan
     Get
         Return state.Position
     End Get
 End Property

 Public Property PlayerPosition() As TimeSpan
    Get
        Return state.Position
    End Get

    Set(ByVal value As TimeSpan)
       If value > previousPosition + Interval Then
          previousPosition = value
          state.Position = value
       End If
    End Set
 End Property

Let the Flame Wars Begin

“Well?,” as Howie Mandel’s tiny alter-ego Bobby asks, “what would you say?”

This posting is part of the Silverlight HyperVideo Platform documentation and a Silverlight Mini-tutorial. The information in this posting, however, should be of interest to anyone writing meaningful Line of Business applications with Silverlight.

The premise of the classic 1956 film Invasion of the Body Snatchers is that there are “pod people” among us, who are converting “normal” people into pod people one by one.

“Once you are a pod person, you think everyone should be one”

Once you begin seeing the benefits of TDD you tend to evangelize; its working great for you and you want everyone to become one.  This can be helpful, annoying or alarming depending on who you’re talking to.  My daughters, for example, are quite sick of hearing about it.

“They’re here already! You’re next! You’re next!”

It seems reasonable to many developers to create unit tests for their code; but the presumed high cost of doing so implies for waiting for a project that is not in “crunch mode.”  Most developers will be waiting a long, long, long time.

Experience indicates that TDD actually saves time – you spend less time debugging and more time coding. Unfortunately, that sounds like “a good theory” and we all know that In theory, theory and practice are the same,
But in practice, they never are.

The bigger problem is Isaac Newton. Most of us suffer from Newton’s first law (significant inertia) and when confronted with an evangelist, we are governed by his third law (the more you push, the more I push back.)

“Give Up! You Can’t Get Away From Us! We’re Not Going To Hurt You!”

That said, for the past few years I’ve had the nagging sense that I was missing something important.  Especially given that some of the folks I respect most in the industry were strong proponents; not least my mentors in all things good:  RMSquaredF: Robert (Uncle Bob) Martin and Martin Fowler who laid the ground work and established best practices in their seminal works Refactoring: Improving the Design of Existing Code (Fowler) and Clean Code: A Handbook of Agile Software Craftsmanship (Martin).  In the latter book, Robert Martin summarizes his approach which I paraphrase here:

1. Don’t write production code until you’ve written a failing unit test
2. Write just enough of a test to fail.
3. Write just enough code to pass the test

What you are aiming for is about a 30 second cycle of write-test, write-code, Run-test.

Uncle Bob’s premise is that you tremendously reduce your risk and thus your fear because your production code never gets ahead of what you know; and you know it because you’ve tested for it.

“I Don’t Want Any Part Of It.”
“But You’re Forgetting Something….. You Have No Choice.”

A second premise of folks who evangelize TDD is that you really have no choice; it is a case of “pay me now, or pay me later.” Either you create the unit tests or you spend that much time and a good deal more on debugging.

The Silverlight HyperVideo Platform project offered the ideal opportunity to take on TDD, and the only way to do so was by Fiat. Thus, I made the executive decision to require unit tests for all code checked into the project (not hard to enforce so far, as at the moment all the code in the project is mine).

“The words, the gesture, the tone of voice, everything else is the same, but not the feeling.”

The rules for writing good tests are very similar to writing good code, but with a couple extra requirements.  Stealing again from Robert Martin, here is a paraphrase of the good-test rules developed at his company, Object Mentor:

• Test must be quick. The slower a test runs the less likely you are to run it.
• Tests must be independent of one another; any side effects or dependencies must be avoided
• Tests must be repeatable: running the same test against the same code base must give the same results
• Tests must return unambiguous results
• Tests must be isolated from the production code

Configuration – ViewModel Objects

I published a plan for configuration that made use of Xaml files. I realized yesterday, in one of those forehead slapping moments, that a design that relies on placing configuration files on the client of course will not work due to access limitations.  No harm done: the Xaml files were just a mechanism for creating the configuration business objects; and there are natural server-side analogs.

The working design now looks like this (using a relational database for persisting the configuration information, and WCF-RIA Services for moving the objects to the client. (A forthcoming blog entry will walk through that aspect of the implementation in detail)

(Click on image for full size)

Links Vs Units

Links are a unique identification of a Unit, and Units are not represented by a class. A Unit is a set of Items (and the selected item), each item’s set of topics (and the selected topic) and each item’s set of links (and which links are currently displayed).  Notice that units are identified by a URL.  In V1 the selected item and selected topic are the first in the set, and this design is used only for configuration.

After v1, we’ll move from read-only to read-write, allowing the user to persist the current unit and to recreate the state of the application at a later time.

From Tables To Objects

The diagram above was created to show how the RDB would work, but it is a bit misleading.  What we really want is not tables but rather objects.  There is a very small jump (in this case) from the tables to the business objects as shown here:

(Click on image for full size)

There are a number of advantages to creating these objects, the most significant of which is that I can go ahead and implement the configuration without regard to how these objects were created, providing two implicit benefits:

• I don’t have to get all the WCF Ria Services code working before I can make configuration work and…
• The design now allows me to substitute virtually any persistence mechanism (database, Xaml configuration files, etc.) to back these business objects.

Further, these objects are part of the ViewModel, and facilitate binding the View to the ViewModel (as discussed in my mini-tutorial on MVVM).

Implementation

We’re now (finally) ready to implement this, and as an experiment in open, honest and direct explanation I’m going to do this in real time, documenting my experience of creating the Unit Tests and the classes and their methods as I do it.

One of the contributors to the slhvp project, Abby Fichtner (aka Hacker Chick) said to me just last night,

The great advantage of testing first is that it forces you to think about what the ideal API would be to each of your classes.

Exactically.

The Configuration Objects

The first implementation issue is this:  I already have the following objects in the project:

It isn’t clear if the existing Item, Link and Topic (location) classes can be used for configuration, and I have a nagging feeling that I want something more. But here is where Agile development comes to the rescue: Design for what you need right now.

Next up, A Real Time Walkthrough of Test-Driven Development….

The problem with using a blog to track a rapidly evolving design, is that blogs don’t make for very fluid documents; the unwritten rule is that once posted, you ought not go back and substantially alter a post.

Matching Blog Posts to Discussions

I do want to use these postings to keep everyone up to date on the evolution and lessons being learned in the SLHVP project, but we also need a way to consolidate the discussion and the evolving understanding, and so each blog post will refer to a specific discussion on CodePlex where the ideas will be discussed and will evolve. I’ll then post a roll up of changes periodically, but not in response to each posting. The most recent post is being discussed here, where I have recognized that I violated my own design principles and backed away from two lines in the previous blog post. Here is what I wrote:

Your questions reveal that I have violated my own design principles: "Do not let the design get ahead of what you know" — The right answer is, of course, to design only for what we know we need, and keep the design open enough to extend as new needs emerge. To answer your questions specifically:

…What I meant was that we know that videos will want to signal a marker has been encountered, and I can imagine that other frame components might want to signal that something has happened that is equivalent (you’ve reached the 4th level of play in this game)… then I went off the track and speculated that this should be handled by the Frame. But that is absurd.  The Frame might be the place to handle this, but I can easily imagine that there is a base class or interface that the video and game support or that there is a separate class they both associate with, etc. etc.  So let’s just strike that statement (which I will do by editing my message and referring to this discussion.

2. [Each module will have its own xml config file] Here is where I really went over the edge. I totally retract this statement. Maybe it makes sense for each module to have its own configuration file, but we’ll only know that once we have modules and we’ve worked with a single integrated configuration file (the manifest you have working). So let’s please stay with the manifest until it is manifestly not working

Please do join us in the ongoing discussion. Feel free to leave comments here about the form of the post, but substantive comments about the project will be seen by the most people, and those most involved, in the ongoing Discussions.

Thanks