CHAPTER 9 Intro to Client-Side Development

Let’s face it. The client-side development experience in SharePoint 2007 wasn’t  exactly the best.  While we had  some web services we could work with, we really didn’t have much else. If we needed more capabilities than what  the web services provided, we were basically left with creating our own web service. Unfortunately, that left out a lot of developers who specialize in client-side technologies such as JavaScript and  who weren’t accustomed to web service 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:


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:


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):