DarksideCookie

Building a template selector in Silverlight

chris@59north.com — Tue, 24 Jan 2012 12:59:53 +0100

There are several “missing” features in Silverlight that people keep bringing up, or keep trying to find solutions for. One of them is the template selector, or DataTemplateSelector class to be more specific.

The DataTemplateSelector has a single responsibility, which is the way it should be. It is responsible for returning a DataTemplate based an object. Generally, it is used in lists, where the data template can be selected based on the bound item, and thus give different templates to different kind of objects in the list.

In Silverlight, this is not possible out of the box, and instead requires us to create multiple UI controls, and hide and show them using data binding. This approach works, but it easily becomes heavy and complicated, which is why I want a template selector that works…

And I say “that works” as there are many solutions and options available out on the web, but none of them are that great, at least from the ones I have seen. Most of them use some form of IValueConverter, which looks fugly and quirky when written in the Xaml. And generally works poorly at design-time.

I wanted something cleaner… So I tried to solve it using attached properties instead of converters, making the whole thing a little cleaner from a Xaml point of view.

The goal is to put the DataTemplates in ResourceDictionary objects with some form of key. I then want to match that key to a value in the ViewModel, without having to implement some custom interface or something. And as the ResourceDictionary’s key is of type object, I can really use any kind of key I want, which makes the whole thing very flexible.

I also want the actual selection to work in 2 different ways. By default, I want it to walk up the control tree, looking at all resource dictionaries along the way, until a DataTemplate resource with the same key is found. But, I also want it to be possible to point out a specific ResourceDictionary and thus not spend CPU cycles on traversing the control tree.

So from this, I figured that I needed 2 attached properties, one called KeyPath and one called ResourceDictionary. With these two, I should be able to get the job done…

But before I go into code, I just want to mention that it is a bit complicated and hard to explain, so downloading the code and playing around with it might be a good idea… The code is available at the bottom of the post as usual… But a combination of looking at the code and reading the post is probably a good idea…

The attached properties are declared by a class called TemplateSelection, and are typed as string and ResourceDictionary…no surprises there…

For the KeyPath property, I declare a callback method to get notified when the value changes. In the callback, I do a somewhat ugly hack and verify that the control has an ItemTemplate property using reflection. I guess it would have been nicer to check for a property of type DataTemplate, but as far as I know, all the controls in Silverlight that use DataTemplate, do so using a property called ItemTemplate. If you need something else, just change it…

var prop = sender.GetType().GetProperty("ItemTemplate");
if (prop == null)
    throw new Exception();

Next I get a little creative… First off, I create a new Guid, which will be used to identify this specific control. I then generate a new DataTemplate containing a custom control called TemplateSelectorDisplayControl, passing it the Guid. I then store the control in a Dictionary<Guid, WeakReference>, using the newly created Guid as the key, before setting the ItemTemplate property of the control to the the newly created template.

var id = Guid.NewGuid();
var dt = XamlReader.Load(string.Format(DataTemplateFormatString, id));
_controlDictionary.Add(id, new WeakReference(sender));
 
prop.SetValue(sender, dt, null);

The DataTemplate is created from a string as you can see using the XamlReader class. The string used to create the template looks like this

<DataTemplate 
    xmlns=\"http://schemas.microsoft.com/winfx/2006/xaml/presentation\" 
    xmlns:ts=\"clr-namespace:TemplateSelector;assembly=TemplateSelector\">
    <ts:TemplateSelectorDisplayControl TemplateSelectorKey=\"{0}\" />
</DataTemplate>

As you can see, it defines a DataTemplate with a single control, which gets the Guid I created passed in through a property called TemplateSelectorKey… The TemplateSelectorKey property is of type string and not Guid as this was the easiest way to do it…

Ok, so that is part one…time to see what the TemplateSelectorDisplayControl does…

The TemplateSelectorDisplayControl is a custom control, that will make the “magic” happen. It has 2 dependency properties, one public called Content, which is used to bind its “content” to the ContentPresenter in the controls template, and one private called TemplateKey. The TemplateKey property is used to get the key from the ViewModel through binding. It obviously also has a string property called TemplateSelectorKey which is used to get the Guid from the TemplateSelection class as seen before…

That sounds awfully complicated, and it kind of is, but then again it isn’t…

In the ApplyTemplate method of the control, I get the KeyPath to use from the TemplateSelection class using the Guid. As the control I am working on has no knowledge of what parent control is being used, the Guid helps to identify the control and get the correct value. If the attached property KeyPath has not been set, I set the TemplateKey property to the type of the ViewModel being used instead. That way, if you want to, you can set the KeyPath property to an empty string to use the type of the VM as the ResourceDictionary key (not recommended…). Otherwise, I data bind the TemplateKey property using the KeyPath.

public override void OnApplyTemplate()
{
    base.OnApplyTemplate();

    var path = TemplateSelection.GetKeyPathById(Guid.Parse(TemplateSelectorKey));
    if (string.IsNullOrEmpty(path))
    {
        var key = DataContext.GetType();
        SetValue(TemplateKeyProperty, key);
        return;
    }
    SetBinding(TemplateKeyProperty, new Binding(path));
}

Ok, now that we got the key stuff handled, it is time to get the data template. This is done in the TemplateKey’s change callback method… The nice thing is that this will be called in both the cases above…it doesn’t matter if I use SetValue() or SetBinding(), the system will handle the everything and make sure the callback is called…

In the callback the actual value is available, and I don’t have to care if it has been set explicitly in the previous code or fetched from the ViewModel using a data binding.

Using the Guid and the key, I can once again ask the TemplateSelection class for the template (I will get back to how it does this later). If I get a DataTemplate back, I call its LoadContent() method to create the controls defined by it and then set the Content property to the returned value. The TemplateBinding defined in the control template will handle the rest… And if no DataTemplate is returned, I just set the Content property to the DataContext, causing the control to renter a TextBlock with the name of the DataContext type…

private void OnTemplateKeyChanged(DependencyPropertyChangedEventArgs args)
{
    var tc = TemplateSelection.GetTemplate(Guid.Parse(TemplateSelectorKey), args.NewValue);
    if (tc != null)
    {
        Content = tc.LoadContent();
        return;
    }
    Content = DataContext;
}

Ok, so what is happening in the GetTemplate() method? Well…a whole bunch…

First I check if the dictionary with WeakReferences to controls contains the supplied key. If not, I just return null (shouldn’t happen unless someone is messing with the code…), otherwise I get hold of the WeakReference and verify that it is still alive. If it isn’t, I once again return null…

Now, if I get this far, it is time to find the template. If the ResourceDictionary attached property has been set on the control, I look for a DataTemplate in the defined dictionary, otherwise I traverse the control tree looking for a data template with the correct key…

internal static DataTemplate GetTemplate(Guid id, object key)
{
    if (!_controlDictionary.ContainsKey(id))
        return null;

    var wr = _controlDictionary[id];
    if (!wr.IsAlive)
        return null;

    var dictionary = GetResourceDictionary((DependencyObject) wr.Target);
    if (dictionary != null)
    {
        return dictionary.Where(kvp => kvp.Key.Equals(key)).Select(kvp => kvp.Value).OfType<DataTemplate>().FirstOrDefault();
    }

    return GetTemplateFromResources(wr.Target, key);
}

And the traversal code looks like this

private static DataTemplate GetTemplateFromResources(object obj, object key)
{
    var fe = obj as FrameworkElement;
    if (fe != null)
    {
        var template = fe.Resources.Where(kvp => kvp.Key.Equals(key)).Select(kvp => kvp.Value).OfType<DataTemplate>().FirstOrDefault();
        if (template != null)
            return template;

        if (fe.Parent != null)
            return GetTemplateFromResources(fe.Parent, key);
    }
    return null;
}

Ok, that is actually all there is to it…hehe…yeah, I know, it isn’t the simplest code available…

Quick recap! The list control sets the KeyPath attached property. Setting this property causes the ItemTemplate property of the control to be set to a dynamically created DataTemplate that contains a single control called TemplateSelectorDisplayControl. The TemplateSelectorDisplayControl gets a Guid passed to it, which is used to identify what control it is being used for.

The TemplateSelectorDisplayControl then data binds its TemplateKey DependencyProperty property using the value of the KeyPath attached property. This makes it possible to read the value from the ViewModel without knowing anything about it or having it implement some special interface. Once the key has been retrieved using the binding, it, together with the Guid, is used to get hold of a template with the correct key.

And once it has the data template, it is used to create the content of the control…

That is a couple of really weird steps to get it working, but as soon as that is built, we can write the following Xaml

<UserControl.Resources>
    <DataTemplate x:Key="Test">
        <Grid Background="Yellow">
            <TextBlock Text="{Binding Message}" />
        </Grid>
    </DataTemplate>
</UserControl.Resources>
 
<Grid x:Name="LayoutRoot" Background="White">
    <ItemsControl local:TemplateSelection.KeyPath="Test">
        <ItemsControl.Resources>
            <DataTemplate x:Key="Test2">
                <Grid Background="Green">
                    <TextBlock Text="{Binding Message}" />
                </Grid>
            </DataTemplate>
        </ItemsControl.Resources>
        <ItemsControl.Items>
            <local:TestClass Test="Test" Message="Hello World" />
            <local:TestClass Test="Test2" Message="Hello World2" />
        </ItemsControl.Items>
    </ItemsControl>
</Grid>

Which will render a Yellow and a Green row with the text “Hello World” and “Hello World 2” inside.

Or, if you want to skip the control traversal, you can write

<ItemsControl local:TemplateSelection.KeyPath="Test" 
      local:TemplateSelection.ResourceDictionary="{Binding Resources, ElementName=ctrl}">

Which will make sure that only DataTemplates in the “ctrl” control’s Resources will be used, which in this case makes the green template fail and instead render the name of the DataContext type…

Unfortunately, the latter code does not work very well at design-time, but works fine at runtime… At design-time it seems to still use the traversal code, thus finding the template correctly. So to be honest, it works a little too well at design-time in this case…

That’s it! As the code is complicated, and my descriptions probably a bit lacking, I suggest having a play around with the code… If you find any issues please let me know so I can have a look at it. But so far, it seems to work for me…

Code: TemplateSelector.zip (47.92 kb)

Trying Out Azure Service Bus Relay Load Balancing

chris@59north.com — Mon, 09 Jan 2012 14:21:07 +0100

As you might have noticed from previous posts, I am somewhat interested in the Azure Service Bus. Why? Well, why not? To be honest, I don’t actually know exactly why, but I feel that it offers something very flexible out of the box, and without to much hassle.

One of the later feature that was added to it is the support for load balancing when using message relaying. (You can read more about message relaying here)

It is pretty cool, and just works… And by just works, I mean it really just works. If you have a service using message relaying today, adding another instance will automatically enable the feature. But remember, the messages are delivered to ONE of the services, not both. So if your service cannot handle that, make sure you change the implementation to make sure that only one instance is running at any time.

In previous versions of the bus, adding a second service would throw an exception, which is obviously not the case. So if you were depending on this to make sure only one instance was ever running, you will have to revisit that code and make some changes…

I have decided to crate a tiny sample to show off the feature… So let’s have a look!

I started by creating 3 projects, two console applications, and one class library. I think this would be the most common way to do it. Not using 2 console apps (!), but having a server project, a client project and a class library with the service contract.

Let’s start with the contract. I have decided to create one of those contracts that really shouldn’t ever exist, but still works for demos. It is called INullService and has a single method called DoNothing(), which takes no parameters, and returns void. Like this

[ServiceContract(Name="NullService", Namespace="http://chris.59north.com/azure/relaydemo")]
public interface INullService
{
    [OperationContract(IsOneWay = true)]
    void DoNothing();
}
 
public interface INullServiceChannel : INullService, IChannel { }

As you can see, the service contract is defined as an interface, which is the way it should be. Do not adorn classes with ServiceContractAttribute…

I have also marked the method as being one-way and added an extra interface extending the INullService interface by implementing IChannel as well… Just as I have done in previous demos…

Now that the contract is done, I will move to the server project. I start off by adding references to the class library project, Microsoft.ServiceBus and System.ServiceModel.

Actually I only add a reference to the ServiceBus assembly as it is the only one only being used from config, but if you don’t have ReSharper, it is easier to do it up front. With ReSharper, you can just type the name of the type you need, press Alt-Enter and select “Reference assembly…”. (Did I mention that I have started to like ReSharper a LOT?

Once the references have been added, I add a new class called NullService, which implements INullService in the most simple way possible

internal class NullService : INullService
{
    public void DoNothing()
    {
        Console.WriteLine("Doing nothing...");
    }
}

That’s all there is to the actual service. Next up is the Main method, inside which I start off by creating a new ServiceHost instance. I do this passing in a Type referring to the NullService class I just created, and getting the rest of the information needed from the app.config file by automagic. I then open the host, write a message to the screen and wait for a key to be pressed. Once the key is pressed, I close the host, and let the program close…

static void Main(string[] args)
{
    var host = new ServiceHost(typeof(NullService));

    host.Open();

    Console.WriteLine("Service listening at: " + host.Description.Endpoints.First().Address);
    Console.WriteLine("Press any key to exit...");
    Console.ReadKey();

    host.Close();
}

Once again, very simple! Unfortunately, there is as mentioned a bit of config to go with it. The config is however very standard, so I won’t cover it here, but it is available in the download at the bottom of the page…

Ok, server done, time to look at the client!

The client is a bit more complicated. I started out by creating a very simple client, unfortunately, it kept calling the same service instance all the time, which doesn’t really show off the load balancing very well. To get around this, I made it a bit more complicated by making sure that all the calls were being made in parallel using Tasks.

Let’s go through it one step at the time, once again leaving out the config…

The Main method just makes a single call to a method called ExecuteCallBatch(). The method is named like this because each time the method is run, it will call the service 50 times. Remember, we need a least a little load for this to work…

The ExecuteCallBatch() method starts by asking the user if he/she wants to use the same channel for all calls (and also if he/she wants to quit the application).

Console.Write("Do you want to keep the channel? (y/n/c) ");
 
var key = Console.ReadKey().Key;
 
if (key == ConsoleKey.C)
    return;
 
var keepChannel = Console.ReadKey().Key == ConsoleKey.Y;

Ok, now we know that the users wants to go on, and whether or not he/she wants to keep the channel alive for all calls.

Next I create a couple of variables, one Task variable, and one INullServiceChannel, and if the channel should be kept alive, I set the channel variable to a channel.

var channel = keepChannel ? GetNewChannel() : null;
Task t = null;

The GetNewChannel() method really just instantiates a new channel using a ChannelFactory<> and opens it

private static INullServiceChannel GetNewChannel()
{
    var channel = new ChannelFactory<INullServiceChannel>("RelayEndpoint").CreateChannel();
    channel.Open();
    return channel;
}

Now that I have the variables I need, it is time to create the loop that calls the service. All it does is that it creates a new Task, passing in an anonymous method, and starts it. The anonymous method is responsible for calling the service. It also checks whether or not the channel should be re-used. If not, it creates its own channel, which it also closes when done.

for (int i = 0; i < 50; i++)
{
    t = new Task(() =>
    {
        var c = channel;
        if (!keepChannel)
            c = GetNewChannel();
 
        c.DoNothing();
 
        if (!keepChannel)
            c.Close();
    });
    t.Start();
}

The reason that I keep a reference to the Task, is that at the end of the loop, I use that reference to wait for the last Task to complete before carrying on.

The way I do it in this sample isn’t the best idea, as it assumes that the last Task to be created, will also be the last one to finish. This isn’t necessarily true, but for this demo it is an assumption I can live with. The app might crash if I am unlucky, but it is unlikely enough for me to ignore…

Once the last Task has finished, I close the channel if it has been kept throughout the call batch, and then finally call ExecuteCallBatch() again, causing a loop that can only be stopped by pressing “c” at he prompt.

t.Wait();
 
if (keepChannel)
    channel.Close();
 
ExecuteCallBatch();

Ok, that is all there is to it. To try it out, I start 2 or 3 instances of the server application, and let them all connect and get up and running before I start the client. I then let the client run a couple of batches, looking at the nice little printouts I get in all of the server windows, proving the that the calls are being nicely load balanced…

If you run through the demo a couple of times, varying between keeping the same channel and not, you will see that the result is the same. The messages are being load balanced in both scenarios, which I assume means that utilizing sessions in the services might cause some problems. But I still haven’t looked into this so I might be wrong… Feel free to tell me if you know!

That was it for this time!

Download code here: DarksideCookie.Azure.ServiceBusDemo.zip (142.84 kb)

Encryption is not everything

chris@59north.com — Wed, 04 Jan 2012 14:48:54 +0100

Sorry, for the cryptic title for this post, but it is sort of true, at least when it comes to client access policies. And I didn’t know it until a couple of days ago…

As a part of a project I am working on, we are deploying an STS (Secure Token Service) to handle authentication the users of an OOB Silverlight application. The STS is completely decoupled from the application, as it should be, and is hosted on its own, and the client requests a token from the service through a simple HTTP GET with basic authentication.

As we all know, unless you are using an OOB app with elevated permissions, we need to use a client access policy file when doing cross domain calls. So, I added a clientaccesspolicy.xml file to the STS, with the following content

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

This is a standard policy file that allows EVERYTHING. It allows requests from any address with any header, and does it for all paths… That is pretty bloody open if you ask me.

After having added the policy file, I fired up the client and logged in, and everything worked fin.

And then a couple of days later, I try to logging in, but I get a SecurityException… What!?

Ok, Fiddler to the rescue… But Fiddler didn’t show anything. It showed nothing at all to be honest…just as it does when you connect using SSL. A feature that a colleague of mine had added to the STS the day before.

After telling Fiddler to inspect SSL connections, I could tell that the policy was being downloaded properly, but the client still said that something was wrong.

Slightly confused, I Googled the problem and came across this, a very boring page about network security in Silverlight, which I guess is where I should have started before even Googling it. On the network security page, there is a table that says HTTPS-hosted Silverlight applications can access both secured and unsecured resources if the policy file uses a <domain /> element with the uri attribute set to *. You will also find a table saying that an HTTP hosted client is allowed to access unsecure resources, but not secured resources if the uri attribute is set to *. Instead, an HTTP hosted client requires the attribute to be explicitly set to “http://*” if the resource is hosted on HTTPS.

So to get this working for both secured and non-secured clients, the policy-file has to explicitly allow both types. Like this

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="http://*"/>
        <domain uri="https://*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

In this case, I’m talking about an OOB application, which means that it is actually hosted using the “file://” scheme. So I guess that means that Silverlight considers “file://” being the same as HTTP, which makes sense I guess. It would have been nice if the documentation mentioned this though…

That’s all for this time…

(I finally managed to write a “short” post…)

Exposing and consuming REST-based APIs with WCF WebApi and Silverlight

chris@59north.com — Wed, 21 Dec 2011 14:52:36 +0100

There are many ways to expose functionality and data from a server to a client. And there is probably almost as many going the other way… In Microsoft scenarios, using WCF is the obvious choice for most of us, and when people talk WCF, they generally talk SOAP based webservices.

SOAP can however be a less than ideal choice in a some cases. It is way more complicated than some of the other options, and on top of that it has a tendency to bloat the messages being sent, which can be an issue when working with mobile clients for example.

REST on the other hand is a pretty neat way of doing it. It uses open HTTP standards, making it available to all types of clients, even through a browser if needed. It is also very lightweight as the request and response are stripped down to the bare essentials, and can be made even smaller by using Json. And if you don’t like Json, you can still just use POX (plain old xml).

The only downside to using REST is the fact that we generally don’t get a nice proxy that serialize and de-serialize the data for us, and tells ut what methods are available. Instead we have to handle all of that manually, which can be cumbersome.

The goal for this post is to show how easily we can expose, and consume, REST in a simple and structured way using WCF WebApi and in this case Silverlight. The Silverlight end can of course be any .NET-based client…

The first thing needed to get this going is to install the “Portable Class Libraries” VS extension from http://msdn.microsoft.com/en-us/library/gg597391.aspx. It is an extension to Visual Studio 2010 SP1 that makes it possible to create library projects that can be used in different platforms such as Silverlight, .NET and XNA without having to create a separate project for each platform. The only limitation is that you can only use namespaces available in all the platforms, which means a lot fewer than you would get if you had the whole framework. It is however more than enough to create DTO (Data Transfer Object) classes, which is exactly what I am going to do here…

Once that is installed, I start up a new Silverlight Application project in Visual Studio. I also let VS create a new ASP.NET MVC project to host it. It is important to use an MVC project, otherwise you will have to make some changes to the Web Application to support Url routing… At least I think so…

Once the 2 projects have been created, I create a new Portable Class Library project, which is the new project type created by the previous install.

Inside the PCL project, I create the DTO:s I need. For this demo, that means one class called called AddUserCommand, one called UpdateUserCommand and one called User. The commands are sent from the client to tell the server to do something, and the User class is used to transfer the data about a User from the server to the client…

They look like this

public class AddUserCommand
{
    public string Name { get; set; }
    public string Email { get; set; }
    public int Age { get; set; }
}

public class UpdateUserCommand
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public int Age { get; set; }
}

public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public int Age { get; set; }
}

And no, they aren’t brilliant in any way. They aren’t even that well thought through, but they will do for this demo…

Once the DTO:s have been created, I add a reference to the PCL project from both my Silverlight application and my MVC application.

Next I want to create the REST API that the client will consume. For this, I use WCF WebApi, which makes this really easy.

Installing WebApi is easily done through NuGet, just search for WebApi in the NuGet Package Manager. WebApi will also install the HttpClient NuGet package. Unfortunately, this package isn’t available in Silverlight…but I will get back to that…

As soon as the WebApi NuGet package is installed, I create a new class called Service in my MVC project, and put it in a folder called Api, but you are free to name it whatever you want and place it wherever you want… The name and location isn’t important. What is important is that I adorn the class with a ServiceContractAttribute like this

[ServiceContract]
public class Service
{
    // TODO: Implement
}

But before I go and create the implementation of the service, I open the Global.asax.cs file and add the following to the RegisterRoutes() method

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
 
// Added code
routes.Add(new ServiceRoute("api", new HttpServiceHostFactory(), typeof(Api.Service)));
// End of added code
 
routes.MapRoute(
    "Default", // Route name
    "{controller}/{action}/{id}", // URL with parameters
    new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
);

This extra added route makes sure that all calls coming to “/api” will be routed to the service I just created. It is also possible to configure WebApi to enable a built-in “test client” that enables you to call methods on in the API from the browser in a simple way for debugging and things. But this is outside the scope of this post.

Now that I got the route set up, I can go back to the Service.cs file and add the required functionality.

As you might have understood from the names of the commands I created in the PCL project, I will be adding, updating and getting users from the service. However, in this demo, there will be no database or anything, instead I will just store the users in a dictionary. You will just have to imagine the database…

I start with the “get” method, which is easy to implement. I create a new method called GetUser, that takes an int called id and returns an instance of HttpContent. I then adorn it with a WebGetAttribute, setting the UriTemplate to “user/{id}”, like this

[ServiceContract]
public class Service
{
    private static Dictionary<int, User> _users = new Dictionary<int, User>();
 
    [WebGet(UriTemplate = "user/{id}")]
    public HttpContent GetUser(int id)
    {
        // TODO: Implement
    }
}

If you have done ASP.NET MVC development, you will recognize format of the UriTemplate. If you haven’t, all you need to know is that it defines what paths the method will handle, and by adding curly-brace-enclosed parameters, you can read out parts of the path and get it sent to the method as parameters. In this case, anything added after “/api/user/” will be considered a user id and has to be possible to parse to an int.

The actual implementation of the method is just as simple as you would expect. It reads the user from the dictionary and returns it wrapped in a class inheriting from HttpContent called ObjectContent. But I also want to make sure that I provide a good RESTful API and return a 404 if there is no user with the specified id. Figuring out whether or not there is a user with the specified id is easy, but the question is how you return a 404. Luckily, that is easy, just throw a new HttpResponseException, passing a HttpStatusCode value to the constructor. So the actual implementation looks like this

[WebGet(UriTemplate = "user/{id}")]
public HttpContent GetUser(int id)
{
    if (!_users.ContainsKey(id))
        throw new HttpResponseException(HttpStatusCode.NotFound);

    return new ObjectContent(typeof(User), _users[id], "application/json");
}

The ObjectContent object makes sure that the object is serialized correctly. In this case I tell it specifically that I want Json. Otherwise it creates XML by default…

You could change the method to return a User object straight up. The reason I am not doing that in this case has to do with Silverlight, but won’t be shown in this post. But here is the reason… Silverlight only gets a 404 whenever something goes wrong on the client. To solve this I generally have an “envelope” message that is passed back from method. The “envelope” contains an error code. So instead of using the proper RESTful way, and sending status codes, I send a proper 200 result all the time, but include the error in the message.

If you aren’t using Silverlight, or communicate in a way that accepts other status codes, I suggest just returning a User object…

The add and update methods are pretty much the same. The only real difference is that I add a WebInvokeAttribute instead of a WebGetAttribute. WebInvoke is used when you want to use HTTP PUT or POST instead of GET. Unfortunately there are some problems with using PUT in Silverlight, so I defined them both to use POST, but with different Uri:s.

[WebInvoke(UriTemplate = "user/add", Method = "POST")]
public HttpContent AddUser(AddUserCommand cmd)
{
    var user = new User
                    {
                        Id = _users.Count + 1,
                        Name = cmd.Name,
                        Email = cmd.Email,
                        Age = cmd.Age
                    };
    _users.Add(user.Id, user);

    return new ObjectContent(typeof(User), user, "application/json");
}

[WebInvoke(UriTemplate = "user/update", Method = "POST")]
public HttpContent UpdateUser(UpdateUserCommand cmd)
{
    if (!_users.ContainsKey(cmd.Id))
        throw new HttpResponseException(HttpStatusCode.NotFound);

    var user = _users[cmd.Id];
    user.Name = cmd.Name;
    user.Email = cmd.Email;
    user.Age = cmd.Age;

    return new ObjectContent(typeof(User), user, "application/json");
}

Well, there is one more difference. The parameter sent to the method is not part of the Uri as it is a post, instead I just declare the type I want as a parameter and WebApi automatically maps the posted data just like MVC does for you. And in this case, the parameters come from the PCL created previously, which will also be used on the client side.

Now that the server side is done, it is time to look at the Silverlight client.

As mentioned previously, there is no implementation of the HttpClient for Silverlight, so I will have to build something useful on my own. It just happens the be fairly simple though… But first I need another NuGet package. This time it is Json.NET that needs to be added to the Silverlight project. Once that is done, I can go on and build my own HttpClient, which I call RestClient for some reason…

The RestClient class will take a “base url” to the service in the constructor, and expose a generic Get and Post method that will be responsible for getting objects from the service, as well as send objects to it. When doing this, it takes the path to the method as a parameter, as well as an instance of the object to send.

The base of the RestClient looks like this

public class RestClient
{
    private readonly Uri _baseAddress;
 
    public RestClient(string baseAddress)
    {
        _baseAddress = new Uri(baseAddress);
    }

    public void Get<T>(string commandPath, Action<Exception, T> callback)
    { 
        var client = new WebClient();
        client.Headers[HttpRequestHeader.Accept] = "application/json";
 
        DownloadStringCompletedEventHandler handler = null;
        handler = (s, e) =>
        {
            client.DownloadStringCompleted -= handler;
            if (e.Error != null)
            {
                callback(e.Error, default(T));
                return;
            }

            var result = Deserialize<T>(new StringReader(e.Result));
            callback(null, result);
        };
        client.DownloadStringCompleted += handler;
        client.DownloadStringAsync(new Uri(_baseAddress, commandPath));
    }
 
    public void Post<T>(string commandPath, object data, Action<Exception, T> callback)
    {
        var synchContext = System.Threading.SynchronizationContext.Current;
 
        var request = WebRequest.Create(new Uri(_baseAddress, commandPath));
        request.Method = "POST";
        request.ContentType = "application/json";
 
        request.BeginGetRequestStream(iar =>
        {
            var reqStr = request.EndGetRequestStream(iar);

            SerializeObject(data, reqStr);

            request.BeginGetResponse(iar2 =>
            {
                WebResponse response;
                try
                {
                    response = request.EndGetResponse(iar2);
                }
                catch (Exception ex)
                {
                    synchContext.Post((state) => callback((Exception)state, default(T)), ex);
                    return;
                }
                var result = Deserialize<T>(new StreamReader(response.GetResponseStream()));
                synchContext.Post((state) => callback(null, (T)state), result);

            }, null);
        }, null);
    }
    // Serialization...
}

That was a LOT of code…I know…but it is fairly basic. It uses a WebClient to get a string from the server in the GET scenario, and a WebRequest when posting data to the server. The only 2 non-standard things are the serialization and deserialization of the objects being sent and received, as well as the fact that I store the SynchronizationContext in the post scenario to make sure I make the callback on the same thread as I started the post…

The serialization and de-serialization is ridiculously simple using Json.NET. The methods look like this

private static void SerializeObject(object data, Stream stream)
{
    var serializer = new JsonSerializer();
    var sw = new StreamWriter(stream);
    serializer.Serialize(sw, data);
    sw.Flush();
    sw.Close();
}
 
private static T Deserialize<T>(TextReader reader)
{
    var serializer = new JsonSerializer();
    return serializer.Deserialize<T>(new JsonTextReader(reader));
}

As soon as the RestClient is built, I can build a simple UI to take the required input.

As this UI is ugly and simple, I won’t cover the actual UI and let you look at it in the download instead. But I will cover the ViewModels quickly…

The CreateUserViewModel exposes Name, Email and Age as public properties that are bound using TwoWay bindings. It also exposes an ICommand that does the actual creation by creating a new AddUserCommand, populate its properties and send it to the server using the RestClient’s Post method.

var cmd = new AddUserCommand {Name = Name, Email = Email, Age = Age};
var client = new RestClient(GetServiceUrl());
client.Post<User>("api/user/add", cmd, (ex, user) =>
{
    if (ex != null)
        return;

    NavigateToNextPage()
});

As you can see, using the RestClient makes using RESTful APIs a breeze. You don’t have to care about serialization and stuff like that. Both the server and client can work with “real” objects and just ignore the whole transport part…

On the other page, “edit page”, I use the RestClient once again to get the User to edit, as well as to post the changes back to the server. Getting the user is really simple as well

int userId = GetUserId();
var c = new RestClient(GetServiceUrl());
c.Get<User>("api/user/" + userId, (ex, user) =>
{
    if (ex != null)
        return;

    _user = user;
    OnPropertyChanged(string.Empty);
});

That’s it! The only thing I want to mention is one more neat thing that a lot of people have seemed to have missed. That is the method called GetComponents() on the Uri class. It makes it really easy to get only the parts you need from a full Uri without having to do a bunch of string manipulation. Just tell it what parts you need using an enumeration called UriComponents. And since the UriComponents enumeration is a flags enum, you can just combine the values how you want. In this case, I need the scheme, server and port to get the host Url. Using GetComponents() that looks like this

Application.Current.Host.Source.GetComponents(UriComponents.SchemeAndServer, UriFormat.Unescaped)

Previously I would have done something ugly like

var host = new Uri(Application.Current.Host.Source.ToString().Replace(Application.Current.Host.Source.LocalPath.ToString(), ""));

Or at least something similar. And it works, but it is really ugly…

That was it for this time! I really hope that this will help some of you getting started with RESTful APIs in Silverlight. It is really not that hard, and it makes for a really open and friendly API. Not to mention that it is easy to “debug” by just browsing to it…either by browsing to “Get methods” or by using the built-in test client in WebApi…

Code is obviously available for download: DaksideCookie.Ag.RestDemo.zip (4.95 mb)

Sorry for the large download. It is all the NuGet stuff. But I didn’t want to remove that and leave a half-working app…

That’s all folks! Cheers!

SignalR and Silverlight

chris@59north.com — Thu, 15 Dec 2011 20:53:10 +0100

SignalR is a somewhat newish open source project that makes it possible to simulate push notifications on the web. It does so using long-polling (websockets available as an extra download), so it isn’t true push as such, but it gives the appearance of push. And on top of that, it is so ridiculously simple to set up…

Unfortunately, the NuGet package for SignalR doesn’t include the Silverlight client, which the GitHub project does. This is most likely going to be fixed in the near future, but currently you will have to do it the manual way instead of using NuGet.

The server part of SignalR works fine through NuGet, however, it doesn’t play nice with the Silverlight version as a property has been renamed and causes issues. So we have to do the whole thing manually to make sure both the client and server has the modified property… Once again, it is probably going to be fixed some time really soon.

So let’s start off by running off to GitHub and getting the source. The address is https://github.com/SignalR/SignalR. As soon as that is done, run the build.cmd command file to build the application. This causes some red warnings during the build, but it still seems to work fine.

Next we need to set up a solution of our own to try it out, so start up VS and create a new Silverlight Application project, and host it in a ASP.NET MVC application. As soon as these projects are up and running, it is time to add all the necessary resources.

Let’s start with the Web application. The first thing we need here is of course the SignalR assemblies that we just built, as well as some supporting assemblies. These are easily copied from the newly built SignalR solution. Copy the 3 dll files that you find under /SignalR/bin/Release somwhere good, and then add a reference to them from your web application.

If you want to use SignalR from a web client as well, you will have to upgrade the installed jQuery libraries to a later version as well. ASP.NET MVC apps come with jQuery 1.4.1, and you need at least 1.6.2. But that is ok to just NuGet…

Next, we need to reference the SignalR Silverlight client from the Silverlight project. That assembly is available in the SignalR folder under /SignalR.Client.Silverlight/bin/Release. This time, just copy the 2 assemblies (SignalR and Json.NET) somewhere good, and add a reference to them from the Silverlight project.

Ok, now that all the pre-requisites are in place, it is time to actually write some SignalR code.

I am going to build a really simple application, but SignalR can obviously be used for a lot more complicated scenarios. I am actually going to more or less replicate one of the SignalR JavaScript demos.

So let’s get started. The first thing we need is a Hub. A Hub is a central resource that clients can connect to and use to send, as well as receives messages. All you need to do is create a class that inherits from Hub, and define the methods that you would like the clients to be able to call. In my case, I will create a REALLY simple Hub

public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
        Clients.NewMessage(message);
    }
}

The property Clients is a dynamic object that represents all connected clients. By calling a method on it, we are sending a message to each of the clients.

In JavaScript, this is really cool as it looks as though the server is actually invoking a method on the client. In Silverlight, it doesn’t look quite as cool unfortunately.

That is all we need to do on the server end. The Hub will automatically be registered at runtime through an auto-registration feature backed by the Microsoft.Web.Infrastructure assembly that you added a reference to.

Next up is the client. First off, we need a simple chat window. Something like this

<Grid x:Name="LayoutRoot" Background="White">
    <Grid.RowDefinitions>
        <RowDefinition Height="*" />
        <RowDefinition Height="Auto" />
    </Grid.RowDefinitions>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="*" />
        <ColumnDefinition Width="Auto" />
    </Grid.ColumnDefinitions>
    <ItemsControl Grid.ColumnSpan="2" />
    <TextBox Grid.Row="1" />
    <Button Grid.Row="1" Grid.Column="1" Content="Send" Margin="10,0,0,0" />
</Grid>

Now that that is done, we need a ViewModel to handle the communication. It is once again REALLY simple…

public class MainViewModel
{
    private ObservableCollection<string> _messages = new ObservableCollection<string>();

    public MainViewModel()
    {
        SendMessage = new RelayCommand(message =>
            {

            });
    }

    public IEnumerable<string> Messages { get { return _messages; } }

    public ICommand SendMessage { get; private set; }
}

Obviously all the Hub code is not there yet, but the rest of it is. Very simple. And then that ViewModel needs to be hooked up in the view. That is standard stuff though, so I won’t show that, and instead focus on the SignalR stuff…

The first thing we need is a HubConnection. From that connection, we can create an IHubProxy, which is what we use to send and receive messages from a Hub. The HubConnection takes the Url to the server as a parameter, and works everything else out on its own.

Once we have the IHubProxy, we can hook up a listener using the extension method called On<T>(strrng, Action<T>). The T defines the type of the data being sent, in out case it is a string, but it could be any object that can be serialized using Json. The string is the name of the method that we called on the Clients object on the server, and the Action is the method to be called when a message arrives using the defined event name. Like this

public MainViewModel()
{
    var conn = new HubConnection(Application.Current.Host.Source.GetComponents(UriComponents.Scheme | UriComponents.HostAndPort, UriFormat.Unescaped));
    var hub = conn.CreateProxy("DarksideCookie.Ag.SignalR.Client.Web.Hubs.ChatHub");
    hub.On<string>("NewMessage", message => Deployment.Current.Dispatcher.BeginInvoke(() => _messages.Add(message)));
    conn.Start();
 
    SendMessage = new RelayCommand(message => hub.Invoke("SendMessage", message));
}

Oh yeah, don’t forget to start the connection. That is the call that sets everything in motion.

From the code above, you can also see the hub.Invoke() call that we use to call the SendMessage() method on the Hub on the server. Once again, we could pass much more complex objects, but string seemed good to begin with…

If you run the code now, you will see that when you send a message, it comes bouncing back to you in the “chat box”. And if that isn’t cool enough, try opening 2 windows with the same client in them and then send a message. That is much cooler for some reason even if it shows off exactly the same thing…

So, what else is there to say? Well, I would like to highlight a few things.

The first, and most obvious, is the fact that all Hub callbacks on the client some on the wrong thread. So we need to marshal them to the right one. It would be nice if the SignalR client did that on it’s own, but still a tiny problem…

The next thing is that using SignalR on the server causes restarts, and redeploys, to the IIS to be slow. I believe it is because SignalR is waiting for the long-polling connections to disconnect, which causes the restart to be slower. It can be quite annoying when debugging though…

And finally, I want to mention another nice feature that I am currently using on a project. The Hub class has a static Hub.GetClients<T>() that will get you all clients connected to the hub of type T. Giving you access to the Clients object we had in the hub, anywhere in the application. Using this, we can send messages to clients from anywhere. In my case, the Hub has no functionality at all, so the clients cant call anything on it. But instead, I let my WCF services notify clients of changes by pulling up a client list and sending a message when certain things happen… Very nice and simple…

That was it for my quick SignalR for Silverlight intro. There is obviously code for this. It includes a very minimalistic MVC app and a Silverlight project, that I suggest you look at and then extend to try out the Hub.GetClients<T>() functionality. It is nice!

Code: DarksideCookie.Ag.SignalR.zip (496.89 kb)

Cheers!

Adding WCF custom service behaviors in config

chris@59north.com — Mon, 05 Dec 2011 16:46:16 +0100

Lately I have been working with a bit of WCF for a client, and one of the things I have had to do is to create a service behavior to handle some security things. However, due to the fact that this application needed to run in several different environments, it needed to have different configuration under different circumstances.

The real need was actually to be able to remove the behavior in some circumstances, and add it in some. But I didn’t really want to do it through a bunch of if-statements in my behavior. Instead I wanted it to be done through configuration so that I could turn it on and off using config transforms…

Ok, so how do we do this? Custom service behaviors can be added to a service in several ways. They can be added to the WCF host from code, added as an attribute (also in code) or set up from config. But how do we make it available in config? Well, it isn’t that hard. All you need is an extra class that inherits from BehaviorExtensionElement and overrides 1 method, the CreateBehavior() method, and one property, the BehaviorType property.

It is REALLY simple to implement

public class MyBehaviorExtensionElement : BehaviorExtensionElement
{
    protected override object CreateBehavior()
    {
        return new MyCustomServiceBehavior();
    }
    
    public override Type BehaviorType
    {
        get { return typeof(MyCustomServiceBehavior); }
    }
}

As you can see, it only needs the inheritance and a way to return the type of the extension as well as an instance of it. Once we have that in place, we can add a behavior extension in web.config as follows

<?xml version="1.0"?>
<configuration>
  ...
  <system.serviceModel>
    <extensions>
      <behaviorExtensions>        
        <add name="myBehavior" 
             type="MyNamespace.MyBehaviorExtensionElement, MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      </behaviorExtensions>
    </extensions>   
  </system.serviceModel>
  ...
</configuration>

and then add it as a behavior like this

<?xml version="1.0"?>
<configuration>
  <system.serviceModel>
    <services>
      ...
    </services>
 
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <myBehavior /> <!-- Easy as! -->
        </behavior>
      </serviceBehaviors>
    </behaviors>
 
    <extensions>
      ...
    </extensions>   
  </system.serviceModel>
</configuration>

And if you need to remove it in some configuration, just add a config transform that removes it. Or the other way around, leaving it off by default and adding it in deploy… Just remember that the default setting is what will be used when debugging. Transforms only apply when publishing the app…

That’s it! Just a quick tip this time!

Cheers!

Is Windows Phone 7.5 Too Good?

chris@59north.com — Fri, 02 Dec 2011 07:43:09 +0100

I know I am a Microsoft fanboy, and I am the first to admit it. But I still want to say that I can listen to other peoples arguments and try to look at the facts objectively. I tend to see benefits in a lot of Microsoft things, but that doesn’t mean that I believe that everything else sucks.

I have used a Windows Phone device since before they were even released, built a couple of apps for it and talked about it for different audiences. And it is not a big secret that I like it, especially since I got Mango on my phone.

Having that said, I still believe that there are 2 very good alternatives available. The iPhone is, whatever kind of fanboy you are, a great phone. No, I don’t like a lot of things when it comes to Apple, and I don’t like being stuck with iTunes, and I don’t like Apple’s censorship. But it still is a freaking awesome phone, and pretty much single handedly managed to change the smartphone market into what it is today, which is SO much better than it was with Windows Mobile.

I don’t mind Android either. As a developer, it is very tempting to get an Android device. The specs are ridiculous! But I don’t like that it is still a little “techy”, and lacks pretty much all finesse when it comes to UX. It rips UX details from both iPhone and WP7, and it doesn’t do it that well. And you would expect a dual core behemoth of a machine to be able to handle a couple of transitions, but it still seems to be a bit choppy. But I guess it almost makes up for the lack of polish by having the most open development platform and marketplace.

Ok, so having given ridiculously quick intros to my opinion about both of the other platforms, you can see that I do actually find them to be great platforms. Heading into WP7 the story is pretty much the same.

I love the UX on WP7. I love the integration with social media. I love the fact that it sticks out. And the fact that WP7 has single handedly managed to get me to interact with pretty much all of the big social networks is quite impressive. Before WP7, I had a blog and an account on Facebook (never used it though). Now I am on Facebook, Twitter and LinkedIn to the point that I am getting a little worried where it will end.

But just as with the other platforms, there are things I don’t like. I don’t like the locked down featureset available for developers, or the lack of side-loaded apps. Not to mention that I hate the fact that Bing maps, however great I do find it in the US, still sucks beyond belief in Sweden. Or the tombstoning of applications.

I do appreciate that some of these things are there for a reason, generally to make the experience better in the long run. But it still means that I choose Android over WP7 from a development perspective. If I could only get something as great as Visual Studio 2010 to do it I would be happy doing that.

But why did it choose that headline then? Well, it is something I have been thinking about for a while. The fact that WP7 comes with a lot functionality built in is great, but it also makes me feel “abandoned” when I have to download a separate app.

Having to download games is fine, even if I would have loved to have some simple ones pre-installed, and local things like an app for my subway schedule is also ok. However, when I have to download a PDF-reader, or the YouTube app and so on, it feels as the phone is lacking functionality…even if it really doesn’t…. A PDF-reader or YouTube app is not native to any of the other platforms.

Downloading apps to the phone is something that comes natural when the phone is pretty bare to begin with. Sure there are pre-installed apps on iPhone and Android, but you still run off and get a set of basic apps when you get your hands on one. With WP7 you can do so much without doing that, which makes the trips to the marketplace a lot less frequent. At least in my world…

I think this might get a little bit in the way of the whole marketplace. Instead of pushing people there from the start, like the other platforms, it sort of gives you enough to keep you from running there and getting used to being there… And on the other platforms, the built-in functionality is still an app, it isn’t naturally part of the OS, pushing the “app” idea harder.

So, the question is, is giving too much functionality as part of the OS a bad thing? The answer? I don’t know…

Ok, rant over! I will try to keep my rants to a minimum, but sometimes I need to get it on paper to let it go…

Feel free to flame me, tell me that I am wrong, correct me or whatever you feel like. Would be interesting to hear what other people think…

Developer Mania II

chris@59north.com — Wed, 23 Nov 2011 18:58:35 +0100

I have just returned from the Developer Mania II conference that I spoke at today. It was a great one-day Microsoft conference about Windows Phone 7 development, and I heard some good speakers.

My part in the conference was to share the stage with Johan Lindfors and talk about MVVM. As a part of that talk, I showed off some code I have created to simplify navigation in MVVM scenarios. I thought I would share that code, so here it is: DeveloperMania.MVVM.zip (628.26 kb). It is a little on the heavy side, but that is due to the inclusion of Unity…sorry!

Developer/Designer Workflow According To Me - Take 1

chris@59north.com — Wed, 16 Nov 2011 14:54:09 +0100

A question I keep running into when I speak about XAML-based application developer is how the developer/designer workflow should work. I don’t know if the question is common in general, or if it is because people feel that I’m not only passionate about coding, but also about design.

I have spent quite a lot of time thinking about how this workflow should work when working with XAML. In other technologies, I believe that the flow is much harder to get going, and I believe it requires more steps. In the “XAML world”, it should be a lot easier. The separation between functionality and design is pretty clear. And this separation should enable quite a well working flow.

Before I get into how I see it, I want to add a disclaimer… I have not been able to try this out in the real world as much as I would have liked. Mainly because I, in most cases, play all the roles. Or at least manage everything from XAML to code, with visuals coming from a designer.

Now, with that out of the way, I can get down to business. To be able to show how I see it working, I have decided to write this post based on the idea of building a Twitter client. As I don’t have time to sit and design a new client, that will never even be built, I have decided to use an existing client for the example in this post. It happens to bet the Twitter client I personally use, TweetDeck. I hope they don’t mind me using them as an example…

If you happen to be involved in developing TweetDeck and find that this blog post is out of line, just drop me a line and I will rewrite using another Twitter client…

The first step in building a new application is generally to sit down and talk to the client about what he or she wants. I suggest having several people involved in this.

There should be a person responsible for communicating with the client regarding project progress, as well as day to day management. Basically a project manager. The project manager will not necessarily be adding input to the discussion, but as the PM will handle communication with the client throughout the project, being there and hearing the talk might prove valuable later on.

I obviously want a senior designer there. He/she is responsible for talking about the user experience and finding out what the client wants out of the application. What functionality is needed, what feelings should it invoke, what does the client want to convey and so on. Possibly pulling out some personas and so on.

And finally I want the lead developer there as well. Yes…I want the lead developer to be there during that initial workshop as well. Preferably I want the lead dev at as many workshops and meetings as possible. He/she might have valuable feedback about feature that are easy to add, or that will cause issues or add extra development time.

After this meeting, or possible several meetings, the designer should be able to draw up wireframes. I personally love the tool Balsamiq for wireframes. But obviously, if you know how to use Sketchflow that would work just as well. It all depends on how much the client needs to decide. Balsamiq is static pictures, but conveys the basic layout and functionality. Sketchflow can do the same, but is aimed at an interactive experience that conveys more of the user experience with transitions etc.

For the Twitter client, the wireframes would probably turn out something like this

And with some tweaks back and forth, the client signs off on the wireframes and gives the go ahead with building the application.

Ok…so it might no be that easy in the real world, but hey, this is a simple blog post about it. Use your imagination!

From this wireframe, the developer and designer, or possibly developer and “devigner”, can sit down and decide what functionality and data that needs to be used to build the application. This obviously turns into contracts for our viewmodels.

I use the word contract instead of interface as a lot of developers start seeing actual code interfaces… I am just saying that we can define what properties the VM needs to have.

Looking at the above wireframe, this is what I see

Some form of “main” view model that has 5 ICommands for the buttons at the top, and 2 “column” view models that will hold the information for the Friends and Mentions columns.

However, I will not go for 2 column properties. This UI will need to add and remove columns, so it needs to be a collection.

So the finished VM might look something like this (pseudo code)

public class MainViewModel
{
    public ObservableCollection<ColumnViewModel> Columns { get; }
 
    public ICommand NewMessage { get; }
    public ICommand AddColumn { get; }
    public ICommand Refresh { get; }
    public ICommand ViewSettings { get; }
    public ICommand LogOut { get; }


}

Next I would have a look at the removed parts from the previous picture

Which once again turns into to a new VM, called ColumnViewModel in the previous pseudo code. It needs a name, 3 ICommands for the 3 buttons, and a list of tweets. I also know that the list of tweets will change as new tweets come in, so it also needs to be an ObservableCollection<T>, turning the VM into something like this

public class ColumnViewModel
{
    public string Name { get; }
    public ObservableCollection<TweetViewModel> Tweets { get; }
 
    public ICommand Filter { get; }
    public ICommand ClearSeen { get; }
    public ICommand ClearAll { get; }
}

Keep in mind that this code is written in Live Writer so there might be spelling mistakes and stuff… But you should get the general gist…

Finally, the last part of the puzzle is this

Which gives me the last VM

public class TweetViewModel
{
    public ImageViewModel Image { get; }
    public string Username { get; }
    public string Content { get; }
    public DateTime TweetDate { get; }
    public string Client { get; }
    
    public ICommand AddToGroupOrList { get; }
}

The ImageViewModel is a “standard” viewmodel I use all the time. I have blogged about it several times previously. It basically encapsulates the download of the image, and exposes a progress property that enables the designer to build a progressbar and so on…

Now that this has been set, work can begin on building the application, and this is where it gets funky. As the designer goes of to do his visual design, which can take a while, the developer goes of and creates the application development solution. All in parallel…

The developer starts out by building quick and dirty design-time viewmodels. They are almost done with the pseudo code above. All we need are simple classes with hardcoded data. Just set up the classes in the constructor and you are fine. Nothing fancy…

Yes, you could also create this data in Blend using Blend’s design-time data support, but I actually prefer the quick and dirty custom VM way. That’s just the way I am…

The developer might also have to build some “behaviors” that the designer/devigner needs to use when doing the UI in Blend. In this case there are no fancy functionality that needs to be custom built.

He or she will then create the views that are needed, but just throwing them into the solution and adding the basic controls that are needed, which is simple Buttons and ListBoxes in this case. That way, the dev can hook up his VMs and make sure the work with an ugly looking UI. He or she will also make sure to hook up the design-time VMs using d:DataContext. This is not something that the designer might feel to confident doing…

Once this is done, and the solution is in source control, the dev can do on and start building services, dependency injection and real viewmodels. Basically geek-out doing things that we devs find interesting.

While the dev is doing his thing, the designer finishes off the design. In this case it turned into this

The cool thing now is that the designer, or his friend the devigner, can open up Blend and start working. Blend even has support for TFs integration, which is actually a great reason to use TFS.

I am not going to start a source control war, but what I want to say is that most designer find using Blend a stretch. Try getting them to use a source control system like GIT or SVN. You might as well forget it. TFS on the other hand is built into the tool, and pretty much hides the fact that it is there…

Anyhow…after the source is out of the source control, he/she can go on and change the control templates to look like they should according to the visual. And even do databinding to the design-time VMs, making sure that text flows properly and so on.

Unfortunately, the databinding dialog in Blend is crap compared to the one in VS2010, so I prefer the databinding in there instead.

This can, as mentioned before, go on in parallel to the developer coding up the functionality.

There will obviously be changes along the way that will cause the VMs to have to change and so on, but that is often easy to fix. This mostly happens when the designer starts doing the visuals and realize that it would be nice to have other data on the screen, or other functionality available. At that point, he/she can talk to the dev and explain the changes, and together they can either implement the changes, or decide that it is too hard/complicated/timeconsuming/expensive and skip it.

Once the designer is happy with a view, he/she checks it into source control. And once the dev is happy with his work, he checks it in. And in most cases, there won’t even be conflicts in source control as they are working on separate files. One is building UI, and one is building functionality. Just like it should be!

And at the end of the day/week/month/year you can check out the the whole solution and build it. And at run-time, the design-time VMs are ignored and the real VMs with the real functionality comes through and takes over and provides the UI with the correct data and functionality.

Yes, at the end of the day, this is a little utopian, but I still find it doable. it does demand some training and might be time-consuming at the start, but as soon as you get used to it, it should work. The tools are there, as well as the pattern and technology. You just need to invest the time to get it going and get some plumbing built. But the most important thing is to make sure that the designer/devigner/developer communicates throughout the process.

That is the way I see it… I would be happy to hear any thoughts!

PS: If you wonder what a “devigner” is, it is a person that is part designer and part developer. He/she sits “between” the developer and the designer and works mostly in Blend. Some people call it a interaction designer, but I find that being a different person with different abilities. I don’t really like the word “devigner” as it sounds a lot like divine, which has nothing to do with it…the person might be great at his/her job, but absolutely not divine.

Implementing federated security with Azure Access Control Service

chris@59north.com — Tue, 08 Nov 2011 13:55:20 +0100

I believe it is time for a really heavy blog post, and if you have ever read one of my other blog posts you are probably getting scared now. My posts are normally big, but this might actually be even bigger… Sorry! But it is an interesting topic with many things cover…

But before we can start looking at code, there are 2 things I want to do. First of all, I want to thank my colleague Robert Folkesson (warning, blog in Swedish) for getting me interested in this topic, and for showing me a great introduction.

And secondly, I want to give a quick run-through of what federated security and claims based authentication means…

Federated security means that an application relies on someone else to handle user authentication, for example Windows Live or Facebook. These identity providers are responsible for authenticating the user, and returning a token to the application, which the application can use to perform authorization.

The token that is returned contains a set of “claims”, which are small pieces of information about the user. It can be the users name, e-mail, username, role and so on. In reality, it can be anything the identity provider feels like providing. The application can then look at the claims and provide authorization based on this.

This is called claims based authentication, and sort of replaces the roles based authentication that we are used to. Why? Well, it is a lot more granular. Instead of giving access to a specific role, we can authorize access based on a whole heap of things, ranging from username to domain to “feature”. Anything we can think of. And on top of that, as long as we trust the identity provider, any provider can issue these claims, making our security much more flexible.

What I am going to be showing today however, is not based on using a provider like Facebook. Instead, I will use a custom Secure Token Service (STS) that implements a protocol called WS-Federation. WS-Federation is the same protocol that for example Active Directory Federation Service (ADFS) implements. The main difference between the custom one I’ll be using, and the “real” thing, is that this simple implementation (that I have actually borrowed) is mostly hardcoded and doesn’t actually do anything except generate a predefined token. But this will work fine for the demo…

But before we can get started, we need to get some pre-requisites installed. First of all, we need to get WIF Foundation installed. On top of that, we need the Windows Identity Framework SDK (WIF SDK) installed as it will help us with some configuration in VS. I will also use some code from a sample project built by Microsoft called Fabrikam Shipping. So that source code is important as well.

Fabrikam Shipping is a demo application developed by Microsoft to show off federated security among other things. It covers much more than this post, but is also much more complicated… The reason to download it is that I will be using bits and pieces from that project…

Now that all of the pre-requisites are installed, we can get started! The first thing on the list of things to do, is to get an STS up and running. Luckily, the Fabrikam demo comes with a simple STS application (as mentioned before). It is in the SelfSTS solution, which can be found in the unpacked “Fabrikam Shipping” folder under “assets\SelfSTS”. Unfortunately it doesn’t come pre-compiled, so you need to open the project and run it, which will produce a screen that looks like this

However, before we move any further, we need a new cert to use for signing the token. We could use the existing one, but I will create a new one just to cover that as well.

Creating the cert is easily done by clicking “Generate New..” in the UI, which will generate a new pfx-file in the folder where the SelfSTS.exe file is located. Give the cert a useful name and a password you can remember. That is bin/Debug if you just F5:ed to start the application. The cert is automatically used by SelfSTS…

If you click in the “Edit Claim Types and Values”, you can update the claims that the STS will issue in the token. This isn’t necessary, but the feeling is so much better when the application greets you by your real name instead of Joe (btw, isn’t it normally John Doe, not Joe Doe?)

And yes, before we go on, press the big, green start button.

The newly created cert obviously needs to be available on the machine that is going to run the application that consumes the token for it to work. In this case, that is the local machine. And it needs to be installed in a places where the application user can find it, and has access to it.

In this case, it will be a web application hosted in IIS. And being the lazy person that I am, I installed the cert in the machine store under the Personal container and set the ACL to allow Everyone to read it. In a real scenario you would do this in a safer way…

The actual install of the cert is outside of the scope of this post, but if you Google it you will find a million tutorials on the web. It is easy to do through mmc.exe and the Certificate snap-in.

Ok, STS done! Nice and simple! At least when using SelfSTS…

Next, we need to configure the Azure Access Control Service (ACS), letting it know about our STS. To do this, you have to log into the Azure management portal and click “Service Bus, Access Control & Caching” in the lower left corner. Next, select “Access Control” and click “New”, which will launch this screen

Fill in the namespace, location and subscription you whish to use and click “Create Namespace”. Creating the namespace will then take a couple of minutes…

While that is being created, you can have a long hard think about who would want to steal the namespace “darksidecookie”!? I wanted that for obvious reasons, but it was taken…

Once the namespace is active, select it and press the “Access Control Service” button at the top of the UI

This will bring up a new page where you can configure the access control. It even has a step-by-step of what you need to do to get up and going on the first page… So following that, start by clicking “Identity Providers”.

As you might see, Windows Live provider is already there, and can’t actually be removed… What you want is the “Add” link, which will start a wizard to guide you through setting up a new identity provider.

In this case, we want a WS-Federation provider, and after you have given it a useful name, you need to provide it with an XML file that tells it a bunch of stuff about the STS we are about to use. As our STS is running locally, we can’t give it the address to that. Instead, we choose to upload the XML as a file.

The FederationMetadata.xml can be fetched using a browser. Just point it at http://localhost:8000/STS/FederationMetadata/2007-06/FederationMetadata.xml, where SelfSTS will provide you with what you need. Save the XML to a file and upload it to the Azure ACS.

The login text is irrelevant for this demo, so just put whatever you want in there, and then press “Save”, which should send you back to a page that looks something like this

Ok, so now the ACS knows where to get the token from. The next step is to set up a “Relying Party Application”, which is the name for an application that relies on the ACS for authentication…

To do this, click the “Relying party applications” link and then “Add”. Give your application a useful name, and a realm, which is, as the page explains, the Uri for which the token is valid. If you are running locally, http://localhost/ will do just fine.

The token format should be “SAML 2.0”, and encryption should be turned off for this demo, as we don’t need it… Token lifetime is up to you, I left it at 600…

Next, you want to make sure that your new identity provider is ticked, as well as “Create new rule group”. And also make sure that you generate a new signing key before clicking “Save”.

After we got our “Relying party application” set up, we are almost done. However, we need to look at the rules for this application first.

Click “Rule Groups” and then the “Default Rule Group for XXX”, which will bring up a screen that shows you all the rules for the application. In this case it should be empty as we are in the middle of setting up our first application. But you can easily fill it up with the rules you need by clicking “Generate”. This will look through the configuration XML you uploaded for the STS, and automatically add “passthrough rules” for each of the claims issued by the SelfSTS service.

“Passthtrough” means that the claims issued by SelfSTS will just pass through the Azure ACS and get delivered to the application. You can change the rules to limit what is passed to the client, remap values and modify the claims in a bunch of ways. I will talk a little bit more about this later…

Ok, now the Azure ACS is configured for our application, and we can focus on creating the actual application, which will be a new ASP.NET MVC 3 application (I guess MVC is the way to go…) in VS2010.

Next, we need to set up a new host in the hosts file and map it to 127.0.0.1. We also have to create a new website in IIS, pointing towards the project folder of the new MVC application and using the host header we just added to the hosts file.

You also need to make sure that you update the application pool configuration to use .NET 4.0 instead of 2.0, which is the default. You could also configure it to run under a specific user account and only give that user access to the certificate that I previously set up to allow access for Everyone.

Now that we have a MVC 3 application project set up, with IIS hosting, it is time to configure it to use federated security, which is really easy when you have the WIF SDK installed. Just right-click your project and choose “Add STS reference...”.

In the wizard that opens, give it the URL to the site, as defined in the hosts file, and press “Next”. Ignore the potential warning that pops-up, it is just telling you that you are trying to use cool security stuff without using SSL. In this case that is actually ok…

Next, select “Use an existing STS”. The location of the metadata document is available in the ACS configuration website under “Application Integration”, under “WS-Federation Metadata”.

Once it has loaded that metadata, it will complain about the STS using a self-signed cert, which we actually know. Just disable certificate chain validation…

On the next screen however, we want to make sure to tell it that the token is encrypted, and select the self issued certificate that was imported earlier in the post.

After that, it is next, next, finish…

This will add a bunch of configuration in web.config, as well as a FederationMetadata folder with the meta data for the STS.

Ok, security configured! Time to create a view. First up, the index view!

The Home controller has very little code. For index() it uses this

public ActionResult Index()
{
    var claimsIdentity = (IClaimsIdentity)this.HttpContext.User.Identity;
    return View(claimsIdentity);
}

It basically just casts the current identity to an IClaimsIdentity and uses that as the model.

The view is almost as simple

@using Microsoft.IdentityModel.Claims
@model IClaimsIdentity
@{
    ViewBag.Title = "Index";
}

@if (Model != null && Model.IsAuthenticated)
{

    <h2>Hello @Model.Name! How is your life as a @Model.Claims.Where(c => c.ClaimType == "http://schemas.xmlsoap.org/claims/Group").First().Value?</h2>

    <span>Your claims:<br />
        @foreach (var claim in Model.Claims)
        {
            @claim.ClaimType @:: @claim.Value<br />
        }
    </span>
}

What the view does is pretty simple. If the user is authenticated, it writes out a greeting consisting of the name of the user and the group he/she belongs to. It then iterates through each claim and prints it on the screen.

That should be it! However, pressing F5 give you an error saying “A potentially dangerous Request.Form value was detected…”. The reason for this error is fairly simple. ASP.NET validates all incoming form posts and makes sure that no “<” characters are posted to the application in due to security issues. I will get back to why we are getting a “<” posted, but for now all we need to do is either turn off validation, or change the validation.

Turning it off is as simple as adding the following to you web.config

<configuration>
   <system.web>
      <pages validateRequest="false" />
   </system.web>
</configuration>

If you still want validation, you will have to change the validation that is going on. Luckily, the Fabrikam Shipping solution has already done this. Just copy the “WSFederationRequestValidator.cs” file from “FabrikamShipping.Web\Security” to your project, add a reference to Microsoft.IdentityModel to your project and add the following to your web.config

<configuration>
  <system.web>
    <httpRuntime requestValidationType="Microsoft.Samples.DPE.FabrikamShipping.Web.Security.WSFederationRequestValidator" />
  </system.web>
</configuration>

Ok…time to go F5 again… This time it should work, and you should see something like this

Ok, so we have obviously got it all going! But what is really happening? Well, you might see that the screen flickers a bit as the page is loaded. The reason for this is that as soon as you try to reach the site, it sees that you have no token and redirects you to the ACS, which in turn redirects you to the SelfSTS, which returns a token to the ACS, which takes those claims and returns them in a token to IIS.

Ehh…what? Well, it is easy to see what is happening in Fiddler

It might be a bit hard to see, but the first row is a 302 from the IIS (I am using www.securesite.com in my hosts file). The 302 redirects to xxxxxx.accesscontrol.windows.net over SSL. The return from the ACS is a page that causes a redirect to http://localhost:8000/ (SelfSTS). SelfSTS in turn replies with a page that contains an HTML form containing the token, as well as a JavaScript that posts the form back to the ACS. The ACS then takes the claims and repackage them in a token that is passed back to the client, which sends them to the IIS.

At least I think that is the flow. It gets a little complicated. The important part is that the token arrives and the user is authenticated!

Ok, now that security seems to work, it is time to start tweaking it a bit. I want to make sure that whenever a user is part of the group “Developers”, I want to add another claim to the token, something that is really easy with the ACS.

Open the ACS configuration page and click on “Rule groups” and then the default group from earlier. Click “Add” to add a new rule. In this case, I want the issuer to be the ACS and the input claim to be a “http://schemas.xmlsoap.org/claims/Group”. As you can see, it is open for you to input whatever you want as well…very flexible! The input claim value should be “Developers”, making sure that this rule is only applied when there is a group claim with the value “Developers”.

In the “Then” section, tell it to add an output claim with a type of “MyOwnClaimThingy” or whatever you want. The value can be whatever, as long as you input one. I chose “Dude!”. Finally press “Save”.

Go back to VS and re-run the application. Remember that the token might still be active (and in a cookie), so you might have to close the browser and re-start it.

When you load up the screen, there is no new claim…ok…simple reason. The SelfSTS is configured to issue the group claim with a value of “Sales” (I think…). So open the SelfSTS window (might have been minimized to Systray…) and stop it. Then edit the claims to make sure that the group claim says “Developer”.

Restart the browser again to get the new result, which should now be contain a claim called “MyOwnClaimThingy”, or whatever you called it, with whatever value you chose.

Ok, but what if you don’t want the authorization to be active everywhere? Maybe only a part of the site needs authorization. Well, simple! It is all based around the regular ASP.NET security. Just open the web.config and change the regular <authorization /> element

<configuration>
    <system.web>
        <authorization>
          <allow users="*" />
          <!--<deny users="?" />-->
        </authorization>
    </system.web>
</configuration>

The above configuration will effectively turn it off completely. You might want to do something else using <location /> elements or something. However, in my case, I want to be able to set the authorization on my controller or individual controller actions instead.

Normally you would just add an Authorize attribute to do this. However, that attribute is based around users or roles, not claims. Luckily, it is ridiculously easy to repurpose it to handle claims. Just add a class that looks like this

public class ClaimsAuthorize : AuthorizeAttribute
{
    private readonly string _group;
 
    public ClaimsAuthorize(string group)
    {
        _group = group;
    }
 
    protected override bool AuthorizeCore(System.Web.HttpContextBase httpContext)
    {
        if (!httpContext.User.Identity.IsAuthenticated)
            return false;
 
        var identity = httpContext.User.Identity as IClaimsIdentity;
        if (identity == null)
            return false;
 
        var claim = identity.Claims.Where(c => c.ClaimType == "http://schemas.xmlsoap.org/claims/Group").FirstOrDefault();
        if (claim == null)
            return false;
 
        if (!claim.Value.Equals(_group, StringComparison.OrdinalIgnoreCase))
            return false;
 
        return true;
    }
}

It overrides the AuthorizeCore() method with logic that looks for the claims. But before looking for the claim I want, I make sure the user is authenticated and that authentication has produced an IClaimsIdentity.

Next, I can mark any method or controller with this attribute to force authorization…

public class HomeController : Controller
{
    public ActionResult Index()
    {
        var claimsIdentity = (IClaimsIdentity)this.HttpContext.User.Identity;

        return View(claimsIdentity);
    }
 
    [ClaimsAuthorize("Developer")]
    public ActionResult Authorized()
    {
        var claimsIdentity = (IClaimsIdentity)this.HttpContext.User.Identity;

        return View(claimsIdentity);
    }
}

As you can see, I have created a new action called Authorized, which requires you to be logged in. If you aren’t, it automatically redirects you to the login page, which in this case is the ACS which just requests a token from SelfSTS and then returns it to the application, which renders the page.

Ok, so the actual implementation needs some tweaking, making sure that you get sent to a log in page and so on, but it works. However, it is up to the STS to give you a way to authenticate. The application just redirects you to the ACS, which in turn redirects you to another page. That page should have log in abilities, and make sure you are who you are, before redirecting you back with a valid token.

So…that is my introduction to federated security using Azure ACS. It is fairly complicated with a lot of moving parts, but once it is up and going, it is pretty neat. I hope my introduction has made it a little easier to follow. If not, tell me so and I will try to do better…

I have a little bit of source code for the web app I was using. It is however dependent on a whole bunch of other stuff as you can see from the post. But I thought I would put it up here anyway… So here it is: DarksideCookie.Azure.FederatedSecurity.zip (71.00 kb)

The source contains the config I was using, however that namespace does not exist anymore. So you will have to configure your own…