Apps for SharePoint
are easy-to-use, lightweight web applications that integrate popular web
standards and technologies to extend the capabilities of a SharePoint website.
This topic helps you understand the basic concepts about how to build apps in
SharePoint 2013.
Why build apps for SharePoint?
There are many great
reasons to build an app for SharePoint:
A familiar programming model, plus popular technologies and
languages
For apps, the web is
the platform. If you can build a web application, you can build an app for
SharePoint. Plus, apps for SharePoint have a similar development process for
any device you are targeting – mobile phones, tablets, or computers – so you
can be more efficient and productive.
Here are some
highlights:
·
Use any language -
like HTML, JavaScript, PHP, or .NET - and your favorite web development tools -
like Visual Studio 2012 or the new "Napa" Office 365 Development
Tools.
·
Distribute the app’s
logic, data, and user interface (UI) in separate components to fit your needs.
For example, an app
can have presentation logic in HTML and JavaScript that runs on the client,
business logic in .NET that runs in Microsoft Azure, and data that is stored in
SQL Azure. Or, an app in PHP could have data in MySQL.
·
Connect to most
internal or public web services.
·
Use the new OAuth 2.0
support in SharePoint.
·
Use the expanded
capabilities of REST and client APIs (JavaScript and .NET) to access the rich
data and services in SharePoint such as search, workflow, social networking,
taxonomy, user profiles, and Business Connectivity Services (BCS).
The following figure
shows the conceptual architecture for building apps for SharePoint.
Multiple options for hosting
The app model offers
multiple hosting options for your app. You can choose your own web stack or
host it on SharePoint, as shown in the following diagram. An app can also have
some components in SharePoint while others are in the "cloud." Learn
more about the various types of apps and hosting options in Choosing patterns for developing and hosting your app for
SharePoint.
A familiar web experience, yet more flexible
Apps for SharePoint
have the same user experience as SharePoint websites but are more flexible –
they fit seamlessly into a SharePoint website in several ways:
·
As an immersive
full-page experience
·
As part of a webpage,
using app parts to surface an iframe element that contains the app
·
As UI custom actions,
extending ribbons and menus by adding the app to list items, documents, and
more
The following diagram
shows the types of user experiences available. For more information about apps
for SharePoint, see UX design for apps in SharePoint 2013.
Integration with apps for Office
Apps for SharePoint
can integrate with apps for Office, which are based on the new web-based
extensibility model in Office 2013. Apps for SharePoint can also be part of an
Office 2013 document template. For more information about apps for Office,
see Overview of apps for Office.
Reach users through the Office Store and the App Catalog
Use the Office Store
to sell your app for SharePoint to users and IT professionals for personal or
corporate use. The Office Store handles the end-to-end process from discovery
to purchase to updates.
Apps for a company are
deployed to the organization's internal App Catalog hosted on SharePoint, which
provides the same complete back-end support. For more information about the
Office Store and the App_Catalog, see Publish apps for SharePoint.
Building an app for SharePoint
To build your app for
SharePoint, you must do the following:
Configuring an app
An app for SharePoint
is configured with SharePoint using an app manifest—an XML file
that declares the app’s basic properties, where it runs, and what to do when it
starts.
An app manifest file
can do many things, such as use different authentication schemes (also known
as app principals) and declare the permissions the app needs. It
can also include tokens that are replaced at build/run time, so you can
reference your app and pass context (for example, the SharePoint language and
where the app is installed).
The following simple
app manifest tells SharePoint to register the app and invoke a remote page when
the app starts.
<?xml version="1.0" encoding="utf-8" ?>
<App
xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest
(http://schemas.microsoft.com/sharepoint/2012/app/manifest)"
ProductID="{5eccee90-1e41-4ecc-af8c-485facb5c188}"
Version="1.0.0.0"
SharePointMinVersion="15.0.0.0"
Name="LocalTheater"
>
<Properties>
<Title>Local Theater</Title>
<StartPage>https://remoteAppUrl/Default.aspx/?{StandardTokens}</StartPage>
</Properties>
<AppPrincipal>
<RemoteWebApplication ClientId="*"
/>
</AppPrincipal>
</App>
Deciding where the app’s code runs (hosting options)
You decide where the
app’s code runs by choosing the hosting option —in SharePoint, in the cloud, or
a mix of SharePoint and cloud.
·
Provider-hosted
apps: You or your app
purchaser’s IT department must host a provider-hosted app on a dedicated server
or third-party hosting service. Depending on your choice, these apps run either
on your server or in the cloud.
·
SharePoint-hosted
apps: When the app is
hosted in SharePoint itself, the code is only in HTML and JavaScript and is
hosted by SharePoint.
·
Hybrid
apps (components in both SharePoint and the cloud): In these apps, SharePoint components run
in SharePoint while components hosted in the cloud run in the cloud.
Communicating with SharePoint using SharePoint APIs
Apps show their power
when they use SharePoint APIs to connect and integrate with SharePoint
features—search, workflow, social networking, taxonomy, user profiles, BCS, and
more. This lets them read documents, do searches, connect people, and much
more. SharePoint APIs include the following:
To
start working with SharePoint APIs, see How to: Complete basic
operations using SharePoint 2013 REST endpoints, How to: Complete basic operations
using JavaScript library code in SharePoint 2013,
and Basic operations with the
SharePoint .NET client object model.
Before
you call SharePoint APIs, you must authenticate to SharePoint and get user
consent or authorization. For more information, see Data access options for apps in
SharePoint 2013 and App permissions in SharePoint
2013.
Packaging and distributing an app
Apps
for SharePoint are distributed as an app package, and the components it
contains depend on where your app is hosted. A provider-hosted app package might
contain only the app manifest if the app is hosted on a dedicated server or
third-party hosting service. A SharePoint-hosted app package might contain some
SharePoint-related components and the app manifest. In addition, app packages
can include components such as apps for Office. For more information, see How to: Publish an app for
SharePoint by using Visual Studio.
If
you use "Napa" Office 365 Development Tools or Visual Studio 2012 to
build apps and deploy directly from them, the tools let you publish your app
into a file that has an .app extension. You can then distribute the app in one
of two ways:
·
Apps that are meant to run within a particular organization can
be deployed using the App Catalog.
·
Apps for the Office Store can be submitted via the Microsoft
Seller Dashboard. Always remember to add licensing checks to the app. For more
information, seeHow to: Submit apps for
SharePoint to the Office Store.
Apps Types:
SharePoint-hosted apps
Provisions an isolated sub web on a parent
web. The app webs site gets it’s own unique sub-domain (browser cross domain
policy). This is important to separate one app from each other app. Use lists,
out-of-box web parts. No server-side code allowed, client JavaScript only.
Provider-hosted apps
Bring your own server hosting infrastructure.
Use the programming language of your choice and callback to SharePoint via the
OData API. There is also an option to create remote event receivers.
You can combine SharePoint-hosted apps
with remote apps.
HOW DOES AN APP
LOOKS LIKE?
The main part on app is the app manifest
The manifest contains an unique app id, the title, permissions and a start page. The example shows how to register a remote app. {Standard Tokens} appends some standard url parameters to the request like the url of the SharePoint host site. The url of the SharePoint host site is important for callbacks from the remote app to SharePoint.
Marketplace
Microsoft also is going to introduce a
commercial public marketplace for SharePoint and Office apps (Office apps are
similar to SharePoint apps and will bring a new
and unified web development model to the
Office rich clients and web apps). 100 million potential SharePoint apps
customers, or even 750.000.000 potential Office apps customers’ sounds very
promising. Beside the public marketplace there is also the option to have a
private corporate app catalog.
Summary
I think the SharePoint product group did a
really good job with the new app model, the marketplace and the current
SharePoint strategy. They did some really clever decisions!´
No comments:
Post a Comment