SharePoint-Hosted Apps are also known as client-side Apps. This article lists the components of a client side App and introduces useful SharePoint Web Parts such as the Client Web Part and the Chrome Web Part. Although client-side Apps can only execute client-side code the improved client object model (CSOM) and script libraries such as jQuery make client-side Apps very powerful.

What is a SharePoint-Hosted App?

A SharePoint-Hosted App is a custom SharePoint 2013 component, built using Web technologies, and stored completely within the SharePoint content database. SharePoint-Hosted Apps are also known as client-side Apps because they can only execute client-side code, which is code that executes in the browser, not on a SharePoint server. This architecture ensures that client-side Apps do not threaten the stability of SharePoint servers or monopolize server resources. However, because the CSOM has been greatly extended in SharePoint 2013, the client-side approach does not limit the capabilities of Apps. In fact a SharePoint 2013 client-side App is more powerful than the sandboxed server-side solutions you may be familiar with in SharePoint 2010.

Parent Sites and App Sites

When a user or administrator installs a client-side App in a SharePoint site, SharePoint automatically creates a sub-site in which it installs all the pages, code, and markup that make up the App. This sub-site can include SharePoint lists, libraries, content types, items, and other objects that you define using CAML in the App's code. This approach to declarative objects has not changed for SharePoint 2013. It is easy to write CSOM JavaScript code to access all the items, lists, and libraries in the App Site. This architecture ensures that client-side apps are self-contained. When you remove a client-side app, the sub-site is removed and nothing remains in the parent site. This clean removal process is a significant advantage of apps for SharePoint.

Types of Client-Side App

Client-side Apps are of three kinds, depending on the location in the SharePoint user interface where you will find them:

Building SharePoint-Hosted Apps

SharePoint-Hosted Apps differ from solutions for earlier versions of SharePoint in that their code runs entirely in the user's browser on the client-side. This has two advantages:

User Interface

Client-side Apps display their user interface in the browser so you must design and style that user interface by using HTML and CSS just as you would design and style a stand-alone Web page. Create elements that users can click on or type text into or interact with in other ways. You will use a script to respond to these events.

Scripting Language and Libraries

Code that responds to user input and executes logic in a client-side app is written in JavaScript and runs in the browser. JavaScript is not compiled to machine or managed code but instead is interpreted, at run time, by the JavaScript engine in the browser. Most Web browsers support JavaScript although there are differences in their implementations. Several script libraries make it much easier to write JavaScript code that accesses SharePoint 2013. Some of these are exclusively used with SharePoint, others are general libraries intended for scripting on any Web page but useful in Apps:

Structure of a Client-Side App Project

Visual Studio 11 includes a project template for creating apps for SharePoint. The following shows a new project created from that template in Project Explorer and illustrates its structure. It includes the following elements:

Using Built-In Controls

There are two user interface controls frequently used in SharePoint-Hosted Apps. These controls make it easy to integrate your App with the SharePoint user interface and present a consistent look and feel.

The Client Web Part

SharePoint 2013 includes many Web Parts and you can add your own because the SharePoint solutions you are familiar with from SharePoint 2010 are still supported. Web Parts are helpful because they enable users to modify SharePoint pages to their own requirements without writing any code. Web Parts can be moved around a page and connected by users to build dashboards that present data. Apps for SharePoint are not Web Parts however, by using the Client Web Part that comes with SharePoint 2013, you can present them as a Web Part that users can add to pages wherever they need them. The Client Web Part therefore distinguishes Web Part Apps from Full Page Apps and Command Extension Apps. This Web Page enables apps to behave precisely as Web Parts do in the SharePoint user interface.

The Chrome Control

SharePoint 2013 comes with a default look and feel that consists of colors, fonts, styles, and menus in various locations on the page. Site templates and themes can alter this look and feel. In addition, power users and developers may have created custom master pages that impart completely new styles on their sites. In fact a SharePoint page may not look like the default scheme at all. This presents a problem to developers who want an App to blend seamlessly into any site. If, for example, you hardcode your style to look like the default SharePoint style it will work well when no design changes have been made. However, in the many sites where branding is in place and styles have been altered your App will stick out and present an unpleasant contrast in presentation. You can use the Chrome Control to overcome this problem. The Chrome Control downloads a copy of the style sheet used in the parent site and applies it to the HTML pages in your client-side App. You can use this control to automatically inherit styles from the parent site and can blend with any site where users install your app. The Chrome Control also helps the developers by making it easy to create menus within apps for SharePoint. This is a very rapid way to build navigation into your custom App.

Cross-Domain Calls

In Web site development, cross-domain scripting is a technique used by attackers to inject their own scripts into other site's Web pages. By using this technique a hacker can compromise security, gain access to other users' details, or create a denial-of-service attack. Therefore most Web servers and applications will not run any script that does not originate from a local site. They consider any script from another site to be untrustworthy. However, when you build apps for SharePoint, whether it is a client-side, server-side, or hybrid App, you frequently need access to data in other sites. For example, as you have seen, a client-side App exists in a separate sub-site within the parent site where it was installed. A client-side app frequently needs to display data from lists in the parent site. Ordinarily this would be considered a cross-domain call and the parent Web would deny access. SharePoint 2013 provides a secure way to register and enable cross-domain calls for a limited set of well-known sites, so that Apps, parent sites, and other sites can trust each other and access each other's data.

Coding Cross-Domain Calls

SharePoint 2013 includes the following components that you must use to enable secure cross-domain calls:

The App requests the AppWebProxy.aspx page from the parent Web and loads it into a hidden IFrame in its user interface. The App also includes the SP.RequestExecutor.js library. In your custom App scripts, you can call functions in that library. These functions communicate with the AppWebProxt.aspx in the Parent Web. This page can access list items in the parent Web and return them, through the SP.RequestExecutor.js library to your script.