Developing Windows Phone 7 Applications that integrate with SharePoint data have a lot more in common with developing .NET Managed Applications for the desktop than writing SharePoint Pages or writing Silverlight applications that live inside SharePoint. That is to say while developing custom list templates or Silverlight parts inside SharePoint, these applications have direct access to the SharePoint Context. We will not have that ability in Windows Phone 7.
Although we can't use the managed DLL's that were provided for Silverlight applications in Windows Phone 7, we still have access to the same information and functionality. It's just going to be a lot more work to use them.
The client object model communicates to the server using WCF Data Services, formerly known as ADO.NET Data Services. We will use these same services for our Windows Phone dashboard application. As is the case with a lot of programming problems, there are multiple ways of attacking this problem.
Representational State Transfer, or REST, is a way of communicating with services across the Internet or intranet using standard HTTP verbs. Specifically, the common verbs used are GET, POST, PUT, and DELETE. Using simple HttpWebRequests, we can call on the WCF Data Services SharePoint exposes to perform most of the actions that the client object model would have made simple for us.
REST is a fairly generic term for accessing data across a network using a less stuffy format than SOAP. Responses from a REST call are usually either Plain Old XML (POX) or a fairly clean JavaScript Object Notation (JSON). The calls into SharePoint can return XML or JSON, but their output format is a predefined data structure that we'll discuss next.
In SharePoint, we can make calls to web services using simple HttpWebRequests. These calls use traditional REST semantics and return data sets either in JSON or in an open data format that Microsoft created named OData. In addition to the traditional REST semantics of using the HTTP protocols and URI strings to tell the server what our intent is with the call, OData defines a QueryString structure for refining our requests.
We make all these calls to the same URL http://<yourserver>/_vti_bin/listdata.svc/ and from this location we can gain access to all of the data in SharePoint. For example, to get all of the calendar items we can make a call to this URL http://<yourserver>/_vti_bin/listdata.svc/Calendar.
Now with the addition of the OData semantics, we can get just the top five calendar events:http://<yourserver>/_vti_bin/listdata.svc/Calendar/?$top=5 or even order the items by start date as follows:
http://<yourserver>/_vti_bin/listdata.svc/Calendar/?$orderby=StartTime&$top=5
Note
To get more information on OData, the best place to start is the official OData website located at the following URL:
In SharePoint, making these calls directly will probably result in a 403 Authentication required error. We'll use the authentication token from earlier in this chapter to make these calls. Also, even with the authentication token, we'll end up with an ATOM response.
ATOM is a data format that uses XML to deliver data. As it is XML based, it is fairly bulky across the wire. It is better than POX though because there is a well-defined schema for passing data through ATOM. That means that for clients accepting ATOM they don't need to know anything about the incoming data in order to deserialize it. Plain old XML requires a lot of knowledge ahead of time for the incoming data.
However, deserialization is a fairly expensive operation. To deserialize ATOM with no prior knowledge of the contents means a lot of reflection and creation of very heavy anonymous objects. Deserialization can come in the form of using the OData tools for Windows Phone 7 from Microsoft. The problem with these tools is they don't support authentication today. On a mobile device, we may be better advised to use alternative methods of getting information.
When making the call to the SharePoint server, we can specify that we accept JSON as a response. This will cause SharePoint to return a JSON string. This string is usually half the size of the ATOM string coming across the network. That's a good thing for mobile devices. Deserializing JSON has some of the same problems as ATOM though in creating heavy objects through reflection. There's a built-in JSON deserializer in the System.Runtime.Serialization.Json namespace, but an alternative open source tool named Json.NET is smaller, faster, and easier to use.
In the examples provided in this chapter, we will use LINQ to XML to get just the data we need from an ATOM feed, but when building larger applications you may need a more robust toolset and it is important to know that they are out there. My personal recommendation is to use JSON and the Json.NET deserializer. Since Windows Phone 7 development is still young, other tools will come along to make all of this easier. However, this all depends on the application being built. Sometimes, we just need something that works.
ASP.NET Web Services should be considered deprecated. In SharePoint 2007, this was an excellent way to communicate with the server. With SharePoint 2010 though, the web services have been pushed aside for the newer WCF Data Services. The ASP.NET Web Services used SOAP to securely communicate with the server and get responses back. This made the requests and the responses really heavy, which would not be good for employees on a small data plan with their phone. By using more modern techniques, such as REST with JSON, it is very common to see a decrease in network traffic by up to 10x. JSON may be a little slower to deserialize on the phone, but it is much faster than waiting for a large XML package to come across the network.