Developing for the mobile platform is all the rage right now – and rightfully so! I, for one, am tired of having either an experience that plain does not work on my device or having to zoom in and scroll around just to look up some quick information (time tables for busses are my nemesis). There are a few ways to develop against mobile devices like creating a web application that works in the devices browser, creating a hybrid application using HTML and a framework like PhoneGap, or just go plain native. As ASP.NET developers most likely we’ll want take a look in to the first option, creating a web app that can run in a mobile devices browser. This is a great habit to have because even if you have a native application your users might not be aware and still navigate to your website. Or you might just have a native app for one platform, but not all. Either way, how do we go about developing mobile applications in ASP.NET now that ASP.NET 4.5 is here? Well, this is what this blog post is for!

Three Different Approaches

When creating any kind of web application, whether it is with plain HTML or with a server platform like ASP.NET, I like to say that there are three different approaches when creating applications that fit for mobile devices, one of which is to do nothing at all (boo and hiss!). These three are the following:

  1. The Lazy Approach – Doing Nothing
    This approach, while it is easy to do since it requires you to do absolutely nothing in terms of changing your application, is not really ideal. The only benefit is that you do not spend any additional man hours on development. These kind of pages, if they work at all on mobile devices, will require the user to pan and zoom everywhere in order to interact with the page properly. Additionally, links and buttons might be so small that the user keeps on tapping something else. Honestly I lost track of the amount of times I’ve done this on my phone.

  2. Building with Legos - Progressive Enhancement
    I like to think of progressive enhancements like building with Legos. Everyone has enough pieces to build a basic car, that just takes a kit or two. However, some people that are way to in to it (I may or may not have a chest full somewhere) have all kinds of crazy pieces. Like an awesome cage to keep prisoners, wings so it can fly whenever needed, some sort of submarine-like thing, and of course lasers. Oh man, those lasers.

    It’s the same way with the web. Most browsers let you build a simple web application but as the browser capability expands we keep on adding more and more features. This way everyone gets the car, but if you use the latest browser the car can fly, go underwater and even shoot laser beams – pew pew!

    This approach allows you not only to design for certain viewport ranges (how big the screen will be) but it’s all taken care of via CSS and JavaScript – no need to set up any logic for devices on the server. It also makes your application future proof since when a browser updates the standards it accepts it will be able to add that laser rifle.

    Of course, you run in to some problems as well. Certain screens, let’s say a huge form that has to be filled out, will still be really awkward on a mobile device as you’ve only added features and not necessarily thought of a redesign for mobile devices. Also, the fact that you do all of this on the client means that all the code for the features, even if they’re never used, gets sent over the wire regardless of if they get used or not.

  3. Doubling Down – Creating Mobile Specific Pages
    The third approach is to create pages which are specifically designed for mobile devices. Sure, the range of viewport sizes might still vary but you can say “this is what mobile users need to see” and stick with that. Often times the design for mobile devices has to be completely different from the desktop version, especially when user experience is taken in to account. You don’t want the exact same interaction for desktop and mobile devices – it’s two different target audiences completely.

    This is great because the pages are now specifically designed for mobile devices. This also gives you the minimum markup and styling needed to be sent over the wire, you don’t care about the resources for other versions of the app only the ones you currently need. You can also customize the server-side logic for each implementation, allowing for mobile-device specific items to be handled on the server once the information gets sent back.

    This also means that you have to double up (or sometimes more) of the UI you have since for each device you want to target you might want a separate view (tablet vs. phone for example). This means there is more work to be done on the UI. Additionally, you will have to update the code for new devices in case any breaking changes come up.

There might be some more pros and cons here, but these are some of the items that stick out when taking these three approaches. Although, to be honest, the first option should really be removed :) So, let’s just say these two approaches.

Now, how does ASP.NET help us with all of this? Well, I’m going to focus mostly on the third option, creating mobile-specific pages, as this is really where ASP.NET shines.

ASP.NET Specifics

There are a couple of ways you can go about using ASP.NET to help improve your ASP.NET Ajax applications when it comes to mobile.

The Easy Way

One such item is actually ridiculously easy, and while it might not be completely optimized for mobile it can help out tremendously when dealing with this scenario. Essentially all that you do is check if the current device connecting to your application is a mobile device, and if so you switch master page files to one which contains a more mobile-friendly CSS file. While this might be more of a generalization that all mobile devices are the same, you can still provide some CSS that could help alleviate some of the issues that pop up when using mobile devices with your application.

How is this done? It’s not that bad at all. On the PreInit event of any of your pages you can simply use the following:

protected void Page_PreInit(object sender, EventArgs e)
{
    if (Request.Browser.IsMobileDevice)
    {
        MasterPageFile = "~/Mobile.Master";
    }
}

Where “~/Mobile.Master” would be the path to the master page file you created.

Notice how I used Request.Browser? There’s actually a ton of useful stuff in there, with IsMobileDevice being one of the bigger ones. You could do Request.Browser.ScreenPixelsWidth and ScreenPixelsHeight for example. Or if you’re interested in the device itself you have MobileDeviceManufacturer (returns the name of the manufacturer of the device) and MobileDeviceModel (returns the name of the model of the device). There’s a lot that you can use to potentially aid the creation of a mobile-specific version of your application without too many changes to your code.

One downside of this though is that you are checking on every page whether or not the browser connecting to it is a mobile one or not. Kind of annoying to put that in several pages, and if you want to put it at a higher level you still requesting this change every time. Additionally, what if you want to show the desktop version to your users? I lost count of the amount of times certain sites don’t offer full functionality in their mobile web page, something was missing, or a features was just plain broken, and I had to switch over to the desktop view and go “manual mode” (zooming and scrolling) to take care of business.

How do we handle this? Well, we will have to work on a session-by-session basis to ensure that this is only taken care of once per instance that a user is connection to our application. This is all handled in our Global.ascx file, and let’s jump in to the Global.ascx.cs file and add a handler to Session_Start:

void Session_Start(object sender, EventArgs e)
{
    HttpRequest currentRequest = HttpContext.Current.Request;
    if (currentRequest.Browser.IsMobileDevice)
    {
        HttpContext.Current.Response.Redirect("~/Mobile/");
    }
}

We grab the current request, check if is a mobile device and then redirect to the Mobile directory. Given the fact that the Mobile directory should contain our mobile site this will guarantee that no matter what URL we utilize the user will always be redirected to our mobile site.

A Little More Involved

If you want to take this whole thing even further you sure can.  You can always look to see if the current page has a mobile equivalent and then redirect to that specific page – all you need to do is look at the current page and use the above redirect statement to a specific page of your choosing.

One note I want to make here too is that the above will always go to the root of the mobile site, so if you don’t want to kick people back to the beginning when they’ve been good boys and girls and bookmarked a page on your mobile site, just check to see if the URL path starts with “/Mobile/” and only redirect if it does not.

Mobile Simulator

Now that we’re putting in some code for mobile devices, how do we test it? Of course you can test it by having a VPN:ed device (if you’re doing this internally) or publish your app to a public staging sever then navigate to the specific URL and test it out in person. However, how many of us have iOS, WP7, Android, WebOS, and Blackberry devices all at once? Not to mention the phone and tablet variation of each!

Luckily WP7 is ridiculously easy for us .NET developers – just download the Windows Phone Developer Tools!

What about others? Well, in certain cases we cannot truly emulate the device on Windows (iPhone and iPad for example) but there are a lot of options out there. Microsoft even has a page which talks about the various device simulators out there so check it out and install the ones you might need :)

One First Step in to Mobile

While this blog post does not cover everything that you can do to create mobile applications it sure can give you a head start in what direction to think. Mobile devices are becoming more and more important to support, so don’t go with option number one that I listed in the beginning (doing nothing) and start tweaking your page to support these types of devices. While looking at converting your entire application might be a bit daunting, start to think about what mobile users would be most interested in and serve those pages, you can always offer the desktop version for more obscure pages (for now).

So, have you started to mobilize (and not in the sense of moving around ;)) your ASP.NET applications? Feel free to share your experiences in the comment section below.


About the Author

Carl Bergenhem

is an Enterprise Solutions Consultant at Telerik specializing in the ASP.NET AJAX and ASP.NET MVC products. He has always been interested in web development and has played around with various web technologies since he was a kid. In his free time Carl enjoys soccer, running and playing his guitar.

@carlbergenhem

Related Posts

Comments