Chapter 12. Making Web Parts mobile – SharePoint 2010 Web Parts in Action

Chapter 12. Making Web Parts mobile



Over the last few years, the use of mobile devices has exploded. You use mobile phones to read your email and browse the web at work, on the bus...pretty much everywhere. A combination of new and innovative devices and a well-established high-speed mobile network allows you to access information wherever you are. SharePoint 2010 has built-in support for mobile devices that makes the interface adapt to the various devices used to browse a SharePoint site. Using specifically created page views optimized for smaller screens and touch-enabled devices, you can now use SharePoint everywhere on nearly all devices. These views are also optimized to reduce network traffic.

In this chapter we’ll take a look at the mobile interface of SharePoint 2010 and see how you can configure the mobile experience for Web Part pages and Web Parts. Not all Web Parts can be used in mobile devices; you can use only those with specific control adapters that create a mobile interface for the Web Part. I’ll show you how to create and deploy control adapters in a consistent and reusable way.

12.1. SharePoint 2010 mobile interface

SharePoint 2010 allows users to access SharePoint from a wide variety of browsers and devices. Using a phone or tablet device, you can access nearly all information in SharePoint. It’s not only accessible; you can also add or update information and even view Office documents using the mobile view of Office Web Apps.

The mobile interface in SharePoint supports Web Part pages and Wiki pages as well as lists, views, and list items. Web Parts can be used in mobile pages if they have a control adapter that optimizes the Web Part for mobile views. SharePoint has support for a few of the out-of-the-box Web Parts and you can also build your own control adapters. Depending on the capabilities of the browser and device, the mobile user interface may look differently. SharePoint uses a file called the browser definition file to keep track of the various devices and their ability to optimize the mobile experience.

12.1.1. Using the mobile SharePoint 2010 interface

SharePoint 2010 is delivered with an out-of-the-box mobile interface for mobile or small screen devices. The mobile interface is optimized to fit on small screens and reduce the amount of data transferred over the network. The ASP.NET framework includes features that can detect which device is used and, using that information, can adapt the SharePoint interface for that device. SharePoint is aware of the capabilities of the device, such as whether it has a built-in phone or whether it can handle JavaScript. For instance, when SharePoint recognizes a touch-enabled screen, it renders the mobile interface with additional padding that makes links and buttons respond to a finger tap. Figure 12.1 shows a blog post rendered on a Windows 7 Phone device using the mobile view of a site. You can also see that the blog post viewed is paginated automatically. This is a default optimization designed to reduce the data transferred to the device.

Figure 12.1. A Windows 7 Phone that uses the mobile interface to read a blog post. The blog post is paginated so that only a minimal amount of information is transferred for each request.

Some devices (or browsers on devices) support the default SharePoint interface. The default interface isn’t optimized for small screens or touch gestures, which may make the interface less usable when working with information. Even though the device might support the default SharePoint interface, you might want to speed up the access while on slower networks and to reduce the traffic and roaming costs. To access the mobile pages using a full browser or on a device that supports the full interface, append mobile=1 to the query string, like this:


12.1.2. Page, form, and Web Part support

Almost all pages and sites can be shown using the mobile interface. The mobile pages are specific application pages stored in {SharePoint Root}\TEMPLATE\LAYOUTS\MOBILE\. Depending on what type of page is requested in the mobile interface, different files from this folder are used to convert the page into a mobile representation. For instance, the mblwp.aspx page is used to convert a Web Part page into a mobile Web Part page, and mblwiki.aspx is used for Wiki pages. Once a user requests a Web Part page from the device using the default URL, the user is redirected to the mblwp.aspx page with the target page passed as a QueryString parameter.

The mobile interface also has full support for viewing lists and items as well as editing and adding items. Figure 12.2 shows a user adding a new announcement to an Announcement list. Lists can have specific views that are optimized for mobile device access.

Figure 12.2. All lists in SharePoint can be accessed from the mobile interface. The mobile forms also allow users to add new or edit existing items.

Both Wiki and Web Part pages can be displayed in the mobile interface. All content will be shown, including rich text content in the Wiki pages, all depending on the capabilities of the device. Web Parts on the pages can also be shown if they support a mobile interface. As I mentioned earlier, only Web Parts with a mobile control adapter can be shown. Later in this chapter I’ll show you how to build your own control adapters.

For Wiki content pages, all Web Parts with mobile support are shown on the page. But for Web Part pages, you can configure exactly which Web Parts will be shown in the mobile interface. To determine which mobile Web Parts are visible on a Web Part page, click the Page tab in the Ribbon menu and choose the Edit Mobile Page button in the Page Actions group, as shown in figure 12.3.

Figure 12.3. The Web Parts in the mobile view of a Web Part Page can be configured. You can specify the order and which Web Parts to show.

The Edit Mobile Page option allows you to configure the default mobile settings for this page, and the Edit Mobile Personal Page option allows you to customize your own personalized mobile page. The mobile interface of a Web Part page ignores the Web Part zones. The Web Parts are listed in the order that they appear on the page. Using the Edit Mobile Page option, you can customize the order of the Web Parts for the specific page if the order should differ from the default interface order.

12.1.3. Supported mobile Web Parts

Web Parts, by default, aren’t supported in mobile pages; to show them, you need to create one control adapter per Web Part. SharePoint 2010 has control adapters for only a subset of the available Web Parts. You can create control adapters for your own Web Parts or for the default Web Parts; we’ll explore this in the next section. Table 12.1 shows the Web Parts that are available in mobile pages by default.

Table 12.1. Web Parts that by default can be used in mobile Web Part pages

Web Part

SharePoint SKU

XSLT List View Web Part SharePoint Foundation
List View Web Part SharePoint Foundation
Image Web Part SharePoint Foundation
Whereabouts Web Part SharePoint Foundation
RSS Viewer Web Part SharePoint Server
Business Data Item Web Part SharePoint Server
Business Data Item Builder Web Part SharePoint Server

12.1.4. Supported devices

SharePoint 2010 supports a wide range of mobile devices, ranging from Windows Mobile, Windows Phone, Blackberry, to iPhone, as well as tablet devices such as the iPad, as shown in figure 12.4. Depending on the capabilities of the device and browser, the full SharePoint 2010 user interface or the specific mobile interface will appear. No configuration is needed to enable the mobile device support. For devices such as Windows Mobile 6.5 or iPhone, the mobile interface is shown by default; for Windows Phone 7 or iPad, the default SharePoint interface is used.

Figure 12.4. Browsing SharePoint 2010 using an iPad gives you access to the full SharePoint 2010 interface instead of the mobile version. Notice that the Silverlight Web Part doesn’t show the Silverlight application.

12.1.5. Browser definition files

Since version 2.0 of ASP.NET, the ASP.NET runtime has used a file called the browser definition file, by default named compat.browser in SharePoint, to determine the capabilities of browsers and devices. For instance, this file might specify whether the device is a mobile device, whether it supports JavaScript, or whether it can initialize a phone call. When ASP.NET receives a request, it uses the user agent information in the header of the request to look up the browser specifics in the .browser file. The .browser file exists in the App_Browser folder of each web application, and you can configure it with new devices and capabilities to fit your needs.

The .browser file is an XML file that consists of browser elements that correspond to a specific platform, browser, or browser version. For instance, the iPod Safari browser is defined like this:

<browser id="iPodSafari" parentID="AppleSafari">
      <userAgent match="iPod" />
      <userAgent match="Mobile" />
    <capability name="isMobileDevice" value="true" />
    <capability name="canInitiateVoiceCall" value="true" />
    <capability name="optimumPageWeight" value="1500" />
    <capability name="requiresViewportMetaTag" value="true" />
    <capability name="supportsTouchScreen" value="true" />

The browser element contains a unique id element for the specific browser and optionally a parent browser id element for inheritance of capabilities from other defined browser elements. The identification element defines how to match the specific browser, and the capabilities element contains all the defined capabilities of the browser. The isMobileDevice property is the property that SharePoint checks to see whether or not the device is going to be automatically redirected to the mobile interface.

You can use the information in the file during runtime in your Web Part to detect the capabilities of the current browser. Do this by using the HttpBrowserCapabilities object, like this:

HttpBrowserCapabilities caps = Request.Browser;
string s1 = "Type of Browser: " + caps.Type;
string s2 = "Is current browser a crawler: " + caps.Crawler;
string s2 = "Has touch capabilities: " + caps["supportsTouchScreen"];

Some of the browser capabilities are available as strongly typed properties of the object, and some are available through the indexer property. Using these capabilities during runtime can help you make decisions as to how to render a specific Web Part or enable certain features. For instance, you could adapt the size of buttons, images, or links.



Microsoft provides updates to the .browser file using the ASP.NET CodePlex project, which you can find at The latest release ( is targeted for ASP.NET 4 but the download includes instructions on how to use the updated files with ASP.NET 3.5.


SharePoint Server 2010 adds a specific browser definition file called compat.moss.browser instead of modifying the default compat.browser file. This file contains the control adapters for the SharePoint Server Web Parts.

12.2. Mobile Web Part adapters

You can also create your own mobile views of your Web Parts by leveraging features in the ASP.NET infrastructure. ASP.NET supports alternate renderings of controls through control adapters. A control adapter is a specific registered control that allows you to modify the output of another control without any changes to the original control. By using a custom browser definition file, you can create and register a control adapter for the Silverlight-based Task Count Web Part (which you built in the previous chapter). This adapter will provide an alternate rendering for mobile devices, as shown in figure 12.5, because most mobile devices don’t support Silverlight (at least when this book was written).

Figure 12.5. Control adapters are used to create a mobile representation of a Web Part. The Windows Mobile 6.5 phone in this figure shows the number of tasks from the Task Count Web Part using text rather than the Silverlight application.

12.2.1. Create a mobile adapter

To provide the alternate rendering of the Silverlight-based Task Count Web Part, the first thing you need to do is build a new control adapter. Building this adapter doesn’t require any changes to the original Web Part and therefore you can create a new empty SharePoint project. The project has to be a farm solution because registering the control adapter requires that you edit the compat. browser file or add a new custom browser definition file. (The latter is preferred because updates to SharePoint or ASP.NET might overwrite the original files.)

Control adapters for Web Parts derive from the WebPartMobileAdapter, which is based on the generic control adapter class ControlAdapter object. The first thing to do is to add a new class file to the project and give it a name. I recommend that the name always end with MobileAdapter; in this example, name the class TaskCountMobileAdapter. Once you create the class, you need to create the alternate interface, using the code in the following listing (see figure 12.5).

Listing 12.1. A control adapter for the Task Count Web Part

To create the control adapter, set the TaskCountMobileAdapter class to inherit from the WebPartMobileAdapter class. First, you need to add the Guid attribute to the class. This isn’t necessary for the control adapter to work but will make it easier to deploy, which you’ll see later. The Guid attribute requires that you include the System.Runtime. InteropServices namespace in the class. You can generate the globally unique identifier (GUID) using the Guidgen tool found in Visual Studio under the Tools menu. Then, to provide the alternate rendering for the control, you must override a few methods. You don’t have to override all the methods in the WebPartMobileAdapter, just those necessary for your alternate view. In this example, two methods are overridden: CreateControlsForDetailView and CreateControlsForSummaryView . The first one contains the detailed view of the mobile interface. It retrieves the number of tasks in the Tasks list and uses the SPMobileLabel control to write out a heading and the number of tasks. The SPMobileLabel is a Label control optimized for mobile interfaces. To use the mobile controls, you also need to add a reference to the System.Web.dll and the System.Web.Mobile.dll in the project. In the second overridden control, the base implementation is called; this overridden method could be left out but I’m using it here to show the difference between the two.



To generate a GUID, use the Guidgen tool available in Visual Studio. If that tool isn’t installed, you can browse to to get a GUID. Never handcraft your GUIDs on your own; always use a tool so that it’s guaranteed to be globally unique.


The summary view is what the user sees by default when browsing to a page. The default implementation of the CreateControlsForSummaryView shows the name of the Web Part and an icon that the user can click to display the detailed view, as shown in figure 12.6. In this case it might be more appropriate to have the summary view call the detailed view method and show the same interface. That would allow the user to see the number of tasks directly instead of having to click the icon.

Figure 12.6. The Task Count Web Part, using the summary view of the control adapter. Clicking the icon in front of the Web Part title switches to the detailed view shown in figure 12.4.

The WebPartMobileAdapter contains a set of helper methods and properties that you can use to build the mobile interface. Table 12.2 shows some interesting properties and methods.

Table 12.2. Important methods and properties in Mobile Web Part adapters

Method or property


CreateWebPartIcon() Creates an Image control with the current Web Part icon, optionally linked to the summary or detailed view of the Web Part
CreateWebPartLabel() Creates a Label control with the title of the Web Part
DetailViewPageUrl The URL to the detailed view of the Web Part
SummaryViewPageUrl The URL to the summary view of the Web Part
ItemBulletIconUrl A URL to a bullet icon that’s used when the adapter needs to render a bulleted list

12.2.2. Register a mobile adapter

So far you’ve only created the control adapter—you haven’t yet registered it for use in mobile web pages. To register control adapters, you modify the existing compat.browser file or add your own .browser file to the App_Browsers directory. You simply add adapter elements to any of the browser elements in the file. The adapter element contains information about the control adapter and the control (Web Part) that the adapter will replace when rendering the mobile view.

You can add a control adapter to one or more specific browsers or add a generic control adapter. Generic control adapters have the refID attribute on the browser element set to default. For this project, you’ll add a generic control adapter in a custom .browser file.

Create the Custom Browser Definition File

To add a custom browser definition file to the project add an Empty Element SPI to your project. Rename the elements.xml file to customAdapters.browser (or delete it and add a new .browser file). This empty element doesn’t need any elements manifest; it’s just there so that the .browser file will be copied to the feature folder in the SharePoint root. Edit the file so that it looks like this:

  <browser refID="default">
        controlType="WebPartsInAction.Ch11.TaskCountWebPart. ManualTaskCountWebPart.ManualTaskCountWebPart, WebPartsInAction.Ch11.TaskCountWebPart, Version=, Culture=neutral, PublicKeyToken=6c2febfebf1839cd"
        adapterType=" $SharePoint.Type.95bd5e48-0771-4f32-9ff8-1877b6deaa6d.FullName$, $SharePoint.Project.AssemblyFullName$" />

The custom browser definition file defines one adapter for the Silverlight Task Count Web Part, created in the previous chapter. The control to replace is specified in the controlType attribute and the adapter is specified in the adapterType attribute. Both the control and adapter require that the full name of the class and assembly be specified. But you don’t have to enter the full class and assembly name of the adapter; the adapterType attribute uses the Visual Studio 2010 replaceable parameters, which are replaced by Visual Studio during the packaging process with the correct values. By using these replaceable tokens, you’ll save a lot of typing.

The replaceable token for the full class name has the format of $SharePoint.Type.<Guid>.FullName$ token, where <Guid> is the lowercase representation of the Guid attribute on the adapter that you previously added. By default, Visual Studio doesn’t parse .browser files for these tokens, so you need to make a small change to the project file (.csproj) in Visual Studio. Right-click on the project in the Solution Explorer and select Unload Project. Visual Studio will unload the project and you’ll see a gray icon next to your project name. Right-click the project node once again and select Edit WebPartsInAction.Ch12.Mobility.csproj (or whichever name you gave your project). Visual Studio will now display the XML for your project file. Before the Import element that contains the SharePoint targets file, create a new PropertyGroup element or add the following to any existing PropertyGroup element:


This code will make Visual Studio replace all tokens in all files ending with .browser. You can add any file extension you like here; just be sure to separate them with semicolons. By default, Visual Studio parses files with the extensions .ascx, .aspx, .dwp, .webpart, and .xml. Right-click the project node in Visual Studio once again and select Reload Project to go back to editing your project.



For full reference of all available replaceable parameters in Visual Studio, refer to


The Solution file will not add the file to the App_Browser folder of the web applications when deployed; it will only be added to the SharePoint Root. You could manually copy or edit the customAdapters.browser file in the App_Browsers folder for each web application on each server to add the control adapter. But I don’t recommend that you manually copy or edit the .browser file because it’s hard to maintain consistency over all web applications in the farm. A better approach is to create a timer job in SharePoint that creates the file or makes the change in the existing file for you on all the web applications. You can use a similar timer job to remove the control adapter from the .browser file.

To make the registration process more seamless (and to make it a reusable solution), I’ll show you how to create a timer job that registers the mobile control adapter in your solution. This timer job will be invoked when a feature is activated or deactivated. Failing to remove the control adapters from the .browser file when removing the control adapter assembly will cause the entire SharePoint application to break and throw exceptions.

When you add a custom browser definition file, SharePoint, or rather ASP.NET, won’t automatically pick that up. ASP.NET caches a compiled version of the browser definition files and only empties that cache when already compiled and existing .browser files are changed. This means that if you update the compat.browser or compat.moss.browser file, ASP.NET will recompile the browser definitions. To force ASP.NET to recompile custom browser definition files, you have two options. The first is to empty the cache by deleting all files from the Temporary ASP.NET Files directory located under c:\Windows\Microsoft.NET\Framework64\v2.0.50727\. The second alternative, which I’ll show you in this example, is to change the last edited time on the default compat.browser so that ASP.NET thinks that the file has been updated and thus recompiles all browser definition files.

Create the Timer Job

A timer job is a task that is asynchronously executed by the SharePoint Timer Service. Creating timer jobs is a great way to schedule repetitive jobs or long-running operations. The timer job can be set to run on all servers or only on specific servers.



For more information about timer jobs, read the following article on MSDN:


To create the timer job that you’ll use to add the custom browser definition file, first add a new class to the project; assign the class the name BrowserDefinitionTimerJob. This class should inherit from the SPJobDefinition class. The timer job will copy a custom browser definition file from the feature folder in the SharePoint root to the App_Browsers directory of the web application. To create the timer job, you must define the constructors and timer job information, such as the name and description, as shown in listing 12.2.

Listing 12.2. Timer job definition that installs the control adapter
public class BrowserDefinitionTimerJob: SPJobDefinition {
    public BrowserDefinitionTimerJob()
        : base() {

    public BrowserDefinitionTimerJob(string name,
        SPWebApplication webApplication) :
        base(name, webApplication, null, SPJobLockType.None) {
    public override string DisplayName {
        get {
            return "Add custom browser definition file";
    public override string Description {
        get {
            return "Copies a custom browser definition file
to the App_Browsers directory";

The timer job has two constructors: the default without parameters and a second one that accepts a name and an SPWebApplication object. Because the browser definition file is a web application–level file, this timer job has to be run on each web application. The constructor calls the base implementation constructor with SPJobLockType set to None, which ensures that this job is run on all front-end servers for the specified web application. DisplayName and Description are used to provide information to the administration interface in the Central Administration website.

To complete the timer job, you have to implement the Execute method, which does the work when the timer job is triggered. Listing 12.3 shows the code that copies the browser definition file into the App_Browsers folder of the web application.

Listing 12.3. The Execute method of the timer job

The Execute method is executed for each web application for which this timer job is created. The same timer job will be used both for addition and removal of the browser definition file, and that’s configured using timer job properties . Because a web application can be extended to different zones, you need to iterate over all the available zones that are used by the SharePoint web application and for each create the path for the new .browser file . Using the GetGenericSetupPath method of the SPUtility class, the path to the feature and the source .browser file is created, and then the file is copied to the destination folder (App_Browsers) . Finally, the last write time is changed on the compat.browser file so that ASP.NET is forced to recompile all browser definition files. Because the same timer job is used for deleting the custom browser definition file, the last branch just deletes the file from the App_Browsers directory.

Now that the timer job is defined, you need to create an instance of it. Do so by adding a new Feature to the project and creating a Feature receiver class that will configure the timer job for addition during activation and removal when deactivated.

Add a new Feature to the project and set its scope to WebApplication. Remember that you register the adapters on a web application basis. To add the Feature receiver, right-click the Feature and select Add Event Receiver. Add a constant to the Feature receiver class that contains the name of the timer job, like this:

public const string jobName = "browser-definition-timer-job";

To instantiate the timer job in the activation method, uncomment the FeatureActivated method. Enter the following code to create and schedule the timer job instance in the FeatureActivated method:

SPWebApplication webApplication = properties.Feature.Parent
    as SPWebApplication;

BrowserDefinitionTimerJob newJob = new BrowserDefinitionTimerJob(
    jobName, webApplication) {
    Schedule = new SPOneTimeSchedule(DateTime.Now)
newJob.Properties.Add("add", true);

The timer job instance is created using the constant name and the web application that the feature is activated on. A one-time schedule is used to schedule the job for running immediately. Because it’s a one-time scheduled job, you don’t have to take care of removing the job—that’s done automatically after the job has executed successfully. Before the timer job is saved, add a parameter called add with the value true, which tells the timer job that it should add the new browser definition file, as shown in listing 12.3.



Timer jobs are executed by the SharePoint Timer Service. If you’re making changes to the timer job in your solution, you need to restart that service, because it caches your assembly. Do so by executing the following PowerShell command: restart-service sptimerv4. To debug timer jobs you need to attach the Visual Studio debugger to the owstimer.exe process.


For the removal of the adapters, follow the same procedure: uncomment the FeatureDeactivating method. And instead of configuring the timer job for addition, specify that it should remove the browser definition file:

newJob.Properties.Add("add", false);
Create the Safecontrol Entry for the Adapter

There’s one thing more you should do to before deploying the solution: add safe control entries for the adapters. You can do this by using the SharePoint Developer Tools in Visual Studio. Select the SPI node containing the customAdapters.browser file, which you created earlier, in the Solution Explorer. Right-click the SPI node and select Properties. In the Properties window click the ellipsis button next to the Safe Control Entries property to open the Safe Control Entries dialog box. Click the Add button and modify the Namespace property so that it has the namespace of the mobile adapter, as shown in figure 12.7.

Figure 12.7. The Safe Control Entries property of SharePoint Project Items in Visual Studio 2010 allows you to easily add new safe Control entries.

All that’s left is the testing. Build and deploy your solution and you should be able to browse the Web Part pages where you added the Silverlight-based Task Count Web Part using a mobile browser. Or you can append mobile=1 to the query string in your browser and see that there’s a mobile version of the Web Part, as shown in figure 12.6. You can also go to Central Administration and select m > Review Job Definitions > Job History. There you’ll see (after a few seconds) that the timer job has successfully been executed, as shown in figure 12.8.

Figure 12.8. Check the Monitoring section in the Central Administration for the status of the timer jobs.

To test the activation and deactivation, in Central Administration choose Application Management > Manage Web Applications and select the web application that you’re going to test the Feature receiver on. Then choose Manage Features to activate and deactivate the web application–scoped feature, as shown in figure 12.9.

Figure 12.9. The control adapters are deployed as web application–scoped Features and are activated and deactivated from Central Administration.

If you make updates to the project, and specifically the timer job, you have to manually restart the timer service, because it keeps a reference to the assembly. To restart the SharePoint timer service, use the following PowerShell command:

Restart-Service sptimerv4

12.3. Mobile controls

Rather than adapting all your controls to the Web Part interface, you can take advantage of the set of mobile controls that comes out of the box with SharePoint and ASP.NET. The ASP.NET assembly System.Web.Mobile.dll contains several useful mobile controls representing most of the default ASP.NET web controls in the System. Web.UI.MobileControls namespace. These controls take advantage of the various browser capabilities such as JavaScript, touch, and phone support. Table 12.3 describes some of the available mobile controls.

Table 12.3. Sample ASP.NET mobile controls



Calendar A calendar control optimized for mobile view.
Image Displays an image based on the characteristics of the device.
List Renders a list that can use pagination.
PhoneCall For devices with phone capabilities, this control renders a link that invokes a phone call. For other devices, the phone number is displayed.

SharePoint also has its own mobile controls specifically designed for SharePoint. These controls are defined in Microsoft.SharePoint.dll in the namespace Microsoft.SharePoint.MobileControls. Most SharePoint controls and fields have a corresponding mobile control. Table 12.4 explains some of the mobile controls available in SharePoint.

Table 12.4. Sample ASP.NET mobile controls



SPMobileDispFormNavigation Renders a link to the display form for a list item
SPMobileHomePageNavigation Renders a link to the home page of the site
SPMobilePeoplePickerForm Renders a people picker control
SPMobileThumbnail Renders a thumbnail for an image list item

For a Web Part that shows the name of the page editor with an option to contact the editor, the contact option would normally consist of an email link for use with standard browsers. With a mobile adapter, you can add the phone number, which the user can click to invoke the phone function of the mobile phone. The default Web Part would show an email link, as you can see in figure 12.10.

Figure 12.10. The Page Author Web Part in the standard web interface shows a link that you can click to contact the author via email.

This Web Part overrides the CreateChildControls method like this:

protected override void CreateChildControls() {
    SPFile file = SPContext.Current.File;
    SPUser author = file.Author;
    this.ChromeType = PartChromeType.None;
    this.Controls.Add(new HyperLink() {
        Text = "Page author: " + author.Name,
        NavigateUrl = "mailto:" + author.Email

For this Web Part, you can create a control adapter that uses the mobile controls to render a phone call–enabled link using the PhoneCall mobile control. For browsers with phone support, it will render as shown in figure 12.11. If users click the link, they’ll be taken to the phone interface of the device with the phone number automatically entered. If phone support isn’t enabled for the device, the phone number will be printed on the screen instead.

Figure 12.11. The control adapter for the Page Editor Web Part renders a phone call supported link for devices with phone support instead of a link that sends an email.

The mobile adapter for this Web Part is implemented as follows. Only the CreateControlsForSummaryView method is overridden:

Because this is a mobile page representation of the original Web Part page, the SPFile object must be retrieved using the Url QueryString parameter. Two controls are added: the an SPMobileLabel control and a PhoneCall control. The SPMobileLabel control and other mobile controls have a weight. The weight of the controls is used to determine pagination of mobile web part pages. You can set the Weightless property of the SPMobileLabel control to true to exclude the control from the pagination calculation. The PhoneCall control is a standard ASP.NET control that renders the phone number on the device differently, as explained earlier, depending on the device’s capabilities.

12.4. Summary

Building mobile support for your Web Parts can significantly affect the availability of your SharePoint solutions. Even though many devices support the full SharePoint interface, the mobile network bandwidth is limited in some places and the roaming costs for mobile devices are quite high. The mobile SharePoint interface can reduce costs by generating content and Web Parts that require less bandwidth.

The control adapters you built in this chapter use a timer job and a Feature receiver to deploy the control adapters and the browser definition files to the web applications. Although it might seem like a lot of steps, once you have done this you can reuse the solution for all your mobile adapters.

In the next chapter we’ll take a look at Web Part development from a design principles perspective and you’ll learn how to make testable and configurable solutions.