Dimebrain

A theming engine for ASP.NET MVC 2

Daniel — Fri, 06 Nov 2009 21:47:53 +0000

Get the example code shown in the video here.

I’ve wanted a way to apply custom themes in ASP.NET MVC that “just works” for awhile. Sometimes you want to apply a new theme that switches out just a few CSS elements, or changes the structure of a specific view, or the entire site. There’s no out-of-the-box way to do that, and the existing solutions I’ve seen will only solve the CSS problem, or the views problem, but not both, or they require you to duplicate your views for every theme or use exact file names rather than your own, which is a maintenance nightmare.

I’ve come up with a ThemeViewEngine, based on the current WebFormViewEngine, that allows you to opt-in to only the changes you need, whether that’s a CSS file there, a MasterPage here, a couple of views, etc. Since it’s written for ASP.NET MVC 2, it supports themes within areas as well. The next listing isn’t the whole engine, but it highlights the important points, which are the locations where theme content lives, and finding the theme in the current session or query string. In production, it’s not a great idea to use cookies (or use the URI for cookieless sessions), so you’ll probably want to tie the theme to a user’s session in a different way.

using System;
using System.Collections.Generic;
using System.Globalization;
using System.Linq;
using System.Web.Mvc;

namespace MvcTheming
{
    /// 
    /// Provides a flexible  for adding theming capabilities to your views.
    /// You have the option of using a theme to override only what you need, whether that's CSS, Javascript,
    /// MasterPages, or specific views. This way both look and feel as well as site structure may be
    /// changed on demand.
    ///

Using a controller to manage static resources

Daniel — Mon, 13 Jul 2009 13:57:59 +0000

If you’re like me, you’re more or less addicted to YSlow and getting the best performance for your web applications whenever you can. One challenge is to address multiple YSlow recommendations at the same time, particularly when it asks you to compress the content sent to clients, and in the same breath asks that ETags are used to avoid resending cached content for particular resources. In this excellent overview of some of the pitfalls of using ETags, you’ll learn that if you try to base your ETag value on compressed content, the timestamp-based format of that content will cause a new ETag to generate for every resource request, and the end result is a constant fetch of the resource, breaking your caching scheme.

For this challenge I decided to use a Controller, and mapped its route so that a request for the Site.css file in my “/Content/” folder, where the default project template stores CSS files (and where I store all static content), is declared in markup as “/static/Site.css”. Not a big difference for me, but I can customize the controller’s behavior later to search in multiple places, hiding the details behind the static URL path.

In ASP.NET MVC you have a few options for getting between the pipeline to fine tune your requests and responses. In this post I want to outline a static resource controller I’m using to ensure that my static content is cached on both the client and the server, is sent compressed whenever possible, and makes appropriate use of ETags. Your static resource controller should do the following things for you:

It should cache content on the client, and know when to send a 304 – Not Modified whenever the request is asking for an ETag that maps to the file it’s looking for, or if the last modified date of the resource file hasn’t changed since the last request. I prefer to evaluate the ETag first, just in case the file’s last modified date was changed, but the content of the file itself is identical, since that would result in an unnecessary cache invalidation.
It should cache content on the server, ensuring multiple requests from different browsers are handled efficiently (in this case from memory rather than from disk), and know when to invalidate the cached copy as soon as the underlying resource changes. This will help when you are lucky enough to have a traffic problem.
It should compress the content returned to the client based on what the client is able is to accept.
It should work with GZIP and DEFLATE, and the ETags should take these into account so that the controller works even when compression is turned off.

Here’s the skeleton version of the controller, with a few missing methods, but enough to read through to see how an HTTP GET call using the controller handles static resources.

using System;
using System.IO;
using System.Linq;
using System.Net;
using System.Text;
using System.Web;
using System.Web.Caching;
using System.Web.Mvc;
using Dimebrain.Commons.Mvc.Extensions;
using Dimebrain.Commons.Mvc.Filters;

namespace Dimebrain.Commons.Mvc.Controllers
{
    [CompressFilter]
    public class StaticResourceController : Controller
    {
        [AcceptVerbs(HttpVerbs.Get)]
        public void Get(string file)
        {
            var relativePath = string.Format("~/Content/{0}", file);
            var absolutePath = Server.MapPath(relativePath);

            // 304 (If-None-Match), a better test of uniqueness than modified date
            var etag = GenerateETag(absolutePath);
            if (BrowserIsRequestingFileIdentifiedBy(etag))
            {
                Response.StatusCode = (int)HttpStatusCode.NotModified;
                Response.SuppressContent = true;
                return;
            }

            // 404 (NotFound), if ETag differs, I/O access is inevitable
            if (!System.IO.File.Exists(absolutePath))
            {
                Response.StatusCode = (int)HttpStatusCode.NotFound;
                Response.SuppressContent = true;
                return;
            }

            // 304 (If-Last-Modified)
            var lastModified = new FileInfo(absolutePath).LastWriteTime;
            if(BrowserIsRequestingFileUnmodifiedSince(lastModified))
            {
                Response.StatusCode = (int) HttpStatusCode.NotModified;
                Response.SuppressContent = true;
                return;
            }

            // 200 - OK
            CacheOnClient(etag, lastModified);
            var content = CacheOrFetchFromServer(relativePath, absolutePath);
            using (var sw = new StreamWriter(Response.OutputStream))
            {
                sw.Write(content);
            }

            var contentType = absolutePath.MimeType();
            Response.ContentType = contentType;
        }
    }
}

That’s the controller in a nutshell. It compresses the stream serving the content, and it gives the browser multiple opportunities to use its cached copy, and it also caches the content on the server. Looking closer at the supporting methods of the controller, you’ll find that both the ETag and the server cache dependency on based on the file itself; when it changes, a new value is generated for the ETag, and the server cache is invalidated. This is a great way to set this controller up and forget about it, because whenever you make a change to the underlying resource, all bets are off and the browser is guaranteed to get the latest version on the next request.

using System;
using System.IO;
using System.Linq;
using System.Net;
using System.Text;
using System.Web;
using System.Web.Caching;
using System.Web.Mvc;
using Dimebrain.Commons.Mvc.Extensions;
using Dimebrain.Commons.Mvc.Filters;

namespace Dimebrain.Commons.Mvc.Controllers
{
    [CompressFilter]
    public class StaticResourceController : Controller
    {
        private const string DeflateTag = "-deflate";
        private const string GzipTag = "-gzip";
        private const string LastModifiedSinceHeader = "If-Modified-Since";
        private const string IfNoneMatchHeader = "If-None-Match";
        private const string DefaultEncodingCodePage = "iso-8859-1";

        [AcceptVerbs(HttpVerbs.Get)]
        public void Get(string file)
        {
            var relativePath = string.Format("~/Content/{0}", file);
            var absolutePath = Server.MapPath(relativePath);

            // 304 (If-None-Match), a better test of uniqueness than modified date
            var etag = GenerateETag(absolutePath);
            if (BrowserIsRequestingFileIdentifiedBy(etag))
            {
                Response.StatusCode = (int)HttpStatusCode.NotModified;
                Response.SuppressContent = true;
                return;
            }

            // 404 (NotFound)
            if (!System.IO.File.Exists(absolutePath))
            {
                Response.StatusCode = (int)HttpStatusCode.NotFound;
                Response.SuppressContent = true;
                return;
            }

            // 304 (If-Last-Modified)
            var lastModified = new FileInfo(absolutePath).LastWriteTime;
            if(BrowserIsRequestingFileUnmodifiedSince(lastModified))
            {
                Response.StatusCode = (int) HttpStatusCode.NotModified;
                Response.SuppressContent = true;
                return;
            }

            // 200 - OK
            CacheOnClient(etag, lastModified);
            var content = CacheOrFetchFromServer(relativePath, absolutePath);
            using (var sw = new StreamWriter(Response.OutputStream))
            {
                sw.Write(content);
            }

            var contentType = absolutePath.MimeType();
            Response.ContentType = contentType;
        }

        private bool BrowserIsRequestingFileUnmodifiedSince(DateTime lastModified)
        {
            if (Request.Headers[LastModifiedSinceHeader] == null)
            {
                return false;
            }

            // Header values may have additional attributes separated by semi-colons
            var ifModifiedSince = Request.Headers[LastModifiedSinceHeader];
            if (ifModifiedSince.IndexOf(";") > -1)
            {
                ifModifiedSince = ifModifiedSince.Split(';').First();
            }

            // Get the dates for comparison; truncate milliseconds in date if needed
            var sinceDate = Convert.ToDateTime(ifModifiedSince).ToUniversalTime();
            var fileDate = lastModified.ToUniversalTime();
            if (sinceDate.Millisecond.Equals(0))
            {
                fileDate = new DateTime(fileDate.Year,
                                        fileDate.Month,
                                        fileDate.Day,
                                        fileDate.Hour,
                                        fileDate.Minute,
                                        fileDate.Second,
                                        0);
            }

            return fileDate.BeforeOrEqual(sinceDate);
        }

        private bool BrowserIsRequestingFileIdentifiedBy(string etag)
        {
            if (Request.Headers[IfNoneMatchHeader] == null)
            {
                return false;
            }

            var ifNoneMatch = Request.Headers[IfNoneMatchHeader];
            return ifNoneMatch.EqualsIgnoreCase(etag);
        }

        private static string CacheOrFetchFromServer(string relativePath, string absolutePath)
        {
            var cache = HttpRuntime.Cache;
            string content;
            if (cache[relativePath] == null)
            {
                var encoding = Encoding.GetEncoding(DefaultEncodingCodePage);
                var dependency = new CacheDependency(absolutePath);

                content = System.IO.File.ReadAllText(absolutePath, encoding);
                cache.Insert(relativePath, content, dependency);
            }
            else
            {
                content = cache[relativePath].ToString();
            }

            return content;
        }

        private bool HasGzipFilter
        {
            // You can't inspect the response headers directly in IIS6 / Cassini
            get { return Convert.ToBoolean(HttpContext.Items["gzipped"] ?? "false"); }
        }

        private bool HasDeflateFilter
        {
            // You can't inspect the response headers directly in IIS6 / Cassini
            get { return Convert.ToBoolean(HttpContext.Items["deflated"] ?? "false"); }
        }

        private void CacheOnClient(string etag, DateTime lastModified)
        {
            var futureDate = 365.Days();
            var expires = futureDate.FromNow();
            var cache = Response.Cache;

            // Cacheability must be set to public for SetETag to work; you could also
            // add the ETag header yourself with AppendHeader or AddHeader methods
            cache.SetCacheability(HttpCacheability.Public);
            cache.AppendCacheExtension("must-revalidate, proxy-revalidate");
            cache.SetExpires(expires);
            cache.SetMaxAge(futureDate);
            cache.SetLastModified(lastModified);
            cache.SetETag(etag);
        }

        private string GenerateETag(string absolutePath)
        {
            var sb = new StringBuilder();
            sb.Append(absolutePath.MD5());

            if(HasGzipFilter)
            {
                sb.Append(GzipTag);
            }
            else if(HasDeflateFilter)
            {
                sb.Append(DeflateTag);
            }
            return sb.ToString();
        }
    }
}

You can see how the Cassini workaround is used in the code above, to check if either GZIP or DEFLATE was used based on the results of compression. If it was, the ETag is appended with the appropriate value, so that a browser that doesn’t support GZIP (and will rename nameless to protect the guilty) can still participate in ETags but not accidentally receive a compressed version, which would happen if only the MD5 was used to identify the file. You’re also throwing everything but the kitchen sink at the client cache, giving it more than enough information to work with caching. Keep in mind that it’s still up to your code to handle telling the browser that there’s nothing to see here, and that it’s time to move along, by comparing “If-Modified-Since” against the resource’s last modified date, and “If-None-Match” against the current ETag generated for the resource, to see if there are any discrepancies. There’s a few gotchas in this process, such as ensuring you truncate milliseconds in your file’s last modified timestamp, if the browser does the same thing, otherwise you’ll continue to send the same cached file every time.

To set up compression, you can use an ActionFilterAttribute, overriding the OnActionExecuting event to spin up a compression filter and add it to the output stream. The reason you would run compression prior to the action completing in this case is because I personally prefer to use the Visual Studio Development Server, aka Cassini, when debugging my applications. Unfortunately, Cassini emulates II6 which does not support integrated pipeline mode, and will cause exceptions when you try to inspect response headers directly when asking questions like “Is this response compressed?”, so, I apply compression before my controller action executes, and toss the results of the compression filter into HttpContext.Items so it’s available for the action down the line. You don’t have to do this if you’re debugging on a local IIS7 instance, or if you’re comfortable doing it live. Here’s the code to add compression to the controller through a filter.

using System.IO.Compression;
using System.Web.Mvc;

namespace Dimebrain.Commons.Mvc.Filters
{
    public class CompressFilterAttribute : ActionFilterAttribute
    {
        private const string ContentEncodingHeader = "Content-Encoding";
        private const string AcceptEncodingHeader = "Accept-Encoding";
        private const string GZipValue = "gzip";
        private const string DeflateValue = "deflate";

        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            var request = filterContext.HttpContext.Request;
            var acceptEncoding = request.Headers[AcceptEncodingHeader];

            if (string.IsNullOrEmpty(acceptEncoding)) return;

            acceptEncoding = acceptEncoding.ToLowerInvariant();
            var response = filterContext.HttpContext.Response;

            if (acceptEncoding.Contains(GZipValue))
            {
                response.AppendHeader(ContentEncodingHeader, GZipValue);
                response.Filter = new GZipStream(response.Filter, CompressionMode.Compress);

                // Hack so we can continue to use Cassini
                filterContext.HttpContext.Items["gzipped"] = "true";
            }
            else if (acceptEncoding.Contains(DeflateValue))
            {
                response.AppendHeader(ContentEncodingHeader, DeflateValue);
                response.Filter = new DeflateStream(response.Filter, CompressionMode.Compress);

                // Hack so we can continue to use Cassini
                filterContext.HttpContext.Items["deflated"] = "true";
            }
        }
    }
}

The last thing you need to do to get this working is declare the controller route wherever you’re doing such things, which by default is in your Global.asax file’s Application_Start event handler (via the RegisterRoutes method).

// Static Resources
routes.Add(new Route
    ("static/{file}", new MvcRouteHandler())
    {
        Defaults = new RouteValueDictionary(
                   new { controller = "StaticResource",
                         action = "Get",
                         file = ""
                       })
    });

Now you can declare your static resources that live in the Content folder like this, and get all the benefits of the controller.

That’s the code. The last snippet shows you all of the extension methods I used to make the example more readable. Hopefully this will feed your YSlow addiction just a little bit more, but more importantly, work effectively with cached static content in your MVC projects.

public static string MD5(this string filePath)
{
    var sb = new StringBuilder();
    using (var fs = new FileStream(filePath, FileMode.Open))
    {
        using (var br = new BinaryReader(fs))
        {
            var md5 = new MD5CryptoServiceProvider();
            var hash = md5.ComputeHash(br.BaseStream);
            foreach (var hex in hash)
            {
                sb.Append(hex.ToString("x2"));
            }

            return sb.ToString();
        }
    }
}

public static string MimeType(this string filePath)
{
    const string key = "Content Type";

    var extension = Path.GetExtension(filePath).ToLowerInvariant();
    var registryKey = Registry.ClassesRoot.OpenSubKey(extension);

    return registryKey != null && registryKey.GetValue(key) != null
               ? registryKey.GetValue(key).ToString()
               : "application/octet-stream";
}

public static bool EqualsIgnoreCase(this string left, string right)
{
    return String.Compare(left, right, true) == 0;
}

public static TimeSpan Days(this int value)
{
    return TimeSpan.FromDays(value);
}

public static DateTime FromNow(this TimeSpan value)
{
    return DateTime.UtcNow.Add(value);
}

public static bool BeforeOrEqual(this DateTime left, DateTime right)
{
    return left.CompareTo(right) <= 0;
}

Why Twitter clients don’t matter

Daniel — Sat, 18 Apr 2009 15:08:20 +0000

Since creating TweetSharp, I’ve had the opportunity to speak with a lot of folks who are using it to build their Twitter projects, which is great to hear. Most developers feel that a) the current state of the union for Twitter clients like Seesmic Desktop and Twhirl, TweetDeck and hootsuite, blu and Witty, just doesn’t do “all of the things I’d want a Twitter client to do”. And this is fair criticism, since client developers can’t possibly anticipate every use for Twitter, and new uses are emerging all the time.

The most common use for TweetSharp has been to accelerate the development of Twitter clients, which makes sense considering that is exactly why it was written in the first place. It is the API running the show behind the scenes of our own client. After working hard over the last while on our next-generation Twitter client, and watching the community conversations about taking things to the next level, we’ve realized: Twitter clients don’t matter, applications do. Here’s why:

Too many choices. I have a pet prediction that there will be around thirty choices of Twitter client around the summer of 2009. I know of several development teams working under a veil on their version of client revolution, myself and @jdiller included, that plan to launch this summer. This is great for users, the more options the better, but usually when faced with overwhelming alternatives, people stick with the default. That means more TweetDeck users, and more developers with superior offerings left scratching their heads.

Lack of diversity. The next evolution of Twitter clients will ultimately need to make journeys into extensibility; it just makes sense. Features like groups that persist across devices, interchanging multi-column and condensed views, slick UX, offline support, are not innovations when every developer who builds a client knows those features are necessary and are part and parcel of good software: this is the minimum bar. That means having a client that can load plugins to extend features, and possibly opening up that plugin model for others to build on top of your client, are going to be part of just about every competitive Twitter client going. TweetDeck will bring these features in if they aren’t working on them already. That means more TweetDeck users, and more developers with superior offerings left scratching their heads.
The sunset of “features-as-applications” . Once the vast host of Twitter clients converge on the same basic set of features and offer a decent extensibility model, the game will change to swallowing up all of the applications that have managed to attract a following simply because they fulfill one missing feature of Twitter’s default offering. Want to know who’s stopped following you? That’s Qwitter. Want to broadcast tweets at certain times to pre-defined groups? That’s TweetLater. And the list goes on, but all of these applications are not true applications, they’re just features. Features are not a good reason to build a business. The Twitter client army will devour these features as either native functions of the client itself, or bring them in piecemeal as plugins.

What’s left are applications in the true sense of the word: unique software that solves a particular need, whether broad or niche. This category is as wide open as innovation itself. You’ve always had the option of doing something remarkable.

Want to know how to get users to switch from TweetDeck to your client? Build an application worth switching clients for, then offer it exclusively from within yours. All things being equal–and they will be sooner than you think–nobody is loyal to their Twitter client.

Managing social data in Silverlight: do you push or pull?

Daniel — Wed, 28 Jan 2009 00:39:55 +0000

Here’s a problem you want to have: many concurrent connections to your web application, all vying for your precious data. Before you enjoy the challenges of that problem, you should consider whether your application works best in a push or pull scenario. In summary, pull applications are the most common; any time your client makes a service call to your application or another, expecting relevant data in the response, you are “pulling” data from a source and into your application. This is a fine way to go, as you are only keeping a thread in use long enough to retrieve your data or an error, and you’re off to greater things.

And then things go south

But what if your application is social, and the underlying data changes frequently? Let’s use Twitter as the typical example. Caching restrictions aside, how often do you want each and every one of your users to hit your server asking for the latest tweets? The numbers add up quickly if you have a popular application, and bandwidth is still a factor, even if you’re holding on to the actual data from Twitter for dear life.

Pushing through the dip

Have you heard of gnip? It is a freemium service that solves this problem for popular applications: rather than having clients continously pull data from a server, gnip lets your applications know when there is fresh data available to be had on social sites, so you only use exactly the amount of bandwidth you need to update your data. Even with a server set up to intelligently update its back-end social stores, you may also want to consider having a similar set up for your Silverlight (and any WCF-supported client) applications: your clients are “pushed” data when its new and relevant, with no polling required. Of course there are performance considerations to consider in this scenario as well, since your server will need to track “who” is listening for messages, but this may work well for the application you’re building, as it’s working well for mine.

Building a push client

A push client is made possible through WCF’s duplex polling feature. Most of the plumbing for this example comes directly from MSDN’s article, so if you care deeply about the implementation details then I suggest you start here first. A duplex service defines two contracts, the one for messages your client sends to the server to let it know its alive, and the one your server “calls back” to the client; the latter contains all of the messages we can push to our Silverlight applications.

Let’s build a Twitter client that receives fresh tweet statuses only when they are available, rather than asking for new statuses from the server at regular intervals, like we might conceive of in a “pull”-based application. We’ll use tweet# to handle the communication between Twitter and the server.

// These are the messages we can send from
/// the client to the server
[ServiceContract(Namespace = "Push.Server",
                 CallbackContract = typeof(ITwitterClient))]
public interface ITwitterService
{
    [OperationContract(IsOneWay = true)]
    void SignIn(Message receivedMessage);

    [OperationContract(IsOneWay = true)]
    void SignOut(Message receivedMessage);
}

// These are our "push" messages from
// the server back to the client
[ServiceContract]
public interface ITwitterClient
{
    [OperationContract(IsOneWay = true)]
    void ReceivedStatuses(Message returnMessage);

    [OperationContract(IsOneWay = true)]
    void SignedIn(Message returnMessage);

    [OperationContract(IsOneWay = true)]
    void SignedOut(Message returnMessage);
}

Notice we’re defining the callback contract for the main service, and all messages are one way. We definitely don’t want to block any threads as messages are sent and received, and we need to distinguish between what service operation is doing the pushing (in this case, signing in, signing out, and receiving the latest tweets) so our client can respond appropriately.

When a user signs in, we want to store a reference to the connecting client, and push data updates to them when relevant. A Twitter application likely has a central store of “tweets”, that is the same for each client; when new data is available, every client that is signed in will receive the same information. In the implementation of our service we’ll spin off a new thread that polls Twitter in the background looking for a response that differs from our last poll. We’ll cache this as a static variable containing the most recent update.

static TwitterService()
{
    StartStatusesQuery();
}

private static void StartStatusesQuery()
{
    // Build a request to get the application's followers
    var request = FluentTwitter.CreateRequest()
        .Statuses().OnPublicTimeline().AsJson()
        .Configuration.CacheUntil(6.Seconds().FromNow())
        .CallbackTo(ProcessStatusesResponse);

    // Re-query every five seconds
    new Timer(callback =>
              {
                  _statusesQuery = request.Root;
                  _statusesQuery.RequestAsync();
              }, null, 0, 5000);
}

In the query callback, we’ll check to see if the JSON reply from Twitter is different than the previous result. If it is, we’ll call up all of the signed in clients and let them know.

private static void ProcessStatusesResponse
        (object sender, WebQueryResponseEventArgs e)
{
    var json = e.Response;
    if (json == null)
    {
        return;
    }

    try
    {
        var same = _statusesResult != null ?
                   _statusesResult.Equals(json) :
                   false;

        if (String.IsNullOrEmpty(_statusesResult) || !same)
        {
            _statusesResult = json;
            var message = string.Format("{0}#{1}",
                                        STATUSES_ACTION,
                                        _statusesResult);

            CallClients(message, STATUSES_ACTION, (c, m) => c.ReceivedStatuses(m));
        }
    }
    catch (TimeoutException)
    {
        //
    }
    catch (CommunicationException)
    {
        //
    }
}

Now on the client we can demonstrate how to manage an open channel back to the server and work with the messages that we receive.

public Page()
{
    InitializeComponent();
    _ui = SynchronizationContext.Current;

    // Create a new manager to receive data pushes from the server
    _manager = new ChannelManager(_ui);
    ChannelManager.ResponseReceived += manager_ResponseReceived;

    StartTweetTicker();
}

private void StartTweetTicker()
{
    var timer = new DispatcherTimer {Interval = new TimeSpan(0, 0, 0, 2)};
    timer.Tick += ((sender, e) =>
                   {
                       if (_queue.Count == 0)
                       {
                           return;
                       }
                       var status = _queue.Dequeue();
                       _statuses.Add(status);
                       var tweet = new TextBlock
                               {
                                   Text = String.Format("{0}: {1}", status.User.ScreenName, status.Text),
                                   Width = 500,
                                   Height = 20
                               };

                       // This came from a different thread
                       _ui.Post(s => waterfall.Children.Add(tweet), null);
                       _ui.Post(s => UpdateQueue(), null);
                   });
    timer.Start();
}

In the page constructor above, we’re creating a new channel manager, a convenience class that wraps up the duplex polling logic, and passing it a handler for when a new server-side message is received. Then we make a call to spin up a new timer thread that “peels” from our batch of tweets and displays them on-screen.

void manager_ResponseReceived(object sender, DuplexResponseEventArgs e)
{
    switch (e.Action)
    {
        case ChannelManager.STATUSES_ACTION:
        {
            var statuses = e.Response.AsStatuses();
            var fresh = statuses.Where(s => !_queue.Contains(s) && !_statuses.Contains(s));
            foreach (var status in fresh)
            {
                 _queue.Enqueue(status);
            }

            // This came from a different thread
            _ui.Post(s => UpdateQueue(), null);
            break;
        }
        case ChannelManager.SIGNED_IN_ACTION:
            break;
        case ChannelManager.SIGNED_OUT_ACTION:
            break;
        default:
            throw new NotSupportedException("Unknown callback contract operation");
    }
}

Above, we’re handling the response to each unique message action, whether it’s confirming sign-in and sign-out, or receiving new tweets. In the latter case, we make sure we aren’t looking at any duplicate tweets from those we’ve received before, before queueing them up for display.

I won’t dwell on the fine details of the channel management code itself; for that you can refer to the MSDN article mentioned earlier. I have prepared a reference application you can use to see the duplex behavior in action. I like how twitterfall.com queues and then “peels” tweets off the queue for display; the reference application shows this type of behavior in action.

Download the example solution

It’s probably true that for many situations a pull-based architecture is appropriate. How well do you think push-based services scale? You can use this example as an exploration for your own applications.

‘Innovate with Silverlight 2′ article code available

Daniel — Sat, 24 Jan 2009 01:55:00 +0000

Back in October, I wrote an article for MSDN’s {youshapeit} campaign called “Innovate with Silverlight 2: Community-powered client side imaging“, outlining several open source approaches for displaying and editing GIF, PNG, BMP, and JPEG images in Silverlight 2 exclusively from the client-side.

I’ve received quite a few messages over the last while notifying me that the source code for the article is no longer available on the site. Luckily, I was given permission to share that code, so you may download it here. Please refer to the article for a description of licensing terms.

People + Media + Messages = Social

Daniel — Mon, 19 Jan 2009 11:32:57 +0000

In a social application there are always two domains: the domain you define, or the ‘problem’ domain, and the social domain. A video-sharing web application, for instance, has no problem domain. Its entire story can be described within the social domain: it has users, videos, possibly forums, possibly blogs, possibly syndication of content. In other words, there are patterns we can apply that allow us to describe this system to a framework without writing any code, at least not code that isn’t contained within some higher API-level abstraction. If we aren’t there today, then we should move in that direction.

Whatever is unique about this video-sharing application compared to all the others, then, is the element we can design and layer on top of the framework. That is the element that we find interesting, that teammates are passionate about, and that the Internet population will find exciting (we hope). The more we are able to focus on this element, the more enjoyable the process will be. It is also a matter of necessity: any application that does nothing more than re-iterate the acceptable interactions in a social domain adds nothing to the conversation, and is ultimately forgettable. Thinking that you can “just add blogs and tags” is not going to take you very far.

The crux of a social application is interaction. If social software had a paradigm to follow it might be called Interaction Driven Design. In “Designing for the Social Web“, Joshua Porter calls this the AOF pattern, or Activities, Objects, and Features. We’re designing for the need for your application to arrange itself so that it is evident what a user does, and what benefit they get from doing so.

The application you build is merely the implementation details of taking a description of a problem domain, and how it is allowed to interact with itself and other domains, and coupling it with a description of how its users may interact with each other. The more we can describe about those interactions up front, the less code we need to write. It is fortunate, then, that we already know much about the social domain, and it enjoys a healthy amount of overlap between the typical objects that we might find in a social application: people + messages + media. Are there any social objects that don’t fit one of these categories, and are the contracts between these categories not well-defined?

This blog was formed to explore and define the social domain, that which you can separate from your “secret sauce” and is the most likely candidate for abstraction. The principle we want to follow is that choosing to build social software in .NET should mean that we get to move from a great software idea to an implementation that already possesses the social domain, so that the harder work of creating your own interactions, the ones that make your application unique, is both more apparent and has common ground to relate with.

Introducing tweet#, the complete fluent C# library for Twitter

Daniel — Sat, 10 Jan 2009 09:21:00 +0000

tweet# is a complete C# library for Twitter that allows you to write short and sweet expressions that are automatically converted to Twitter queries and sent on your behalf. In addition to covering 100% of Twitter’s REST and Search APIs, tweet# also provides the following configurable features:

Discoverable method chains that only expose what you can actually call
Hooks for easy asynchronous operation
Status update truncation by word, and automated URL shortening
Server-side caching of queries (ASP.NET, memcached, or use your own)
Quick and painless conversion from JSON query results to C# data classes

Here are just a few examples to show you what’s possible with tweet#:

// Get the public timeline, caching the result for two minutes
var twitter = FluentTwitter.CreateRequest()
     .Configuration.CacheUntil(2.Minutes().FromNow())
     .Statuses().OnPublicTimeline().AsJson();

// Send a blocking call
var response = twitter.Request();

// Convert response to data classes
var statuses = response.AsStatuses();

With plans to support OAuth, selectors, rate limiting, and geocoding enhancements, tweet# should accelerate your Twitter client development.

// Send a status update with automatic URL shortening
var twitter = FluentTwitter.CreateRequest()
     .Configuration.UseUrlShortening()
     .AuthenticateAs(username, password)
     .Statuses().Update("http://code.google.com/p/tweetsharp")
     .CallbackTo((s, e) =>
                     {
                          // do stuff asynchronously...
                          var updated = e.Response.AsStatus();
                     }.AsXml();

// Send an asynchronous call
twitter.RequestAsync();

Feedback on design, features, and issues is greatly appreciated. The best way to get acquainted with tweet# syntax and style, currently, is to download the code or browse the unit tests.

I hope you find it useful!

Project code is hosted by Google Code:
http://code.google.com/p/tweetsharp

tweet# uses James Newton-King’s JSON.NET, the Enyim Memcached Client, and would like to thank Sean Erickson for his assistance with multi-part form posts.

How to make cross-site service calls in Silverlight using JSON

Daniel — Mon, 22 Dec 2008 13:31:01 +0000

You’re quite familiar by now with the need for cross-domain policy files and service proxies if you’ve spent any time writing applications in Silverlight that behave like mashups. The root of the cross-domain issue is in how browsers restrict XML requests, and one emerging and popular way to circumvent this problem is to make JSON calls instead, which are cross-site friendly.

Silverlight has a nice set of browser interoperability classes waiting to be used for these kinds of purposes. As a quick and dirty example let’s create some extensions that allow us to make JSON calls to grab data from Twitter.

The first thing we’ll do is create an event class that manages incoming JSON data received from a service call. We’ll want to work with objects rather than a string, so I’ve borrowed some code from a conversation on StackOverflow to provide a simple conversion from a JSON string to a dictionary of property names matched to objects. You can use whatever JSON converter you like, or download my version.

JsonEvent.cs

[ScriptableType]
public class JsonEvent
{
    public static event EventHandler Responded;
    public static void OnResponded(string json)
    {
        if(Responded != null)
        {
            Responded(null, new JsonEventArgs(json.ToDictionary()));
        }
    }

    [ScriptableMember]
    public void Received(string json)
    {
        OnResponded(json);
    }
}

JsonEventArgs.cs

public class JsonEventArgs : EventArgs
{
    public IDictionary Data
    {
        get;
        private set;
    }   

    public JsonEventArgs(IDictionary data)
    {
        Data = data;
    }
}

Now let’s take a look at the extension method that’s going to perform the service call for us.

JsonExtensions.cs

public static class JsonExtensions
{
    private static readonly Dictionary
        _scriptables = new Dictionary();     

    public static void SendJson(this string url)
    {
        if(!_scriptables.ContainsKey("Json"))
        {
            HtmlPage.RegisterScriptableObject("Json", new JsonEvent());
        }

        var id = HtmlPage.Plugin.Id;
        HtmlPage.Window.Invoke("jsonLoad", url, id);
    }
}

In the snippet above, we’ve registered a new instance of our JsonEvent class to receive incoming data, retrieved the name of the Sys.UI.Silverlight.Control instance on our host page, and called a JavaScript method called jsonLoad(), passing it the web request URL, and the control’s ID.

On the client-side, we’ll need the usual script to handle JSON data (www.json.org/json2.js for example), as well as a few lines to make the JSON call, and add a callback to our scriptable method registered on JsonEvent.

SilverlightJson.js

var $id;

function jsonLoad(url, id)
{
    $id = id;
    var script = document.createElement('script');
    script.type = 'text/javascript';
    script.src = url;
    script.src += hasParameters(url) ? '&' : '?';
    script.src += 'callback=jsonCallback';

    var head = document.getElementsByTagName('head')[0];
    head.appendChild(script);
};

function jsonCallback(jsonData)
{
    var id = $id;
    var silverlight = document.getElementById(id);

    if (silverlight)
    {
        var response = JSON.stringify(jsonData);
        silverlight.Content.Json.Received(response);
    }
};

function hasParameters(url)
{
    url = url.replace(/[[]/, "\[").replace(/[]]/, "\]");
    var pattern = "[\?]w+=([^&#]*)";
    var regex = new RegExp(pattern);
    var results = regex.exec(url);

    return results != null;
}

With the script in place, making a client-side call to Twitter is easy.

public partial class Page
{
    public Page()
    {
        InitializeComponent();
        JsonEvent.Responded += JsonEvent_Responded;

        "http://twitter.com/users/show/dimebrain.json".SendJson();
    }

    static void JsonEvent_Responded(object sender, JsonEventArgs e)
    {
        // Twitter response is in key-value pairs
        var name = e.Data["name"];
    }
}

This approach requires that the service API you’re calling supports the “callback” parameter, but the popularity and simplicity of using JSON on the client should see many of the most used APIs, like Twitter, providing this feature. Whether you stick with proxies or use this method, hopefully you have a better understanding of what is possible through the browser and Silverlight in tandem.

Composing animations with Silverlight.FX

Daniel — Fri, 19 Dec 2008 15:00:00 +0000

When I read Nikhil’s “Effects and Transitions for Silverlight” and its accompanying Silverlight.FX framework, I was impressed by how easy it was, and is, to create an animation and declare it on any Silverlight framework element.

With a framework this powerful, I wanted to extend it even further by providing a fluent interface, similar to jQuery, to compose and chain animations together. This way, you can declare a common animation element and behavior once, and apply it to any framework element you require, swap it for another, or chain reusable components together.

Here is the equivalent code for the highlight example above, using the new fluent interface:

Animator.WithNew(highlightImage)
        .Highlight(Colors.Yellow)
        .For(1.Seconds())
        .When(EffectBehaviors.Clicked)
        .Play();

So far we have a nice, code-centric way to declare these powerful effects (or any custom effects you create in addition to the ones provided with FX). Now we can take it even further by providing animation chaining to achieve the results of the CompositeAnimation effect in a natural way.

The above is nice and declarative, but you can achieve better readability and flow in the code below. In addition to parallel animations, you can also mix it up with sequential animations using the Then() method.

Animator.WithNew(compositeImage)
     .WithEasing(EffectEasing.QuadraticInOut)
     .Move(50).For(1.Seconds())
     .And().Resize(0.5, 0.5).For(1.Seconds())
     .And().Spin(360).For(1.Seconds())
     .And().FadeTo(0.5).For(1.Seconds())
     .Play();

You can also predefine animations and remix them at runtime using the the new interface. For example, the composite effect above is made up of four separate animations. Using the declarative approach we would have to create a new effect that wraps all of those effects, or rewrite them every time we wanted that particular combination of effects. Using a fluent interface we can declare each animation separately, and use them in one or many places interchangeably.

// Move script (used on another image)
var move = Animator.WithNew().Move(50).For(1.Seconds());
move.On(moveImage).Play();

// Resize script (used on another image)
var resize = Animator.WithNew().Resize(0.5, 0.5).For(1.Seconds());
resize.On(resizeImage).Play();

// Spin script (used on another image)
var spin = Animator.WithNew().Spin(360).For(1.Seconds());
spin.On(spinImage).Play();

// An animation on a new target but reusing
// the animations used on other targets
Animator.WithNew(compositeImage)
    .WithEasing(EffectEasing.QuadraticInOut)
    .FadeTo(0.5).For(1.Seconds())
    .And(move)
    .And(resize)
    .And(spin)
    .When(EffectBehaviors.Clicked)
    .Play();

The results above are achieved by combining animators’ contents together in the And() overloaded method. You are free to download the project, which includes the same effects examples from Silverlight.FX using the new fluent interface in the code-behind.

Enjoy!
Downloads: AnimationComposer

Jumping from ASP.NET to Silverlight 2 available now

Daniel — Tue, 16 Dec 2008 18:40:46 +0000

If you’re not familiar with Wrox Blox, they are shorter than books, and aim to give developers focused, contextual information on new technologies to get and stay productive quickly. I’m happy to report that Jumping from ASP.NET to Silverlight 2 was published today.

In it, I try to provide a solid base from which to learn Silverlight 2 coming from an ASP.NET development background. If you’ve held off getting into Silverlight 2, but are anxious to learn and build on what you already know about web development, I sincerely hope this is helpful for you.