MVC 4 :Mobile Routing: Part One

If you have not read Scott Hanselman’s Blog Post  on the developers preview of Visual Studio 2011, Asp.Net and MVC 4. GO READ IT !!

What caught my eye about MVC 4 was its new mobile support.   As mentioned in Scott’s Blog;

ASP.NET MVC 4 Developer Preview is the latest release of our MVC framework. This release includes built-in support for mobile sites, new, fresh HTML5 project templates as well as jQuery Mobile. It has enhanced support for asynchronous methods, and custom code generation.

You can download the bits from here

So one of the new is mobile device detection and routing.  In normal MVC you have a controller action that has an associated SINGLE view. The view then has the same filename as the action method. MVC 4 has a feature that allows routing from a  {controller}/{action} to one of several views depending on whether or not the browsing device is mobile.

The MVC 4 Functionality simply adds the identifier mobile between the two names {ActionName}.mobile.{fileType} example “” This can be used in the case of _layout pages as well. If a mobile device browses to the site then a view with the .mobile middle name will be returned if it it exists. If not then the desktop view will be returned.

Is the Customer REALLY always right ?

I once worked with a consulting firm whose client had selected us to do a portal migration project. They informed us that they had a very detailed project plan already completed and had been signed off on by a extraordinary number of managers. Hey that’s great, we normally never get a client that is on the ball.

As my associates and I reviewed the project plan, we soon realized to our growing dread that the client had absolutely no clue as to what the project entailed. Most of the tasks were completely off base. There was no possible way to do the project based on what was projected.

NICE !!!

When we held a conference with the client they admitted they had no knowledge about the product they were migrating to nor any idea of how to implement the migration at all. They had made up the tasks and milestones based on guesswork.

Ok so this should be salvageable right ?


To do a new project plan they would have to get all the managers approvals again, which would take months. The other issue is there was no budget to do a new project plan.

Of course we could have faked it and just ignored the plan, created a new one and implement a working solution. A director piped in and said that was fine, but we would still have to do the tasks on the project plan (impossible) to meet the milestones to be able to bill.

This happens more often than you would think. It can be even worse when the client has engaged one of the larger consulting firms to come in and draft a project plan. Many time the over sized consulting firm has no domain knowledge either but can fake it well.

So clients, please be careful. Talk to other customers who have implemented the same software stack. Read forums, see who publishes and answers questions, and most of all read up a bit on the capabilities of a given solution.

Consultants remember. If the client really knew what they were doing they would not need you.