The mobile rendering engine of SharePoint provides mobile users access to the sites with a completely stripped interface. Its main function is to list all libraries and to provide basic access to them. For wiki and blog sites the rendering engine also provides some content rendering.

To keep the amount of data as low as possible, almost all web parts are completely stripped from the mobile site. Only when a web part developer provided a special mobile version of the web part, the web part will be accessible in the interface and to keep the mobile screen as empty as possible, the user must first expand the web part via its title to see it.

Documentation about SharePoint Mobile development is provided at MSDN. At first it all looks quite complex, but building a mobile version of a web part is actually not that hard. Below I will explain the required steps with a ‘Hello world’ example. For this sample I will not rename the default object names provided by the Visual Studio templates.

Create a sample site

In this sample we begin with a fresh empty site. Create a new “Blank Site” and call it “Mobile Demo”.

Create a Visual Studio 2010 Visual Web Part Project

Visual studio 2010 includes a full set of SharePoint templates. These templates automatically publish and debug the project to your SharePoint environment.

Start a new “Visual Web Part Project” and name it “MobileWebPartDemo”.

Add a literal with the “hello world” message

We will now create the normal SharePoint web part. We only show a sample message by adding a literal to the web part controls.

Open the class file “VisualWebPart1UserControl.ascx.cs” and add the following code to the load event:

Build and add the web part to the page

Press F5 to compile and build the web part. Internet explorer will start. Browse to the “Mobile demo” sample site and open the default page in edit mode. Add a new web part. Inside the “Custom” category you will find our demo web part. Add “VisualWebPart1” to the page.

Preview the site

Exit the edit mode of the page. You will now see your site and the web part as normal users will see it.

Preview the mobile site

To view the web site in mobile view, type a “/m” after the normal site url. For example: “http://localhost/mobiledemo/m/”.

At this moment the website is rendered in the mobile view. But hey! We don’t see the web part we just published. This is because the engine strips all normal web parts to keep the data transfer as low as possible. Only mobile optimized web parts will be shown.

Create the mobile (adapter) version of our web part

To add our web part to the mobile version of the site we must provide SharePoint with a mobile optimized version of our web part. We do this by adding a new class. Microsoft calls this class an adapter.

Add a new class and name it “VisualWebPart1MobileAdapter.cs”. Note that we added the name of our web part in front and added the text “MobileAdapter” at the end.

Microsoft recommends to use the namespace “SharePoint. WebPartPages.MobileAdapters” so modify the namespace to use “MobileWebPartDemo.SharePoint.WebPartPages .MobileAdapters”.

Our class should inherit the “WebPartMobileAdapter” class.

The adapter does not use the “OnLoad” event. Instead it uses the “CreateControlsForDetailView” to render. Override this class and add the following code:

Add the adapter to the safe controls

SharePoint should know that the adapter web part is a safe control. We did not have to add the normal web part as safe control, because the project template already fixed this for use. However, we still have to add the mobile version.

Open the web.config file of your SharePoint IIS site (example: C:\inetpub\wwwroot\wss\VirtualDirectories\80) and add the line below into the safecontrols section. Replace the PublicKeyToken with your own key!

Configure the compat.browser file to use our mobile web part

SharePoint must be told that there is a mobile optimized version available for our web part. Basically we are going to tell SharePoint that if there is web part “Normal” on the page, it should load version “Mobile”. Without this configuration SharePoint would just strip our web part like before.

Inside your SharePoint IIS directory you will see a directory “App_Browsers” and inside that directory is a file called “compat.browser”. Load this file in the editor.

At the top of this file you will find a “controlAdapters” section. Add the line below to this section:

Again, replace the PublicKeyToken with your own key! Safe the configuration and exit the file.

Rebuild the project and reload the mobile demo site

We finished the required steps to provide SharePoint with a web part that is optimized for the mobile page. Press F5 to build and deploy our project and re-open the mobile view of our demo site. And wow it’s almost magic! The title of our web part has suddenly appeared.

Expand the web part

To keep the mobile screen as empty as possible, not all web parts are automatically visible. Just click the title of the web part and it will be rendered.

And that’s it. This is all the information required to start developing web parts for the SharePoint Mobile pages. Enjoy!

The problem was that after a search in the search center was performed, the browser would not navigate any further for 1 or 2 minutes. Finally this blog of Sourav provided the right solution.

Since the Infrastructure update, search has been extended with Federated search. The default setting for the federated search results, is to query the online OpenSearch for results. This is fine as long as the web server has internet access, but if internet access is restricted, performance problems will occur in the SharePoint environment. The solution is to alter the configuration and set Federated Search to use the local Index. Basically you’ll have to decide if you would like to use OpenSearch and enable internet access for the server, or keep it locked and use the classic index.

Somehow Microsoft did not include any clear instructions with the Infrastructure update about this new default setting and possible implications for non internet enabled servers. If your Search center is experiencing performance issues, check out Sourav’s blog posting for a possible solution and detailed steps to solve it.

This script can be added to the itemstyle.xsl for use. I’m always copying it from older projects, so now it’s on my blog for faster access

“During the installation of SP2, a product expiration date is improperly activated. This means SharePoint will expire as though it was a trial installation 180 days after SP2 is deployed. The activation of the expiration date will not affect the normal function of SharePoint up until the expiration date passes. Furthermore, product expiration 180 days after SP2 installation will not affect customer’s data, configuration or application code but will render SharePoint inaccessible for end-users.”

The team is working as hard as possible to release a hotfix to address the issue.

The Work around is also known: Re-enter the Product ID numbers on the Convert License Type page in Central Administration.

More information at the Microsoft SharePoint team site.

It required me to dig deeper and .Net reflector turned out to be the right way to go. Microsoft made a lot of the required functions internal, which means that we cannot access the functions from our own code. By analyzing the steps I was able to add item scheduling on the pages library with the code below.

Step 1: Enable Moderation and Minor versions
To allow item scheduling, we must enable moderation and minor versions on the pages list.

Step 2: Register Scheduling Events
The item scheduling requires us to register 2 events.
First we will retrieve the assembly and class information of the ScheduledItemEventReceiver and then we will create the 2 events.

Step 3: Unhide the startdate and expirydate fields
The list already contains the startdate and expirydate fields, but they are hidden. With the following code we will unhide the fields.

And that’s it. With these coding steps we enabled item scheduling at the Page library.