CHAPTER 9 Intro to Client-Side Development
Thankfully, client-side development has received some much-needed attention, and SharePoint 2010 touts some significant improvements over its predecessor. The client-side development experience now targets a broader audience, includes out-of-the-box support for multiple user experiences, and offers us a better choice of application programming interfaces (APIs) to work with.
In this chapter, we’ll cover the following topics:
• Why Go Client-Side?
• Client Application Landscape
• Client Application Models
• Accessing Data with Services
• The Client Object Model
Why Go Client-Side?
We’ve had a robust server-side API in SharePoint for years, and we can already customize just about any aspect of SharePoint we want. So why is client-side development suddenly becoming so important? What’s changed? And why should we care?
One big change is the subject of this app: SharePoint Online and Office 365. SharePoint Online represents a new paradigm in how SharePoint is offered and in how we develop solutions for it. We learned in Chapter 8 that if we want to develop for SharePoint Online, our only option is sandboxed solutions. Sandboxed solutions, as you might recall, don’t give us access to the entire server-side API. Client-side development can help us get back some of what we’ve lost (and in some cases is our only option).
Of course, sandboxed solutions aren’t the only reason to prefer client-side development. Other reasons include the need to access SharePoint data from outside of SharePoint or a desire to build richer user interfaces (UIs) with technologies like Silverlight and jQuery.
Client Application Landscape
Before delving into the details of client-side development, let’s focus for a moment on the big picture. It’s helpful to think of client-side development as having two facets: the way we interact with the user (the user experience) and the way we get data to and from SharePoint. Collectively, we refer to these two facets as the client application landscape.
Figure 9-1 illustrates the client application landscape for SharePoint Online.
Figure 9-1. Client application landscape for SharePoint Online
Note The BCS Client Runtime Object Model isn’t pictured in Figure 9-1 because it isn’t available in SharePoint Online (even though it is available in SharePoint Server 2010 for client-side access to BCS)
On the data access side of the landscape, we have two new APIs that weren’t available to us in SharePoint 2007: the REST API and something called the Client Object Model. Both will be discussed in more detail shortly.
Likewise, on the user experience side, we now have better out-of-the-box support for rich client applications. SharePoint Online includes a Silverlight web part for hosting Silverlight applications (XAP files) in the browser. Additionally, the new REST and Client Object Model APIs let us build rich client applications much more easily. By taking advantage of technologies such as WPF, Silverlight, and jQuery, we can now focus more on building compelling user interfaces and less on the mechanics of getting data in and out of SharePoint.
Client Application Models
When we’re doing client-side development for SharePoint Online, we have two application models available to us: the in-browser (rich Internet application [RIA]) application model and the rich client application model.
The in-browser application model is pictured in Figure 9-2.
Figure 9-2. In-browser (RIA) application model (Source: http://bit.ly/Lh6Vkz)
As you can see in the figure, one defining characteristic of in-browser applications (including Silverlight applications) is asynchronous communication with SharePoint. Asynchronous communication means that when the code makes a request of the server, it doesn’t wait to receive a response because doing so could cause the browser to become unresponsive. Instead, it makes the request in the background and continues executing the rest of the code while the request is being made. Eventually, the code is notified that the request has completed and can take appropriate action. The trade-off with asynchronous communication is the UI is more responsive, but the code is a little more complicated to write (as you’ll see later).
Now consider the rich client application model pictured in Figure 9-3.
Figure 9-3. Rich client application model (Source: http://bit.ly/Lh6Vkz)
In this case, the application isn’t limited to using only asynchronous communication with the server. If you’re writing a Windows Presentation Foundation (WPF) application, for instance, you can use synchronous communication, in which you make a request of the server and then wait for a response before continuing. You could show a progress bar or other wait indicator while the request is being made and avoid the complexities of asynchronous communication. The UI may not be quite as responsive, but the code is also simpler to write.
Accessing Data with Services
SharePoint Online includes two types of services you can use to access data: REST-ful services (or REST interfaces) and ASP.NET web services (also known as ASMX web services).
Using the REST-ful Services
A REST-ful service is one that implements the Representational State Transfer (REST) design principles. A core concept of REST is the idea that resources (such as lists and list items in SharePoint) can be represented as HTTP resources addressable by remote uniform resource indentifiers (URIs). They can also be manipulated by create, retrieve, update, and delete (CRUD) operations that are mapped to the HTTP verbs POST, GET, PUT, and DELETE, respectively. You also get support for retrieving list information in several formats, including JSON, ATOM, and ATOMPub.
SharePoint Online exposes two REST-ful services. The first is a REST service for working with lists and libraries (and their contents).
To see which resources are available to you through this service, you can type a URL like this one into your browser (note that you must have logged into SharePoint Online first and be authenticated):