SharePoint 2013 has added a bunch of new concepts for apps. You can think of a SharePoint app just like iPhone app or Android app for time being. If you have not already setup the on-premises development environment for SharePoint 2013 apps development, please follow the link Set up an on-premises development environment for apps for SharePoint to setup your development environment.
Install/Host an App
You can install the app in a SharePoint web (called host web for the app). When you install an app in the SharePoint web (called host site), the app needs a place to exist where app’s css, javascripts, pages etc will be placed. The app resources (like pages, css, javascript etc) are not stored/kept inside host web. Where the app’s resources are stored/kept basically depends on app’s hosting type. The app can be hosted in any of the followings:
- inside SharePoint (called SharePoint hosted)
- You can host app in Cloud. You have two options for cloud-hosting apps
- Windows Azure (called AutoHosted)
- Third-party solution providers can provide setup for apps (called Provider-hosted)
You can get more details on this hosting options at MSD link.
The app can add some links/actions (like ribbon, ECB menu etc) in the host web. But the app itself doesn’t live inside host site. When you use SharePoint hosted option for an app and as soon as you install the app in a host web another web (usually subsite to host site) is created (called app web) for the app components to be installed. The relation to host and app web for SharePoint hosted app, is shown below:
Figure 1: SharePoint hosted Apps are usually installed under subsite of Host web
For other options (like provider hosted and windows azure hosted app), app web is optional and the actual app web resources are stored in windows azure or third party servers.
Though app webs are installed under subsite of host web usually, for SharePoint hosted app, it doesn’t mean you can access the app web directly with url. Rather the apps are only accessible from different url. The App web is accessible from different url (not like host-web url). This is to keep the app webs isolated from host web. Usually these two types of webs urls (host and app web) belongs to two different domains. You can find more details on this host web url and app web url from this MSDN link.
App Types (From users’ points of view)
Now question comes what types of apps we can develop and how they will look like from user’s point of view. You can do the following types of things with apps:
UI Custom Actions
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. Let’s consider a scenario which will explain this UI custom actions in details:
- You installed an app (let’s call it SharePoint PDF Converter) in a SharePoint site http://mysite.mydomain.com/businessdocs (called host web). The app will add a ribbon button in the site to convert any word document to pdf. When you will install the app ‘SharePoint PDF Converter’, a subsite will be created under host web (http://mysite.mydomain.com/businessdocs) and the app contents (like javascript, css, aspx pages etc) will be deployed in the subsite. As mentioned already app webs are not accessible by url (like http://mysite.mydomain.com/businessdocs/appwebname) directly, rather they have different url for isolation. The idea of adding ribbon button in host web shown below:
Figure 2: An app can add ribbon to the host web. - Now what will happen on user will click the ribbon button? Usually user will be redirected to the app web and app developers have the option to pass the current selected item details (like id, url etc) to the app web. The concept of redirecting from host web to app web and having the app web taking control of the full browser page is called ‘Immersive Full Page’ user experience.
You can get more details on custom action app types on MSDN link Create custom actions to deploy with apps for SharePoint.
App Part
Apps can also add web-part like stuffs in the host web called Part (or app part). You can think of an ‘app part’ as like web part but it’s provided by app web. You can think of it as just like web part but instead of Farm WSP solution this app part comes from app deployment to your host web. You can find more details on this app part on MSDN link Create app parts to deploy with apps for SharePoint. The following image shows an app part that is available to be added in the host site:
Figure 3: Add an app-part (just like adding webpart)
Once you add the app-part the page will look like below which kind of resembles the webpart concept:
Figure 4: App part added to the page
Immersive Full Page
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 http://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, http://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. Basically Chrome control is kind of adding few components (js,div element etc) in App web so that when user redirect from host web to app web, the chrome control retrieves css, js from host web and apply it in the app web on the fly. Also the chrome control create a SharePoint 2013 ribbon bar in the app site, so that user can navigate back to the hot web.You can get clear idea of chrome control watching this video.