Freigeben über


Part 3 - Apps Hosting and Branding

This post is in continuation to my previous posts about SharePoint 2013 App Model. You can see the previous posts here:

Before we get into the details of building useful apps using SharePoint 2013, we need to go over the app model architectural overview.

Apps for SharePoint hosting options

The SharePoint 2013 app model provides two broad approaches to hosting your apps for SharePoint:

  • SharePoint-hosted
  • Cloud-hosted

Within the cloud-hosted approach there are two important subcategories:

  • Provider-hosted
  • Auto-hosted

 These are not exclusive categories: An app for SharePoint can have both SharePoint-hosted and remotely hosted components. Each approach has key features you should consider when deciding how to host your apps.

SharePoint Hosted App

 

Figure 1: SharePoint-hosted apps

SharePoint hosted app runs within the context of SharePoint, but there is no server side code. Any kind of logic is going to run in the client side using JavaScript. You can leverage some of the SharePoint artefacts like lists, document libraries, pages without code behind and out of the box web parts. SharePoint-hosted apps for SharePoint are installed on a SharePoint 2013 website, called the host web, and that have their resources hosted on an isolated subsite of a host web, called the app web.

Cloud-hosted apps

 

Figure 2: Cloud-hosted apps

In cloud hosted apps, the logic resides outside of SharePoint. The logic can reside either on IIS server OR Windows Azure OR some other cloud solution and it is going to talk to SharePoint using client side object model (CSOM) or REST services and have to be granted permission to SharePoint using OAuth.

Within this category there are two types of apps:

  • Provider hosted

Provider-hosted apps for SharePoint includes components that are deployed and hosted outside of the SharePoint farm, usually by the developer. The provider-hosted app for SharePoint interacts with a SharePoint 2013 site but also uses resources and services that reside on the remote site.This approach enables you to use any hosting service you want, but it places the responsibility for creating the installation, upgrade, and uninstallation logic of the remote components on the developer.

  • Auto-hosted

Apps that include a Windows Azure Web Site, and possibly also a SQL Azure database, that are automatically installed when the app is installed. The Windows Azure web site and optional SQL Azure database can be included in app package, such that when you provision the app, it automatically creates Windows Azure web site and optional SQL Azure database in Azure. If you are using auto hosting for your app, each installation of the app provisions its own Windows Azure web site. The Windows Azure web sites infrastructure handles load balancing, multi-tenancy, and other important maintenance tasks for you.

 

Note: Cloud-hosted app is the most preferred hosting model for almost all apps. You can get full power of the web, you can choose your infrastructure and technology, you can run in IIS or in Windows Azure or even on other non-Microsoft infrastructure. Whereas SharePoint hosted apps is good for smaller apps with limited resource storage.

 

App Shape and Branding

 When you build SharePoint apps, one of the design decision is how apps are going to look like and be presented to the user. To design the user experience of the app, you need to understand the following:

  • App Shape
  • Branding

 Apps for SharePoint fit seamlessly into the SharePoint website where they are installed.

 

Figure 3: App Shapes option

As shown in figure above, the apps can have three possible type of shapes:

Immersive: An app for SharePoint provides a fully immersive experience and optionally can extend some of the existing UI, such as in menus, or by providing embeddable parts for other pages. Immersive apps will take entire browser experience.

 App Part: App parts surface an IFrame element that contains content from your app. Imagine these apps as the ones which add something like a web part to the SharePoint site e.g. weather monitor app. An App Part is nothing but a type of Web Part that is represented by the ClientWebPart class. This kind of Web Part is essentially a wrapper for an IFrame that would host a page of the app.

 Extension App: You need to use extension app when you create new actions for documents or list items. Ribbon or context menu extensions make your app available on list items, documents, or anywhere else a ribbon is shown. An app can add links like ribbon, custom actions or ECB menu to the host web. When user will click on the link, user will be redirected to the app web.

 All apps have a default page which might take the full page. Apps show custom action or app part in the host web. The app might take the full page by redirecting user from host web url to app web. For example, the host web url is https://www.hostweb.com and an app is installed in the host web which adds a custom action. When user clicks the custom action, the user will be navigated to a new url (say, https://www.appweb.com). So the app takes the full page (so it’s called Immersive Full page). However user will not notice the url changes as the new app site will have the same UI look and feel. The idea of having the app web to have similar look and feel like host web is achieve thorough a new concept in SharePoint 2013 – called Chrome Control. This is a javaScript based object that allows custom app to consume and import the css and stying of the hosting parent appweb. Also the chrome control create a SharePoint 2013 ribbon bar in the app site, so that user can navigate back to the hot web.

 

 Figure 4: Chrome control in a web page

 Apps Branding

Microsoft has recommended design process as well as basic guidelines for developing quality user experiences for apps. Refer to this link UX design for apps in SharePoint 2013 to understand the recommended UX design process for apps for SharePoint.

 Developers are going to primarily use three different types of branding:

App Template: The app template is the default branding option in Visual Studio when you create an app web and pages within that web. The app template can be used only for SharePoint-hosted ASPX pages. The template includes the app.master master page.

 Chrome Control: This is a JavaScript based object that allows custom app to consume and import the css and stying of the hosting parent appweb. If you’re not building SharePoint-hosted ASPX pages, but you still want your app to fit in naturally with the host site that it is used from, the chrome control is the right choice.

Custom Branding: If, instead of aligning to the host site’s theme and fitting into the SharePoint site where your app is installed, you want to use your own brand inside your app, you will have to build your chrome from scratch. However, you should still have a "back to site" link in the upper-left corner of the page that redirects the user back to the site where the app is installed.

In the next post, I will mention about details around SharePoint Hosted apps.

Comments

  • Anonymous
    February 09, 2013
    Nice and very informative article.Information on when to use Provider Hosted and Auto hosted is much useful.Thanks for sharing this.Customizing Suite Bar: blogs.msdn.com/.../sharepoint-2013-customizing-suite-bar.aspx
  • Anonymous
    May 06, 2014
    Thanks a lot...Nice Article
  • Anonymous
    June 26, 2014
    Very informative article Amit. Hope you don't mind using your article as a reference :)
  • Anonymous
    August 07, 2015
    Very informative and easy to understand article.