SHAREPOINT 2013 APP MODEL

You can install SharePoint in two primary ways. As with SharePoint 2010, you can install the full version of SharePoint Server and have all of your assets and content running in an on-premises environment. Alternatively, you can provision an instance of Office 365 (O365) and then take advantage of SharePoint Online (or a cloud-hosted version of SharePoint). You saw some examples of SharePoint Online in Chapter 1, “Introduction to SharePoint 2013,” and you’ll see more in this chapter. Irrespective of how you deploy your SharePoint instance, the new app model for SharePoint holds true for both on-premises versions of SharePoint (SharePoint Server) and cloud-hosted versions (O365).

Although you have the ability to manually create SharePoint 2013 site collections and configure and brand those sites to your business needs, this book is about development. One of the key evolutionary areas in SharePoint 2013 is the new app model. You implement the new cloud model, broadly speaking, through the creation and deployment of either Apps for SharePoint or Apps for Office.

Apps for Office

Apps for Office are a new breed of Office 2013 applications that use a nonmanaged code approach to building in-context document and mail apps (think Excel, Word, and Outlook add-ins). These apps enable you to use HTML, CSS, or JavaScript to build lightweight apps that integrate with cloud-based apps. The cool thing here is that you can use a rich JavaScript object model to integrate with parts of the document or mail item. Apps for Office consist of a web page plus an XML-based configuration file called a manifest file, which configures items such as links to an external website, permissions, and so on. You can think of Apps for Office as web apps.

Although Apps for Office primarily target Office, you can integrate them with Office 365, documents, and mail items — artifacts that might in some way integrate with SharePoint. Figure 2-1 shows an example of an App for Office. In this example, the App for Office is integrated with the mail and it displays data from a Windows Azure SQL database within the mail item: Related Requests from Chris Johnson.

FIGURE 2-1

Apps for SharePoint

Apps for SharePoint (or SharePoint App) is the official name for apps you build and deploy to SharePoint. For those familiar with SharePoint, think of the SharePoint App as the evolution of the SharePoint Solution (that is, WSP). As mentioned in Chapter 1, the SharePoint App uses the .APP extension (whereas the SharePoint Solution uses .WSP).

The SharePoint App is a move toward a more cloud-centric development model — one where the code does not reside on the same server as SharePoint. This is a result of a greater migration of code to the cloud and a need to architect a platform to support smother updates and code that is loosely coupled to SharePoint and deployed to the cloud, as well as to mitigate the growing problems that server-side code typically presents (for example, performance and site-loading issues if the code is not properly written, deployed, or tested). Figure 2-2 shows an example of an app for SharePoint that integrates Windows Azure data — in fact, the same data that is being consumed in the app in Figure 2-1 is likewise integrated with SharePoint in Figure 2-2.

FIGURE 2-2

As mentioned earlier, when you build an app for SharePoint, you are building an .APP file. In reality, the .APP file is a “package” of files similar to a CAB file. Within the .APP package are a number of key files that are primarily made up of configuration files and libraries. For example, Figure 2-3 illustrates an .APP file that is created when you build and publish an app for SharePoint (you will walk through this later in this chapter). If you change the .APP extension to .ZIP you can see that the .APP consists of a number of files and another ZIP file. The zipped files represent the web portions of your SharePoint application, whereas the XML files represent more detailed configuration information for your app.

FIGURE 2-3

One of the key XML configuration files that you’ll see in both Apps for SharePoint and Apps for Office is the AppManifest.xml file. In this configuration manifest you’ll find key elements such as app meta data, app permissions and scope for those permissions, GUIDs for Web apps, and so on. The following code snippet shows a simple example of an AppManifest.xml file.

<?xml version="1.0" encoding="utf-8" ?>
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
     Name="AutohostedEmployeeList"
     ProductID="{125f9ba3-5efc-414a-ac53-023919ac2142}"
     Version="1.0.0.0"
     SharePointMinVersion="15.0.0.0"
>
  <Properties>
    <Title>AutohostedEmployeeList</Title>
    <StartPage>~remoteAppUrl/Pages/Default.aspx?{StandardTokens}
  </StartPage>
  </Properties>
 
  <AppPrincipal>
    <AutoDeployedWebApplication/>
  </AppPrincipal>
 
  <AppPrerequisites> 
    <AppPrerequisite Type="AutoProvisioning" ID="RemoteWebHost" /> 
  </AppPrerequisites> 
<AppPermissionRequests><AppPermissionRequest 
Scope="http://sharepoint/content/sitecollection/web" 
Right="Write" /></AppPermissionRequests></App>