First of all, it’s best to actually define and describe what a Mobile Adapter is and what it’s used for. Basically, it’s a replacement for a custom Web Part, or you can think of it as a class that makes a custom SharePoint 2010 Web Part accessible on mobile devices.

Many of the standard or out-of-the-box Lists and Libraries in SharePoint 2010 are automatically accessible through mobile devices. However, some are not. Adding to that fact, when creating custom Web Parts (or Visual Web Parts), you will almost always need to create a Mobile adapter for each custom Web Part.

Usually, from what I’ve found, is that you find out what doesn’t work when you try it. Microsoft tells us that we can emulate what a page with a Web Part will look like on a mobile device by just adding a simple query string to the end of the URL. For instance, if the URL to the SharePoint page is: http://mySharePoint/mySharePointPage.aspx

Then, to emulate what it might look like on a mobile device, the URL in your browser would be: http://mySharePoint/mySharePointPage.aspx?mobile=1

There are so many different mobile devices, that this is not 100% accurate. The best way to find out what it will look like is to actually view the page on a mobile device. For instance, an IPAQ with IE6 will not display GridViews or HTML Tables correctly, so you might need to adjust your code to make it look good on your intended target device.

My general recommendation would be to use the same general naming convention you used to create your original Web Part. For instance, if you named your Web Part “Dept_Search”, then, name your mobile adapter similarly – “Dept_Search_Mobile”.

To create a mobile adapter, start, in Visual Studio 2010, by creating a new project using the Class Library Template. Name your project with the recommendations in the previous paragraph. When the project is fully loaded, remove the class that is created by default. Add a new class to the project and, following the general naming convention, name it “Dept_Search_MobileAdapter”. This class will need to inherit the WebPartMobileAdapter, so, in VB, you’d need to add:

Inherits WebPartMobileAdapter

For C#, you just add “:WebPartMobileAdapter” after the public class designation.

You will need to add the references and imports/using statements as needed for your particular control.

The next part consists of building the actual Mobile Adapter by hand coding. I’ve found it best to put the Dim statements for the new controls, etc above the Class statement, to make them global in scope to the page. That way, you can use references to them in multiple routines and functions.

The base event handler you will need to add/override is:


In this event handler, you will hand code the child controls you need, and add them to the Controls collection in the order in which they should appear on a mobile device.

You can learn more about this and the DetailsView counterpart here:

The last thing before deploying is to make sure:

  1. You sign the assembly
  2. Clean and build the control

Once you have created and built the control, you will need to add it to the GAC. Each time you need to re-do the control, you should uninstall from the GAC, install into the GAC and do an IISRESET.

There are two places which require updating when the control is in the GAC: Compat.Browser page (for the site) Web.Config (in the SafeControls section)

In the Compat.Browser page, within the controlAdapters section, you need to add a section that lists the basic web part, and the new mobile adapter you have created, which basically tells SharePoint to use your new mobile adapter instead of the web part, when a mobile device is accessing the page with the web part. Here is an example of what is needed:
<adapter controlType=Dept_Search.SearchByDepartment.SearchByDepartment, Dept_Search, Version=, Culture=neutral, PublicKeyToken=00d172a57e0d7d94adapterType=Dept_Search_Mobile.Dept_Search_MobileAdapter, Dept_Search_Mobile, Version=, Culture=neutral, PublicKeyToken=1820cdc1d66fe330 />

For both the main controlType (for the web part) and the adaptertype (for the mobile adapter), it uses the following format:


Of course, the version is the version designated in the project. To get the PublicKeyToken, you can look at the following page to learn how to add a Tool to the Tools menu for doing this:

The second part that needs to be added is to tell SharePoint that your mobile adapter is definitely a safe control. To do that, find the SafeControls section of the web.config file and add a section similar to this:
< SafeControl Assembly=Dept_Search, Version=, Culture=neutral, PublicKeyToken=00d172a57e0d7d94 Namespace=Dept_Search.SearchByDepartment TypeName=* Safe=True SafeAgainstScript=False />

I know that sounds like a lot. And really it is, when you’re new to it, but once you’ve got a few of them under your belt, it gets easier!

For a great tool to help you get past the drudgery of creating your own Safe Control and Compat.Browser entries, check out this great new application:
Mobile Adapter Tool