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!

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.

Did you ever try to connect a list feed to a SharePoint RSS feed web part? Well, I did, and it doesn’t work. The web part returned me a redirect error on public Internet sites and an authentication problem on secure Intranet sites.

The RSS web part is not able to handle secure RSS connections. After some debugging the problem of the redirect error was found in the fact, that certain RSS feeds are trying to return a cookie, which a web part normally does not accept. Because the cookie is not set, the RSS generator keeps redirecting the download request.

The cookie and authentication problems do not only apply to the SharePoint list feed, but also to a lot of other feeds on the internet.

The work around

To get correct RSS feeds in the standard SharePoint RSS feed web part, I’ve chosen to develop a small “proxy” handler to access the feed in Visual Studio.

To create the proxy, we’ll start with adding a “Generic handler” file to an empty web project. The generic handler item uses the extension .ashx. I won’t recommend using the normal “Web Form” (aspx) template, because it uses more resources than the simple handler. We simply don’t need all the page rendering technology of a web form to return some xml. Keep it light and simple!

The generic handler implements the IHttpHandler which defines 2 functions. The “IsReusable” boolean function is used to indicate if a single instantiation of our IHttpHandler can be used to process multiple concurrent requests. We will just leave this value on it’s default “false” value. The second function, the “ProcessRequest” function, is where all the magic happens.

In our “ProcessRequest” function we’ll add our code to download a RSS feed. Once we downloaded the feed we will pass it back to the browser or web part. Because we are controlling the download process of the RSS feed, we can now add additional code, that the standard web parts don’t have. We can add a cookie bag to accept cookies and we can set a higher redirect value to allow more redirects. If you bought a news RSS for your intranet which requires login credentials you would also be able to add them to the proxy code.

Of course, in our real project, we made the proxy a lot smarter. For example, I won’t recommend using a hardcoded RSS url inside the code.

If we host the proxy inside a secured SharePoint environment, there is a nasty little problem left; The standard RSS web part is not able to download RSS feeds that require login credentials. Because the proxy is located inside the secure SharePoint environment, IIS requests credentials from the web part. To fix this last step we have to tell IIS that the proxy file is allowed to be accessed anonymously.

Open the IIS manager on the server and locate the proxy file inside the web application. Now right-click the file and request it’s properties. Open the “File Security” tab and click the “Authentication and access control” Edit button. Just check the checkbox on the top to enable the anonymous access.

That’s it, save the settings and reset IIS. Now we only have to point the RSS web part to the ashx http location, and the feed will be downloaded!

The Web Part is called SPUserPoll and it allows site users to quickly create polls anywhere in the Site Collection. The poll Web Part is designed to provide a user friendly interface: Important settings and actions are available from within the Web Part. There is no direct need to work with the SharePoint Web Part setting menu and poll data is managed from normal SharePoint lists. Administrators can manage and keep track of all created polls from a centralized list.

I know that a standard SharePoint installation also comes with a polling mechanism as part of the Survey Lists, but these surveys are complicated and require quite some time to configure. The SPUserPoll Web Part allows users to setup a single topic poll within a few minutes.

This first release provides the basic functionality with text-based results. In later releases more functionality and bar & pie charts will be provided. I hope to receive feedback from you on my project: wishes, ideas and tips for the project are welcome. My initial roadmap for the project is provided below. You can download the first release at the CodePlex site.

Project roadmap:

Version 0.1

Initial version

Version 0.2

Deployment of poll images
Bar results
Poll Closingdate
Caching

Version 0.3

Multiple answers
Input validation
Anonymous voting
Css file

Version 0.4

User customizable graph colors
Multilanguage
Remove attachments option from created poll lists

Version 0.5

Support for Internet sites
Delete poll and the poll’s lists from the Admin list
Print results
Poll preview (before publishing)

Version 0.6

Pie results
Option to hide the “show results” link before a user has voted

Version 0.7

Export poll data to csv/excel

Version 1.0

Documentation

Since Moss2007 you can implement your own connection interface which enables you to connect customized web parts. It looks like you can basically transfer any serializable information.

The first thing you have to do is to define a very simple interface. The second step is to inherit the interface at the web part class that sends the information. In this class you’ll have to assign the interface as the connection interface. The last step in the provider web part is to include the “get function” described by the interface to pass the value.

In our consumer web part we have to retrieve the connection interface. Once this connection has been setup we can read and use the given value.

In the example code we will use the interface with the name “IMossStringConnection” to pass a string value.

Our web part and interface that provides our custom value:

And here is the code for the web part that consumes the provided value:

And that’s basically all the code you need to implement. Just copy and paste it in your web parts and have some fun!