Doing Crazy Things with ASP.NET MVC 4's Display Modes

Nothing I say here is recommended and it all may end up being a bunch of terrible ideas, but when has that stopped me before? Also, this is built on preview bits, so things are very likely going to change. Now, let's get funky with with the DisplayMode functionality in ASP.NET MVC 4 Preview.

There is a new class available for us to use in the ASP.NET MVC 4 preview that helps with mobile, and it's called DefaultDisplayMode. Here is an example of how you could use it:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);

    //New stuff here
    DisplayModes.Modes.Insert(0, new DefaultDisplayMode("android")
    {
        ContextCondition = (context => context.Request.UserAgent.IndexOf("android", StringComparison.OrdinalIgnoreCase) > -1)
    });
}

So this is pretty nifty. So you can take a typical controller action and view (assume the default "home/index" pair you get with the default site), which would use a "Index.cshtml" view, and add a new one called "Index.android.cshtml", you now get a view specific for an android device. The framework bits actually come with two by default, which you can see if you debug and do a quick watch on the Modes property of DisplayModes.

The first display mode (before we add one) has a DisplayModeId of "Mobile". So there is built-in functionality to do what we did for android generically with mobile. So you create another view called "Index.Mobile.cshtml" and view the page. If you view it with an Android device, you should see Index.android.cshtml. If you use another mobile device that isn't Android, you should see Index.Mobile.cshtml. Otherwise, you should see the normal Index.cshtml page. The different display modes execute in order in the collection, so if you want the Android view to be used first, then you have to insert it at the beginning of the list as we did above. But that's somewhat expected usage.

Let's Get Crazy

So like I said above, this may not be a good idea. Just because you can do something doesn't mean you should :) To start out on our path to crazy, let's create a custom DefaultDisplayMode derivative. There is a method we want to override, so let's do that, even if we don't change anything yet.

public class PotentiallyCrazyDisplayMode : DefaultDisplayMode
{
    protected override string TransformPath(string virtualPath, string suffix)
    {
        return base.TransformPath(virtualPath, suffix);
    }
}

I want to do something with this that I would have created a new ViewEngine to do in ASP.NET MVC 3. I want to create A/B test functionality so I can serve up different views to different people. If I were a business, I might use this to measure the effects of a new design or of new content/functionality on a page. The uses are potentially limitless, but here we just discuss the technical implementation. To make this kind of decision, we need to have something to split up our users. So let's do that in our controller action for our index page:

public class HomeController : Controller
{
    public ActionResult Index()
    {
        if (Session["testid"] == null)
            Session["testid"] = new Random().Next(0, 3);

        return View();
    }
}

We're assigning either a value of either "0", "1" or "2" to the session value "testid" in session. If "0", then we'll just use the default skin. Otherwise, we'll use that number to lookup a skin version. Now let's move to our CrazyDisplayMode class and use that to determine the test version, and transform the path to pick it up. We immediately run into a little problem because the method we would override to do this action, "TransformPath", does not have direct access to anything HttpContext related. This is a bit suboptimal but we can work around it. We could directly reference HttpContext.Current but every time I do that I feel like throwing up, so I'll hijack another method and do this session check. I've created a constructor that takes the suffix, so here is our more pimped out but slightly crazy DisplayMode derivative:

public class PotentiallyCrazyDisplayMode : DefaultDisplayMode
{
    public PotentiallyCrazyDisplayMode(string suffix) : base(suffix) { }

    public int? DisplayVersion { get; set; }

    public override DisplayInfo GetDisplayInfo(HttpContextBase httpContext, string virtualPath, Func<string, bool> virtualPathExists)
    {
        if (httpContext.Session["testid"] != null)
            DisplayVersion = Convert.ToInt32(httpContext.Session["testid"]);

        return base.GetDisplayInfo(httpContext, virtualPath, virtualPathExists);
    }

    protected override string TransformPath(string virtualPath, string suffix)
    {
        virtualPath = base.TransformPath(virtualPath, suffix);

        if (DisplayVersion.HasValue && DisplayVersion.Value > 0)
            virtualPath = virtualPath.Replace(".cshtml", String.Format("v{0}.cshtml", DisplayVersion));

        return virtualPath;
    }
}

And now update the global.asax...

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);

    DisplayModes.Modes.Insert(0, new PotentiallyCrazyDisplayMode("android")
    {
        ContextCondition = (context => context.Request.UserAgent.IndexOf("android", StringComparison.OrdinalIgnoreCase) > -1)
    });
}

And reload!

Splosions

If you hit this with a normal browser user agent, you'll be just fine. Use an iPhone user agent and you'll be fine too. But use an Android user agent and you will be rudely attacked by the yellow screen of death:

Why you may ask? Well, there is a bug. In some cases where you use custom DisplayModes, TransformPath is executed way too early in the request lifecycle, well before the controller action is executed. And it happens multiple times. In this case the null reference isn't the session variable but Session itself. Oh snap! This has been reported and hopefully will be fixed for the next preview/beta release. In the meantime we can protect against this and hope that things will be cleaned up a bit (it is a preview release, after all).

public class PotentiallyCrazyDisplayMode : DefaultDisplayMode
{
    public PotentiallyCrazyDisplayMode(string suffix) : base(suffix) { }

    public int? DisplayVersion { get; set; }

    public override DisplayInfo GetDisplayInfo(HttpContextBase httpContext, string virtualPath, Func<string, bool> virtualPathExists)
    {
        if (httpContext.Session != null && httpContext.Session["testid"] != null)
            DisplayVersion = Convert.ToInt32(httpContext.Session["testid"]);

        return base.GetDisplayInfo(httpContext, virtualPath, virtualPathExists);
    }

    protected override string TransformPath(string virtualPath, string suffix)
    {
        virtualPath = base.TransformPath(virtualPath, suffix);

        if (DisplayVersion.HasValue && DisplayVersion.Value > 0)
            virtualPath = virtualPath.Replace(".cshtml", String.Format("v{0}.cshtml", DisplayVersion));

        return virtualPath;
    }
}

Ugly but functional. You'll notice now that if you reload the page on Android (or using an Android user agent) that if not in the test group, the android page is shown. If in the test group, the default page. This is because we aren't doing any file existence checking before transforming the path. We could add that, a worthy effort indeed, but for now we'll just add the test skins for giggles and move on. So now we create a "Index.android.v1.cshtml" and "Index.android.v2.cshtml" and, voila, we have a different version per test id.

Of course that's just one application of the extensibility point here. You can transform that path to anything you want, which gives you quite a bit of flexibility. What will you do with it, dear reader? Perhaps nothing because it's crazy. Or is it?