Pages

Sunday, October 28, 2012

SharePoint 2013 introduced new concept of ‘SharePoint apps’. Apart from Server Object Model, you can now user Client Object Model or REST API to develop SharePoint Apps. For developing apps, you don’t need to install SharePoint in your development pc. You can develop SharePoint apps in client Operating System like Windows 7or Windows 8. If you have not already started developing apps for SharePoint, this post might help you in getting started. To develop apps you need combination of two setups.

Development Environment: where you install visual studio for developing apps. For your information for developing SharePoint apps you don’t need a SharePoint server. You can develop apps in your windows 7/8 environment.

Deployment Environment: where you can run your apps for testing/debugging. Surely this will be a SharePoint system.

Based on the development and deployment environment integration, there are two ways you can setup your apps development environment:

On-Premises Development Environment

In this setup, you install the development and deployment in the same server. This is kind of manual process of setting up your SharePoint server to work as apps hosting server. I would not like to recommend you for this setup unless you have a specific reason. You can find more details on how to setup your on-premises development environment by following the MSDN link on ‘How to: Set up an on-premises development environment for apps for SharePoint’. The concept is shown below: Figure 1: On-Premises setupBasically in he on-premises setup, you develop your own SharePoint server and then prepare it for publishing hub for SharePoint apps. You will develop apps in your development pc and then deploy in the on-premises SharePoint server.

Office 365 based development Environment

In this setup the development environment is on-premises but the deployment environment is office 365. You can get your own deployment environment by signing up for office 365 developer site. You can find details on how to sign up for office 365 developer site from MSDN ‘Sign Up for an Office 365 Developer Site’. The concept of this environment is shown below:

Figure 2: Office 365 developer setup

In the Office 365 development environment setup, you will develop in your own pc and then deploy in Office 365 developer site to test/debug. Once you are done with your development and want to publish it, you can do so by publishing in the office app market.

Step by Step Instructions on Setting up Office 365 based Development Environment

Step 6: Once installation is finished, click ‘Site contents’ from left side and then launch the app “Napa – office 365 developer tools’ by clicking as shown below:

Figure 5: Launch ‘Napa developer tools’ from Site contents

Step 7: Once the app launches, you can add the new SharePoint app project by clicking link’ Add New Project’ as shown below:

Figure 6: Napa apps – home page

Step 8: Once the project created you will be provided in-browser IDE like development environment. However you can lunch the project in Visual Studio by clicking the icon ‘Open in Visual Studio’ as shown below. This will install necessary tools to run the project.

Figure 7: Open in Visual studio link

Finally Microsoft Web Platform Installer will run and install every required components to run the app. After the installation is done, you can deploy your app in Office 365 developer site. Just run your app from visual Studio by pressing F5, which will install the app before running and as soon as you stop debugging, the app will be uninstalled.

Conclusion

Setting up on-premises development environment requires manual configuration and might be time consuming. But setting up Office 365 based development environment is much easier and you can get it ready within 15-30 minutes. So I would recommend you to go for this Office 365 based setup to start learning how to develop apps. Once you are confident with the apps development you can also try to setup on-premises development environment.

Sunday, October 14, 2012

Audience is a nice feature in SharePoint but only available in MOSS/SharePoint Server. Generally speaking, Audience is group of users that can be used to target contents. The class ‘Microsoft.Office.Server.Audience.AudienceManager’ is the main entry point for accessing Audience feature in SharePoint. Audience values are of three different types which are separated by ‘;;’:

I’ve found many times that people are manipulating these audience field values manually by parsing the text. However there’s SharePoint server object model support to manipulate Audience field programmatically.

Find Audience Field in List/Library

Audience field is of type ‘Microsoft.Office.Server.WebControls.FieldTypes.SPFieldTargetTo’. You can find out the field types from list fields’ as shown below (using any of the two described):

//Alternatively you can use the following code snippet also:foreach (SPField field in list.Fields){if (field is SPFieldTargetTo) {//found audience field }}

Code 1: Get Audience fields

Read/Parse Audience Values

You can manipulate the audience values as shown below. To read value from a list/library audience field, pass the value in the AudienceManager.GetAudienceIDsFromText method. The method will parse the audience field value and populate three out variables: Global Audience, Distinguished Name and SharePoint Group.

If you have global audience id (which is valid guid), please convert the guid string to GUID type variable and then pass in the GetAudience method.

Update Audience Field Value

To update audience field value programmatically you need to use following code snippet. You need pass the global audience IDs, distinguished names and sharepoint group names to Audience Manager’s GetAudienceIDsAsText method which will combine the values as text to save in audience field.

Saturday, October 6, 2012

Introduction

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

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.

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.