As industry-leading SharePoint consultants, we provide strategy, create and implement solutions, and offer ongoing support across the SharePoint platform.
As the popularity of SharePoint Online (Office 365) continues to grow, SharePoint developers must begin to approach development of custom applications from a different angle. The biggest challenge that developers face in this new arena is that SharePoint farm solutions built using server-side code like C# cannot be deployed to Office 365 environments. Therefore, any custom functionality must be developed using the SharePoint app model that was introduced in SharePoint 2013.
This new paradigm for SharePoint development certainly presents a learning curve for developers that will take time to conquer. However, some aspects of this shift will also make things easier. Foremost, SharePoint developers don’t need to setup virtual machines with full-scale SharePoint environments to build SharePoint apps for Office 365 as is required for on-premises development. All that is needed is Visual Studio 2012, or later, and an Office 365 SharePoint site collection where apps can be deployed and tested.
SharePoint App Hosting Models for Office 365
There are two hosting models available for SharePoint Apps for Office 365: SharePoint-hosted and Provider-hosted. The biggest difference between these two models is that SharePoint-hosted apps are installed on and execute within the Office 365 SharePoint site, while Provider-hosted apps are installed on the Office 365 site but require a remote web application, running on either an on-premise web server or Microsoft Azure, where the app is actually executed.
Developing SharePoint-hosted apps is the focus for this tip, so let’s explore that model a little further.
SharePoint-Hosted Apps for Office 365
Since all of the components of SharePoint-hosted apps are hosted on the Office 365 SharePoint site and server-side code such as C# cannot be deployed to Office 365, SharePoint-hosted apps can only contain code that runs on the client-side such as JavaScript (with the SharePoint 2013 JSOM library) , HTML, REST Services, etc. Furthermore, since client-side code runs in the browser, user interaction is required for the code to execute. Therefore, a SharePoint-hosted app could contain a custom form that adds items to a SharePoint list when the form is submitted by the user, but not a timer job that runs automatically every night at 11:00 PM.
Host Webs and App Webs
When a SharePoint-hosted app that contains SharePoint components (i.e. app parts, custom pages, custom lists, etc.) is deployed to an Office 365 site, the app is available from the Site Contents page on the host web where it can be launched. However, the app itself, along with any lists, content types, pages, etc. is deployed to a special website that has its own isolated domain called the app web. Even though the app web has its own isolated domain, the app web and host web are contained in the same site collection.
For example, suppose that an app, with SharePoint components beyond just the UI elements that can be deployed to a host web, is installed on a host website at the following URL:
https://ourcompany.sharepoint.com/sites/Sales
The app for SharePoint will be deployed to app web with a URL like the following:
https://ourcompany-bdf2016ea7dacb.sharepoint.com/sites/Sales
Notice that the app web URL contains the App ID (bdf2016ea7dacb), which is a hexadecimal number generated when the app is installed.
Cross Domain Library
The fact that the client-side code runs in the app web, yet may need to access data from the host web presents an interesting set of challenges for developers. For security reasons, modern browsers include blocking mechanisms that prevent client-side code from communicating across domains. Therefore, by default any client side code running in the app web that is trying to retrieve data from the host web will be met with an “Access Denied” error when executed.
The solution to this challenge is to take advantage of the Cross Domain Library. The Cross Domain Library is a JavaScript file (SP.RequestExecutor.js) that can be referenced in client-side code that runs in the app domain that allows the remote app to successfully access data on the host web.
More information about implementing the Cross-Domain Library, as well as code samples, can be found at http://msdn.microsoft.com/en-us/library/office/fp179927(v=office.15).aspx.
Developing custom applications using the SharePoint 2013 app model, especially for Office 365, forces SharePoint developers to tackle familiar tasks in a new manner. It also forces developers out of the comfort zone of relying on server-side code to do the heavy lifting in our applications. While JavaScript may have once been used only for interacting with UI design elements, SharePoint-hosted apps built using the SharePoint 2013 JavaScript object model or REST OData services provide a framework for building custom SharePoint functionality for Office 365 that is not only powerful, but also easy to setup, build and deploy.
This SharePoint Tip of the Month contributed by SharePoint Architect Rob Aycock.