By Matt Ingle
In order for your app to talk to SharePoint, it will use Web Service entry points. Your server-side code runs on a remote box and you callback to SharePoint through the OData based remote API. OData is a standard, so you will be able to choose any programming language like C#, Python, Ruby, Java, or PHP.
Microsoft provides support for apps in Office 365 and in on-premises farms. You app code will be authenticated and have an established identity. The app’s permissions will be independent of the SharePoint user’s permissions. In addition, developers will deploy apps to catalogs and they will be easy to locate, install, and upgrade.
To understand why Microsoft has provided a new way to develop in SharePoint let us look at the current issues with SharePoint solutions.
· The code running inside SharePoint poses risks and can affect scalability.
· Dependent DLLs make it difficult to upgrade SharePoint.
· The SharePoint user’s identity is the basis for a solution’s permissions. You cannot configure permissions for the solution apart from SharePoint.
· It is difficult to manage installation and upgrade of solutions.
So what is different compared to SharePoint 2010 development?
Actually nothing has changed; you can still do all you did in 2010. Your farm and sandbox solutions will continue to work as they do today. In addition, you can continue to develop new farm and sandbox solutions in SharePoint 2013. However, there are no improvements. Microsoft has invested its efforts in the App Model.
Microsoft has categorized the hosting options for SharePoint Apps as either SharePoint-hosted or Cloud-hosted.
· Deployed to Office 365 or on-premises SharePoint farm
· Deployed to child site called app web
· Include only SharePoint components
· Resources added to SharePoint host
· Can have client-side code
· Can NOT have server-side code
· Include at least one remote component and may also include SharePoint-hosted components
· App resources are deployed on remote server
· Remote site known as remote web
· App can have client-side code or server-side code
Within the cloud-hosted category are two important types of apps:
· Deployed to remote web on remote server
· Remote web deployed prior to app installation and can include a database
· SharePoint components deployed to Office 365 or on-premise SharePoint farm
· Deployed to remote web in Office 365
· Remote web deployed by Office 365 during app installation to Windows Azure and can include SQL Azure database
· SharePoint components deployed to Office 365
The development tools needed for app development are as follows:
Solutions, Provider-Hosted / Autohosted Apps
· Visual Studio 2012 + Office and SharePoint Tools
· Complete local development environment
· Office 365 Napa App
· Need Office 365 Developer site and browser
In addition to the SharePoint project templates that are available in earlier versions, Visual Studio 2012 now includes a new app project template in the Apps folder named Apps for SharePoint 2013.
MSDN states that with an Office 365 Developer Site, you get an isolated app domain for SharePoint-hosted apps, preconfigured to use OAuth, so that you can use the Windows Azure Access Control Service (ACS) for authenticating and authorizing provider-hosted apps for SharePoint that are deployed to this site.
Napa is a lightweight toolset for those just getting started with App development. Important notes about the Napa app are as follows:
· Office 365 Developer sites have unlimited license to the “Napa” app
· Trimmed down, web-based version of Visual Studio 2012
o Client-side code only
o No code-behind allowed
o Markup view for ASPX pages
· Cannot be used to create provider-hosted or autohosted apps
· Can only create SharePoint-hosted apps
· Download solutions created with Napa and open in Visual Studio 2012
Below is a look at the Napa UI. You can see that there is a similar look and feel to Visual Studio. There is even intellisense that can be invoked using the shortcut Ctrl + Spacebar.
With Napa, you also have the option to download your project to Visual Studio 2012. Below is the same project above, downloaded from an Office 365 developer site.
To develop apps you will need to become familiar with the SharePoint Client-Side Object Model as well as REST and OData.
· BCS (Business Data Connectivity Services)
· UPS (User Profile Service)
REST stands for Representational State Transfer. Rather than using complex mechanisms such as RPC or SOAP, developers use simple HTTP to make calls between machines. An example of a REST-based architecture is the World Wide Web, based on HTTP. RESTful applications use HTTP requests for all four CRUD (Create/Read/Update/Delete) operations.
SharePoint 2010 provided a REST API called ListData.svc. Microsoft has deprecated this endpoint in SharePoint 2013. Microsoft has provided a new endpoint called Client.svc, which serves as the primary CSOM endpoint.
· /_api/ maps to /_vti_bin/client.svc
· Enables basic CRUD (Create, Read, Update, Delete) operations using REST interface and OData syntax
ODatais a standard protocol to share data founded on RESTful principals. Microsoft uses OData in Microsoft WCF Data Services. In addition, OData is the data access API for HTTP-based clients like Netflix and Twitter.
The Server-side Object Model is not available for apps; you must use CSOM or REST.
Apps will have a tenancy requirement in SharePoint 2013. Multi-tenancy is about the isolation of data, operational services and management. A tenancy results in a unique deployment for the customer on a shared set of infrastructure resources. Additional notes about tenancies in SharePoint are as follows:
· Set of site collections configured and administrated as a unit
· Created with administrative site collection
· A scope for provisioning new site collection
Microsoft uses multi-tenancy for site management in Office 365 and it is required to install SharePoint apps. Administrators can configure on-premise farms with a farm-wide default tenancy.
SharePoint 2013 introduces two new service applications needed in on-premises farms to support apps.
1. App Management Service
· App Instance Metadata
· App Security Principals
· App Permissions
· App Licensing
2. Site Subscription Management Service
· Tenancy Management
· Site Collection Mappings
OAuth is only available in Office 365 and will not be available to on-premise deployments. On-premise apps will need STS (server-to-server) trust setup. Your app code should identify on-premise vs. cloud to determine OAuth or STS for authentication.
Deploying apps in SharePoint 2013 will consist of creating app packages. An app package is a ZIP archive with the *.app extension. This file must contain an AppManifest.xml file. It often contains a file for the app icon. In addition, it contains an inner WSP (solution file) for the app web solution. This inner WSP will be present in all SharePoint-hosted apps, but will only be present in Cloud-hosted apps if they contain an app web.
The app publishing scheme provides better app discovery, installation, and upgrade capabilities compared to traditional SharePoint solutions.
The Office Store is where developers publish apps and make them available to the public.
The App Catalog is where developers publish apps at a private scope. Microsoft implements app catalogs as site collections and uses them in Office 365 tenancies and on-premise farms.
When installing an app you must be a site administrator. To install an app go to Site Contents > add an app > app discovery page (addanapp.aspx)and then click an app to install. After SharePoint installs the app, the app icon appears on the Site Contents page.
When upgrading an app, SharePoint tracks the current app version in the app catalog. SharePoint records the app version when installed. Developers can upload updated versions of the app to the app catalog. SharePoint notifies the user when a new version is available. The user decides whether to upgrade or not.
There is no way to push app updates. Provider-hosted apps must support multiple versions. Developers should make sure that app versions reference specific service versions in order to ensure the user experience is not broken.
This information should provide a good overall picture of what the SharePoint 2013 App Development experience will look like and why Microsoft is moving towards this model and away from traditional SharePoint farm and sandbox solutions.