views:

856

answers:

5

I'm working my way through some ASP.NET MVC reading and I have a web app at work that I'll be migrating from WebForms to MVC. One of the feature requests I expect to get in the process is to have a simplified view returned if the user is coming from a mobile device.

I can't quite see where the best place is to implement that type of logic. I'm sure there's a better way than adding an if/else for Browser.IsMobileDevice in every action that returns a view. What kind of options would I have to do this?

+2  A: 

In the Model-View-Controller pattern, it's the controller that chooses view, so, it's not that bad to add an if statement and return an appropriate view. You can encapsulate the if statement in a method and call it:

return AdaptedView(Browser.IsMobileDevice, "MyView.aspx", model);

Alternatively, you can create a view engine that dynamically executes a view based on whether it's mobile or not. I'm not a fan of this approach since I believe the controller should be in charge. For instance, if you're browsing on iPhone, you might want to see the full desktop version instead. In the former approach, you'd pass the appropriate boolean flag but in the latter, things become more complicated.

Mehrdad Afshari
A: 

Your core logic should be the same in the controllers and only the view you need will change so the controller is where the you do need the if/else statement to serve up the correct view for each controller action as you stated.

An alternative would be to wrap you controller logic in a seperate dll and then have different controllers / paths for the mobile version. If a regular controller receives a request from a mobile device you can redirect them to your mobile area which contains all your mobile controllers that use the shared controller logic. This solution would also allow you to do 'tweeks' that are specific to the mobile controllers and not have it impact your regular controllers.

Kelsey
+7  A: 

The first thing you want to do is introduce the Mobile Device Browser File to your project. Using this file you can target what ever device you want to support without having to know the specifics of what those devices send in their headers. This file has already done the work for you. You then use the Request.Browser property to tailor which view you want to return.

Next, come up with a strategy on how you want to organize your views under the Views folder. I prefer to leave the desktop version at the root and then have a Mobile folder. For instance the Home view folder would look like this:

  • Home
    • Mobile
      • iPhone
        • Index.aspx
      • BlackBerry
        • Index.aspx
    • Index.aspx

I have to disagree with @Mehrdad about using a custom view engine. The view engine serves more than one purpose and one of those purposes is finding views for the controller. You do this by overriding the FindView method. In this method, you can do your checks on where to find the view. After you know which device is using your site, you can use the strategy you came up with for organizing your views to return the view for that device.

public class CustomViewEngine : WebFormViewEngine
{
    public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
    {
        // Logic for finding views in your project using your strategy for organizing your views under the Views folder.
        ViewEngineResult result = null;
        var request = controllerContext.HttpContext.Request;

        // iPhone Detection
        if (request.UserAgent.IndexOf("iPhone",
   StringComparison.OrdinalIgnoreCase) > 0)
        {
            result = base.FindView(controllerContext, "Mobile/iPhone/" + viewName, masterName, useCache);
        }

        // Blackberry Detection
        if (request.UserAgent.IndexOf("BlackBerry",
   StringComparison.OrdinalIgnoreCase) > 0)
        {
            result = base.FindView(controllerContext, "Mobile/BlackBerry/" + viewName, masterName, useCache);
        }

        // Default Mobile
        if (request.Browser.IsMobileDevice)
        {
            result = base.FindView(controllerContext, "Mobile/" + viewName, masterName, useCache);
        }

        // Desktop
        if (result == null || result.View == null)
        {
            result = base.FindView(controllerContext, viewName, masterName, useCache);
        }

        return result;
    }
}

The above code allows you set the view based on your strategy. The fall back is the desktop view, if no view was found for the device or if there isn't a default mobile view.

If you decide to put the logic in your controller's instead of creating a view engine. The best approach would be to create a custom ActionFilterAttribute that you can decorate your controller's with. Then override the OnActionExecuted method to determine which device is viewing your site. You can check this blog post out on how to. The post also has some nice links to some Mix videos on this very subject.

Dale Ragan
Won't work with T4MVC, you assume the viewname is just a name and not a path. also won't work in release mode because of the caching.
Carl Hörberg
Haven't tried it since T4MVC has been released. This was before that was available. When I get time, I will update the answer to reflect my results when testing against T4MVC.
Dale Ragan
Carl, what do you mean by caching? This approach is identical to what Scott Hanselman describes here: http://www.hanselman.com/blog/MixMobileWebSitesWithASPNETMVCAndTheMobileBrowserDefinitionFile.aspx and he doesn't mention it.
roufamatic
See my solution here: http://stackoverflow.com/questions/1387354/how-would-i-change-asp-net-mvc-views-based-on-device-type/3819891#3819891
Carl Hörberg
+1  A: 

Hello

You can see articles for same here http://dotnetslackers.com/articles/aspnet/Mobile-Device-Detection-and-Redirection-Using-ASP-NET-MVC.aspx

Amit Patel
+1  A: 

This is a version which actually works, both with T4MVC and in release mode (where caching of views is enabled). It does take care of usercontrols and absolute/relative urls as well. It requires the Mobile Device Browser File.

public class MobileCapableWebFormViewEngine : WebFormViewEngine
{

    protected override IView CreateView(ControllerContext controllerContext, string viewPath, string masterPath)
    {
        if (viewPath.EndsWith(".ascx"))
            masterPath = "";
        return base.CreateView(controllerContext, viewPath, masterPath);
    }
    public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
    {
        useCache = false;
        ViewEngineResult result = null;
        var request = controllerContext.HttpContext.Request;

        if (request.Browser.IsMobileDevice || request["mobile"] != null || request.Url.Host.StartsWith("m."))
        {
            var mobileViewName = GetMobileViewName(viewName);

            result = base.FindView(controllerContext, mobileViewName, masterName, useCache);
            if (result == null || result.View == null)
            {
                result = base.FindView(controllerContext, viewName, "Mobile", useCache);
            }
        }

        if (result == null || result.View == null)
        {
            result = base.FindView(controllerContext, viewName, masterName, useCache);
        }

        return result;
    }

    private static string GetMobileViewName(string partialViewName)
    {
        var i = partialViewName.LastIndexOf('/');
        return i > 0
                   ? partialViewName.Remove(i) + "/Mobile" + partialViewName.Substring(i)
                   : "Mobile/" + partialViewName;
    }
}
Carl Hörberg
Thank you for following up, but I still don't see why you don't trust the cache. AFAICT allowing caching should speed up the calls into base.FindView(). Those calls are happening after the correct view has been chosen. Checking with Reflector confirms. I can understand disabling caching if you expect that those views will change, but that's not what's happening here. The views are the same, we're just adding logic for how to choose them. I'll stick with the cache.
roufamatic