On the previous post in this series we looked into the DataModel component in our architecture in detail and defined an abstract DataModel base class to derive our models from. On this post we’ll implement a concrete data model to represent a stock’s value. Why stock? It’s an object with a changing value that requires our DataModel constantly refresh and keep its data “alive”, and it’s simple to implement which makes it a perfect example for our first DataModel. The first thing we’ll do when defining our Stock DataModel is abstract the data source. This way we can easily implement several data sources for fetching a stock’s data and instantiate the DataModel with the right one (for example, read from Yahoo at runtime, read from fake data source during unit testing):

/// <summary>
/// Defines the interface allowing <see cref="StockDataModel"/> to read quotes from various providers.
/// </summary>
public interface IStockDataProvider
{
    /// <summary>
    /// Gets a given stock symbol's (given by <paramref name="symbol"/>) data.
    /// </summary>
    /// <param name="symbol">The stock's symbol.</param>
    /// <param name="name">The stock's company name.</param>
    /// <param name="quote">The last stock's quote.</param>
    /// <param name="change">The stock's change value.</param>
    /// <param name="open">The stock's open value.</param>
    /// <returns><b>True</b> if data was retrieved successfully; otherwise, <b>False</b>.</returns>
    bool TryGetData(string symbol, out string name, out double quote, out double change, out double open);
}

Now that we have our data source defined we can implement different stock data providers for our DataModel to consume. Now, lets go over the StockDataModel class:

public class StockDataModel : DataModel
{
    private string _symbol;
    private IStockDataProvider _quoteProvider;
    public StockDataModel(string symbol, IStockDataProvider provider)
    {
        _symbol = symbol;
        _quoteProvider = provider;
        this.State = DataModelState.Fetching; 

        // Queue a work item to fetch the symbol's data
        if (!ThreadPool.QueueUserWorkItem(new WaitCallback(FetchDataCallback)))
        {
            this.State = DataModelState.Invalid;
        }
    } 

    public string Symbol
    {
        get { return _symbol; }
    }

Our StockDataModel constructor takes the stock symbol that the model represents and an IStockDataProvider to fetch the stock’s data from. We set the initial DataModel state to Fetching and queue a work item for a background thread to update our model with the stock’s data - company name, quote, change value and open value. If we fail to queue the work item than we put the model in an invalid state. Next, we need to define the properties exposed by StockDataModel for data binding.

public string Name
{
    get
    {
        VerifyCalledOnUIThread();
        return _name;
    }
    private set
    {
        VerifyCalledOnUIThread(); if (_name != value) { _name = value; OnPropertyChanged("Name"); }
    }
}
public double Quote
{
    get
    {
        VerifyCalledOnUIThread(); return _quote;
    }
    private set
    {
        VerifyCalledOnUIThread(); if (_quote != value) { _quote = value; OnPropertyChanged("Quote"); }
    }
}
...

We’re sign a private setter to update the property values and trigger a PropertyChanged event if required. You can also add calculated properties. For example:

public double ChangePercent
{
    get
    {
        if (double.IsNaN(Change))
            return double.NaN; 

        if (double.IsNaN(Open))
            return double.NaN; 

        try
        {
            double change = (Change / Open) * 100; return change;
        }
        catch
        {
            return double.NaN;
        }
    }
}

In this case, it is important to remember to trigger the property change event for ChangePercent too when the values it depends on change… Now for the implementation of the FetchDataCallback. This method will be called by a background thread to update the stock data. Since this method is called by a background thread we’re free to perform expensive operations, such as calling a web service to fetch the stock’s data from an online provider (like Yahoo).

private void FetchDataCallback(object state)
{
    string fetchedName;
    double fetchedQuote;
    double fetchedChange;
    double fetchedOpen;

    if (_quoteProvider.TryGetData(_symbol, out fetchedName, out fetchedQuote, out fetchedChange, out fetchedOpen))
    {
        this.Dispatcher.BeginInvoke(
            DispatcherPriority.ApplicationIdle,
            new ThreadStart(
                delegate
                {
                    this.Name = fetchedName;
                    this.Quote = fetchedQuote;
                    this.Change = fetchedChange;
                    this.Open = fetchedOpen;
                    this.State = DataModelState.Active;
                }));
    }
    else
    {
        this.Dispatcher.BeginInvoke(
            DispatcherPriority.ApplicationIdle,
            new ThreadStart(
                delegate
                {
                    this.State = DataModelState.Invalid;
                }));
    }
}

On the previous post, on the WPF threading model overview we noted the following:

If only the creator of a DispatcherObject can access it, how can a background thread interact with the user? The background thread does not access the UI directly but it can ask the UI thread to perform a task on its behalf by registering work items to its Dispatcher using it’s Invoke (for a synchronous call that returns when the UI thread finished executing the delegate) or BeginInvoke methods (which runs asynchronously)

In the above code, after fetching the data on the _quoteProvider.TryGetData we need to communicate these changes back to the UI thread. We use the Dispatcher to set the new values for the DataModel properties which ensures that our property change events will be triggered on the UI thread.

Keeping the Data Alive

So far, our code only fetches the stock data once. Lets see what it takes make out DataModel keep its data alive.

protected override void OnEnabled()
{
    _timer = new DispatcherTimer(DispatcherPriority.Background);
    _timer.Interval = TimeSpan.FromMinutes(5);
    _timer.Tick += delegate { ScheduleUpdate(); };
    _timer.Start(); 

    ScheduleUpdate();
}
protected override void OnDisabled()
{
    _timer.Stop();
    _timer = null;
}
private void ScheduleUpdate()
{
    VerifyCalledOnUIThread();
    // Queue a work item to fetch the quote
    if (ThreadPool.QueueUserWorkItem(new WaitCallback(FetchDataCallback)))
    {
        this.State = DataModelState.Fetching;
    }
}

The above code defines a timer that is active when the DataModel is Enabled. The timer calls ScheduleUpdate every 5 minutes to perform the same data update using a background thread logic we performed on our constructor. We’re using a DispatcherTimer so that the calls to ScheduleUpdate will be made using the Dispatcher’s thread (the UI thread) so that we can update the DataModel’s state without a hassle. If we had used System.Threading.Timer then ScheduleUpdate would be called on the timer’s thread requiring the use of Dispatcher.BeginInvoke to update the state…

That’s it…

We’ve got the basic DataModel implemented. You can using it in you’re XAML window to see it working… To get a basic XAML running you’ll need to define a content control:

<ContentControl x:Name="_content" />

And set its content to a StockDataModel instance on your codebehind:

_content.Content = new StockDataModel("AAPL", someProvider);

Then all you need to do is define a data template for the StockDataModel type to control it’s appearance. Here’s a simple template for example:

<DataTemplate x:Name="StockTemplate" DataType="{x:Type local:StockDataModel}">    <StackPanel Orientation="Horizontal" mdb:EnableModel.DataModel="{Binding}" Height="30px" Width="Auto" ClipToBounds="True">       <TextBlock Text="{Binding Name}" Foreground="#737271" Width="120" Padding="3,0,0,3" Style="{StaticResource StockText}" />      <TextBlock Text="{Binding Quote}" Foreground="#737271" Width="55" Padding="0,0,0,3" Style="{StaticResource StockText}" />     </StackPanel> </DataTemplate> 

You can find the code discussed in this article plus my own implementation for an IStockDataProvider that reads stock data from Yahoo here: On the next post we’ll discuss DataModel unit testing and see how the StockDataModel tests are implemented.

Comments (5) imported from www.ekampf.com/blog/:

Sunday, March 30, 2008 10:45:52 PM (GMT Daylight Time, UTC+01:00)

Thanks for the series! Looking forward for the following parts. However, there’s a bug in the shown code as you cannot check if a value is NaN by comparing to double.NaN. You have to use double.IsNaN(…).

Use IsNaN to determine whether a value is not a number. It is not possible to determine whether a value is not a number by comparing it to another value equal to NaN.

Simon Monday, March 31, 2008 4:39:37 AM

(GMT Daylight Time, UTC+01:00)

Hey Simon, Thanks.

Fixing the code and the post…

Regards,
Eran

Eran Kampf

Friday, April 04, 2008 3:47:12 AM (GMT Daylight Time, UTC+01:00)

Very nice article series. Keep up the good work!

Kevin Kerr

Wednesday, May 28, 2008 2:55:06 PM (GMT Daylight Time, UTC+01:00)

Really great series, very nicely done.

Question: Why call VerifyCalledOnUIThread() in the ScheduleUpdate method? Since you’re calling BeginInvoke on the dispatcher inside FetchDataCallback all should be well, right?

Mike

Thursday, May 29, 2008 11:41:31 AM (GMT Daylight Time, UTC+01:00)

Hi Mike,

  Good question. Notice that besides calling queuing a work item that calls FetchDataCallback, the ScheduleUpdate method also updates the model’s State to DataModelState.Fetching when that work item is queued. Since we’re changing the actual model we need to make sure we’re doing it in the UI thread. Alternatively, we could have used a System.Threading.Timer to do the updates ScheduleUpdate() will be called on a background thread directly, but then we couldn’t set the model state to fetching. We’d have to send that back to the UI thread.

Regards,
Eran Kampf

Eran Kampf

Tags: Data Model, Metadata Driver User Interface, MVC, Patterns, WPF

In the first post in the series I gave an overview of the pattern we’ll be using.
This post will go deeper into the DataModel, as defined in the previous post:

The DataModel is defined exactly as the Model in MVC; it is the data or business logic that stores the state and does processing of the problem domain.
The DataModel abstracts expensive operations such as data fetching without blocking the UI thread. It can keep data “alive” fetching it periodically from source (example: stock ticket), merge information from several sources etc.
The DataModel is completely UI independent and pretty much straightforward to unit test.

The DataModel exposes data in a way that makes it easily consumable by WPF. As such, all if its public APIs, called by WPF for data-biding, must be called on the UI thread only. It must not block the UI thread because we want a robust functional UI so it usually performs operations on a background thread using the Dispatcher to send results back to the UI thread.

Therefore, the simplest DataModel implementation exposes several public Properties that expose data, implements INotifyPropertyChanged and/or INotifyCollectionChanged, and it abstracts the way information is fetched (using background threads to avoid blocking the UI thread when fetching the data is an expensive operation).

For two-way binding a commit and rollback mechanism, a dirty flag, etc.  We’ll get to that later on…

As the DataModel implementation needs to abstract expensive data fetching operations and work with multiple threads we need some basic understanding of WPF’s threading model before we look at the DataModel implementation…

WPF Threading Model - A Quick Overview

A typical WPF uses two threads:

• Rendering thread - runs in the background and handles rendering
• UI thread - Receive inputs, handles events, paints the screen and runs application code.

The UI thread queues work items in a Dispatcher object. The Dispatcher object selects work items on a priority basis and runs each one to completion.
Every UI thread must have at least one Dispatcher, and each Dispatcher can only use one thread to execute work items.

Therefore, in order to build responsive UI that doesn’t block the UI thread, the application has to maximize the Dispatcher’s throughput by keeping work items small as to minimize the time the Dispatcher spends on processing them - which keeps other work items waiting causing the UI to lag.

In order to perform expensive operations without blocking the UI thread we can use a separate thread that will run in the background, leaving the UI thread free to process items in the Dispatcher queue. When the background thread is done processing it can report results back to the UI thread for display.
Doing this isn’t trivial as Windows only allows UI elements to be accessed by the thread that created them. This means that the background thread we used for some long-running task cannot access and update our UI when it is finished (or during work to show progress) - a background thread updating a control (such as a list box) during its rendering can cause strange UI behaviors that this limitation is there to prevent.

WPF uses the following design to enforce this kind of coordination between the UI thread and other threads:
Most of the classes in WPF derive from DispatcherObject. During construction, a DispatcherObject stores a reference to the Dispatcher linked with the current running thread - creating an association between itself and the thread that created it.
At the beginning of every method in the DispatcherObject, it calls VerifyAccess which compares the Dispatcher associated with the current thread with the Dispatcher stored during the object’s construction - if they do not match it throws an exception.

If only the creator of a DispatcherObject can access it, how can a background thread interact with the user?
The background thread does not access the UI directly but it can ask the UI thread to perform a task on its behalf by registering work items to its Dispatcher using it’s Invoke (for a synchronous call that returns when the UI thread finished executing the delegate) or BeginInvoke methods (which runs asynchronously)

The DataModel Class

So now, after the brief discussion on the use of the Dispatcher we can start coding our base DataModel class.
We’ll start with the simple class and constructor definition:

public abstract class DataModel : DispatcherObject, INotifyPropertyChanged
{
    public DataModel()
    {
    }

We’re deriving from DispatcherObject because we need to have the Dispatcher available so that we can run background jobs that dispatch results to the UI thread.

As discussed earlier, each call to the DataModel should be made on the UI thread. Therefore we would like to enforce that limitation at the beginning of each publicly exposed API. The DispatcherObject class that we derived from contains a VerifyAccess() method that does just that. The method is public but unfortunately marked with the [EditorBrowsable(EditorBrowsableState.Never)] attributes which will make it hard to find for developers using driving their data model from our class.

To resolve this I simply defined a protected method as follows:

/// <summary>
/// Makes sure the call is in the correct thread (the UI thread) by comparing the current dispatcher
/// object with the dispatcher we got when the DataModel was created.
/// </summary>
[System.Diagnostics.Conditional("Debug")]
protected void VerifyCalledOnUIThread()
{
    this.VerifyAccess();
}

This method will be visible to anyone deriving from our class and it simply calls VerifyAccess to make sure code is made from the UI thread.
The Conditional attribute makes this code execute only in debug bits avoiding this kind of assertion on retail bits - some performance gain.

In order to support asynchronous data fetching the DataModel should encapsulate the information about its state - valid (data fetched), invalid (error fetching data), fetching (processing).

public enum DataModelState
{
    /// <summary>
    /// The model is fetching data
    /// </summary>
    Fetching,
    /// <summary>
    /// The model is in an invalid state
    /// </summary>
    Invalid,
    /// <summary>
    /// The model has fetched its data
    /// </summary>
    Active
}

The data model’s state is exposed using a property:

public DataModelState State
{
    get
    {
        VerifyCalledOnUIThread();
        return _state;
    }
    set
    {
        VerifyCalledOnUIThread();
        if (value != _state)
        {
            _state = value;
            OnPropertyChanged("State");
        }
    }
}

We also implement INotifyPropertyChanged to allow the model to communicate changes in its values.
Since adding\removing event handlers to the PropertyChanged event is a public API exposed by the DataModel, it also requires verification that calls to it are made from the UI thread. We’ll define our own add\remove handlers in order to perform this verification:

protected virtual void OnPropertyChanged(string propertyName)
{
    VerifyCalledOnUIThread();

    if (_propertyChangedEvent != null)
    {
        _propertyChangedEvent(this, new PropertyChangedEventArgs(propertyName));
    }
}

#region INotifyPropertyChanged Members
public event PropertyChangedEventHandler PropertyChanged
{
    add
    {
        VerifyCalledOnUIThread();
        _propertyChangedEvent += value;
    }
    remove
    {
        VerifyCalledOnUIThread();
        _propertyChangedEvent -= value;
    }
}
#endregion

Any property that we’ll add to our data model will call OnPropertyChanged on its setter in order to notify it has changed.

It’s Alive!

One more ability we’d like to add to our DataModel class is the ability to enable\disable it.
As defined earlier, the DataModel encapsulates the logic of fetching data and keeping it “alive” and up to date. To do that, it’ll need to keep some internal timer for updating information or register to some change notification event on its source.
This will keep the DataModel alive and can result in memory leaks, which is why we need some way to turn the DataModel on and off, allowing it to unregister from its data sources when that connection is no longer required:

public bool Enabled
{
    get
    {
        VerifyCalledOnUIThread();
        return _isEnabled;
    }
    set
    {
        VerifyCalledOnUIThread();
        if (value != _isEnabled)
        {
            _isEnabled = value;
            OnPropertyChanged("Enabled");
        }
    }
}

public void Enable()
{
    VerifyCalledOnUIThread();

    if (!_isEnabled)
    {
        this.Enabled = true;
        OnEnabled();
    }
}

public void Disable()
{
    VerifyCalledOnUIThread();

    if (_isEnabled)
    {
        this.Enabled = false;
        OnDisabled();
    }
}

protected virtual void OnEnabled()
{
}
protected virtual void OnDisabled()
{
}

When binding UI elements to the DataModel we’ll need some mechanism to enable the DataModel when the element is loaded and disable it when the element is unloaded. There’s an elegant way to implement this behavior which we’ll implement in a future post.

That’s it! We’ve got a basic class to derive out data models from. Note that we’re only addressing one-way data binding for the moment. We’ll address a two-way data model (which requires the ability to commit\rollback data etc.) in future post.

On the next post we’ll look into a concrete DataModel implementation for our Stocky application.

You can download the code for this post from here:

 

Further Reading

• WPF Threading Model -  http://msdn2.microsoft.com/en-us/library/ms741870.aspx

Tags: Data Model, Metadata Driven User Interface, MVC, Patterns, WPF

WPF, Microsoft’s not-so-new-anymore UI technology offers new capabilities allowing both developers and designers to work together to achieve a stunning experience for their applications.

Power, however, does not come without complexity, and WPF does not provide a framework or a model to solve many of the problems faced by developers and designer when building an application:

1. Handling Rich Data Forms. Many applications, especially when it comes to enterprise applications, rely heavily on displaying and manipulating data. Fetching the data while keeping the UI alive and responsive is a complicated task that’s also hard to debug and requires an experienced developer doing the work.
Can we come up with a framework that will simplify data fetching?

2. Testability is a Requirement for Software Development Framework. Development organizations are no longer satisfied with simple reduction of costs for initial development and there’s a growing demand for frameworks and tool to facilitate a sustainable and agile development process.
Can we come up with a model that will allow writing tests for the application’s UI and behavior?

3. Metadata Driven User-Interface. WPF provides XAML as a meta-model for UI definitions. However there is no clear separation between metadata and code which is a mess when it comes to designer and developers working together.
Can we come up with a model to allow developers provide all the UI logic as closed building blocks that designer can just use in a plug-and-play manner?

Providing a Framework for Building Robust, Data-Driven UIs

The Model\View\Controller (MVC) architectural pattern has long been used by complex applications to present large amount of data to the user.
The pattern allows developers to separate the actual data (Model) from the user interface (View) and the business logic manipulating the data (Controller).

In the following set of articles I will present a variation of the MVC pattern tailored for modern UI development (in WPF) where we’d like the View to be the responsibility of a designer rather than a classic developer writing code.

I’ll be using the DataModel\ViewModel\View terminology to describe the pattern (although you may find the same pattern described using various other terminologies when browsing the net).

Introducing the DataModel\ViewModel\View Pattern

As mentioned earlier, the DataModel\ViewModel\View pattern is a variation of the MVC pattern. Its focus is on making the View, which is the actual UI presented to the user, the responsibility of a designer - a person who is generally more oriented towards graphics, art and interaction than to classic coding.

The design of the view should be done in a declarative form (XAML) using a WYSIWYG tool (Expression Blend).
In short, the actual UI is developed using different tools and languages by a person with a different skills set than business logic and data backend.

In order to understand the meaning behind the DataModel\ViewModel\View terminology lets look at the following diagram describing
typical architecture for our application’s presentation using this pattern:

The DataModel

The DataModel is defined exactly as the Model in MVC; it is the data or business logic that stores the state and does processing of the problem domain.
The DataModel abstracts expensive operations such as data fetching without blocking the UI thread. It can keep data “alive” fetching it periodically from source (example: stock ticket), merge information from several sources etc.
The DataModel is completely UI independent and pretty much straightforward to unit test.

The View

The View consists of visual elements and represents the actual user interface presented to the users (buttons, windows, graphics, etc.). It also defines interaction for keyboard shortcuts and other input devices .

The View is defined declaratively in XAML by the designer (usually using a tool such as Expression Blend).
Using such a declarative model makes it to harder to represent some state that the original  View from the MVC pattern was meant to deal with - this includes dealing with multiple modes of interaction (such as “view mode” and “edit mode”) that change the visuals and behavior of the controls.

This is where we make use of WPF’s advanced data binding mechanism. In a simple scenario we can simply bind the View to the DataModel and use binding expressions to perform one-way binding for display only values or two-way binding to allow editing values in the DataModel.

In most scenarios, however, only a small subset of the application’s UI can be bounded directly to the DataModel. This can be the case when the DataModel is a pre-existing class or data schema over which the application developer has no control. The values exposed by the DataModel are likely to require some processing in order to allow binding to UI elements. There may also be several complex operations that require code implementation and do not fit into the strict declarative-only definition for a View but are too application specific to be part of the DataModel (which we might not have control over).
We may also want to save some view state such as view mode (view\edit\etc.) or item selection etc.

To bridge this gap between the declarative View and the DataModel we define the ViewModel…

The ViewModel

The ViewModel bridges between the DataModel and the View and performs all the tasks mentioned in the previous paragraph.
The terms is meant to describe a “Model of a View” which basically means that the ViewModel abstracts all the behavior logic behind a specific screen (View) in the application.
The ViewModel include converters that can transform DataModel types into View types, Commands that can be executed the the View’s control and interact with the DataModel and general behaviors that can be attached to UI elements in the View.

Summary and Next Steps

The DataModel\ViewModel\View defines a simple yet powerful pattern allowing developers and designers to collaborate on building a robust, data-driver WPF UIs.

It allows separating the data layer from the view layer and the UI to support easier development of granular components that are also unit-testable.

To demonstrate how the various pattern components are developed and used we’ll be going over the development process of a stock ticker widget-like application dubbed Stocky (screenshot on the right) and see how this development pattern simplifies the creation of an otherwise quite complicated little application.

References:

• Dan Crevier’s series on data binding
• MCV at Wikipedia - http://en.wikipedia.org/wiki/Model-view-controller

Comments (6) from www.ekampf.com/blog/:

Tuesday, March 18, 2008 4:09:58 PM (GMT Standard Time, UTC+00:00)

In my company We developing a very big medical system with UI based on WPF.
We used a combination of the Model-View-Presenter and the DataModel-View-ViewModel introduced by Den Crevier’s.
looking forward to see your implementation.

Ran Trifon

Tuesday, March 18, 2008 4:52:31 PM (GMT Standard Time, UTC+00:00)

Well it’s pretty much the same…
The goal here is to summarize all the information into one place. Dan’s post are pretty short and straightforwards aimed at experienced developers and these post are meant to be more detailed.
I am going to post about topics he didn’t mention though…

Eran Kampf

Tuesday, March 25, 2008 3:41:31 PM (GMT Standard Time, UTC+00:00)

Nice post - I’m really looking forward to seeing where you go with this. I’ve just recently being trying to find some guidance on setting up an MVC/MVP framework in WPF. Dan’s series is great but I must admit that I really didn’t understand it all until I began my own implementation and things began to “gel”. Will be great to see another perspective on it.

Nigel Spencer

Tuesday, March 25, 2008 3:53:55 PM (GMT Standard Time, UTC+00:00)

Thanks Nigel,
Next post in the series is already available at http://www.ekampf.com/blog/2008/03/24/DevelopingARobustDataDrivenUIUsingWPFTheDataModel.aspx

Eran Kampf

Tuesday, March 25, 2008 6:38:44 PM (GMT Standard Time, UTC+00:00)

Eran:
Just wanted to say “keep up the good work”. between your work and Dan’s series of articles, I think I’m starting to get a handle on this. My one request is that I’d like to see how your DataModel interacts with the DataAccess Layer against SQL Server. Maybe just something against Northwind. I realize this might be outside the main scope but I think it would be interesting.
Sincerely,
Dale Williams

Dale Williams

Tuesday, March 25, 2008 7:34:38 PM (GMT Standard Time, UTC+00:00)

Hey Dale,
Thanks for the feedback
The 3rd post in the series will show a concrete DataModel example.
Since I was aiming to show how I build a Yahoo finance widget clone I was building the DataModel on that - keeping a stock data up to date (kind of like in Dan’s article).
However, once you see how the DataModel fetching is implemented it doesn’t really matter if the actual data is fetched via SOAP call, http, or a DB access so you’ll be able to implement a one-way binding to a data source of your choice.
While the current implementation only deals with one-way binding (only fetching the data from the without the ability to update data on the source) I do plan to show how to implement two-way binding and support comitting and rolling back data in future posts.
Thanks,
Eran

Eran Kampf

Tags: Metadata Driven User Interface, MVC, Patterns, WPF

I wanted to build a screen saver and came across Karen’s template which is made for Visual Studio 2005 and .NET 3.0.
Since I’m on Visual Studio 2008 and .NET 3.5, I took Karen’s template and made some modifications to support it.

So, if you want to create a screen saver with Visual Studio 2008 here’s a template for you:

Installation Instructions

1. Download the zip file.
2. Copy the zip (do not extract) to <My Documents>\Visual Studio 2008\My Exported Templates

Tags: WPF

• Silverlight is pretty cool for doing interactive web apps.
  • I think they concentrated on Video too much on version one and I would have wanted the features in Silverlight 2.0 (WPF controls etc.) in 1.0 and video added later on. Comm’on, how many of us really set on developing another YouTube clone?
  • Leverages developers .NET and WPF knowledge for web apps. This is what I like most about Microsoft’s offering they have one basic platform that requires one set of basic skills which can later be applied to multiple platforms and kinds of applications.
• I hate the fact Silverlight 1.0 works with JavaScript codebehind.
• I hate JavaScript…

I think the most interesting session was Adam Kinney’s, who demonstrated the development process of his XBox Live! silverlight gadget. After getting some gamer tags from the audience and realizing that all would probably be offline as they’re in the event, one person had a “1 minute ago”… hmm…

And for other notes, as in any Microsoft event they have giveaways:

• I missed the Silverlight T-Shirts giveaway at the beginning of the event and when I came to the organizers later they sadly said that they  only have Small size shirts left. If you haven’t shopped for clothes in the US, size Small is pretty much like Large… and they usually don’t have Small… I was expecting an XXL size shirt and got a small which is just my size so I’m happy
• Microsoft Research were giving out cool bags for filling a form. By the time I filled the form they were out of bags and I got a “Microsoft Research” rubber ball :\
• I almost got a book at one of the lectures
• As usual, I didn’t win anything at the raffles (I never get lucky in raffles)

When I was leaving the Silverlight event there was some Zune marketing\analysts\team\?? meeting in the next room.
Microsoft are planning a PR effort on Zune for Mother’s day and Christmas focusing on the wifi capabilities which are Zune’s differentiator.

Not convinced. But to be fare, I don’t really like the new iPod video or the shuffle… Nothing like my good old iPod Shuffle.

Tags: Silverlight, WPF, Zune

In the Seattle area on November 29 and looking for something to do? Why not join a Silverlight workshop at Microsoft Redmond?

On November 29, 2007 Microsoft will be hosting Silverlight 1.0 Fire Starter on the Redmond, Washington campus. This daylong event is free to anyone who wants to learn about designing and developing with Microsoft Silverlight 1.0.

Don’t worry, if you can’t be there in person, I am told we are going to make all the material available on line after the event..

Microsoft Silverlight 1.0 is a cross platform browser plug-in that enables for easy development of media rich web sites.  For more information, visit http://silverlight.net.

November 29, 2007
Microsoft Redmond Campus
1 Microsoft Way
Redmond, WA
Building 33, Kodiak Room
** Please have a photo ID with you to register onsite and park

Check-in: 8:00 am
Event: 8:30 am – 5:00 pm
Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032359153&Culture=en-US
or by calling 1-877-673-8368 and referencing Event ID 1032359153

Check out the Facebook event page at http://www.facebook.com/event.php?eid=14189895595

I’m definitely going to try and make it…

(via Brad Adams’s blog)

Tags: Silverlight

 Came across this cool XBAP by Denis Dolfus:

Josh Smith ahs written a nuch of very comprehensive overview posts on WPF topics:

• Overview of routed events in WPF
• Overview of dependency properties in WPF
• Overview of attached properties in WPF
• A five-mile overview of WPF

Just came across this new WPF\Silverlight site - nibbles: snack tutorials for hungry designers.
As described on the site:

As the name suggests, nibbles are short tutorials that teach you one specific feature at a time. Later, you can combine all the things you have learned to develop a complex project by yourself.

There are already some tutorials about Expression Blend and Silverlight and content on Blend with WPF is expected soon. You can watch for new releases on the nibbles blog.

Two engineers from Microsoft Switzerland, Ronnie Saurenmann and Ruihua Jin, have put together this 90-page hands-on lab that takes you through the process of building a business application that has the same UI as Outlook 2007 using Expression Blend.
You can check out the xbap, read the hands-on-lab manual, or look at the source.

More details on this here:

• Tim Sneath
• Sascha P. Corti

It seems there’s a lot of new stuff about Acropolis from TechEd:

• Acropolis documentation is now online
• Forums
• Blogs
• Acropolis Team Blog
• Kathy Kam’s blog - PM on the Acropolis team
• Dennis “D.C.” Dietrich’s blog
• David Hill – Sr. PM\Architect on the Acropolis team
• Ricky Tan – Developer on the Acropolis team
• Walkthroughs:
• Walkthrough: Building an Acropolis Notepad Application
• Walkthrough: Building an Acropolis RSS Reader Application
• Media:
• Getting started with Acropolis Video

Acropolis sounds like a very promising new technology for smart-clients (unlike CAB which I hated).
I’ll try to drill more into this new framework in the near future…

Microsoft recently replaced the “WPF/E” codename with the name “Silverlight”.
I don’t get it… It sounds like the opposite to me…

While “Windows Presentation Foundation Everywhere” is a name that actually conveys some sort of a meaning. “Silverlight”, on the other hand, just don’t mean a thing…

What do you think?

Updates:

• I found this post by Josh who seems to agree with me.
• Joe Wilcox at Microsoft-Watch seems to disagree saying

Compared to the complex examples, Silverlight is seemingly genius and truly inspired—and it’s the right approach if Microsoft wants to go after Adobe’s Flash.

Microsoft used the National Association of Broadcasters conference this week to announce the new name for WPF/E - Silverlight.

I know there are some other pretty cool announcements on this topic waiting for MIX. Here’s a teaser from Tim Sneath:

I can’t reveal this yet - there’s a big surprise up our collective corporate sleeve that will be announced at MIX. I hate to hold back on you, but anticipation is part of the pleasure, as my mother used to tell me as a child when I was waiting impatiently for Christmas to come!

Read some more about Silverlight at

• Tim Sneath announcement
• Microsoft press release
• UX blog

The ScobleShow has done a very good video demo of Thirteen23’s amazing WPF apps:

These guys are doing some pretty awesome WPF stuff…

Tim Sneath is doing a series about great WPF applications. Check out his blog…