SharePoint 2013 introduced a ton of new features for the end user. It also brought about a lot of changes for SharePoint developers, particularly in terms of the new SharePoint App Model. I’ve been a core SharePoint developer for seven years now, through both the 2007 and 2010 releases, and so I thought it might be beneficial to share some lessons learned from my own transition from core SharePoint developer to a SharePoint 2013 app programmer.

My previous experiences with SharePoint development focused heavily on MOSS code with workflows, InfoPath, Lists, Content Types and developing front end applications using these features. I had almost no JavaScript experience, especially Async programming, and no clue what SharePoint apps are or what they look like.

My two immediate realizations when faced with SharePoint 2013 were that:

  1. I had to learn lot of new terms: SharePoint Hosted, Provider Hosted, Auto Hosted, On Prem, O365, Host web, App web and many more.
  2. Your working hand is tied behind your back and your head hurts more than ever before, because in the realm of client-side coding you have to think differently, about a 180 degree twist. It gets better after a week or two of JavaScript immersion.

For my current SharePoint 2013 project, we are using Durandal and RequireJs for creating user interface screens and the SharePoint Javascript object model (JSOM) for backend service code. You don’t need Durandal and RequireJs to do SharePoint 2013 programming, but we chose them for creating user screens as single page application.

Learn more about the custom applications you can build with SharePoint.

Making the Leap: What to Learn & Practice

1. Learn JavaScript. Yes, the thought itself is scary but there is no way out if you want to code SharePoint 2013 Apps. Pay attention to the this variable. For instance, the scope of this changes when passed from the calling method to within the called method. The examples provided on MSDN sites work fine for the app, but when I used same methods within the define() function of RequireJs, the missing this created mismatched variable problems. For example:

this.collList = oWebsite.get_lists();
clientContext.load(collList);
clientContext.executeQueryAsync(
Function.createDelegate(this, this.onQuerySucceeded),
Function.createDelegate(this, this.onQueryFailed)
);
}
function onQuerySucceeded() {
var listInfo = '';
var listEnumerator = collList.getEnumerator();

In Line 1, we create a variable collList and add it to the current function’s scope using this. Later, in line 11 we reference collList without this keyword. It works fine if you have the code in files as the article on MSDN describes. But if you take this code and plug it in a .js file (which defines require.js modules), the missing this before collList in line 11 created scoping problems and the variable collList was undefined.

I have explicitly started declaring variables with var keyword and referencing the variable in the called method directly, without this keyword.

2. Learn how to debug JavaScript using the IE toolbar or any developer assistance provided by your favorite browser. This is a must and saves you tons of time in long run.

3. Look through all the namespaces available. The examples on MSDN show samples using only SP.js namespace, but there are many more that are useful. SP. Utilities.Utility being one of them. Examples- SP.Utilities.Utility.resolvePrincipal() enables you to get display name of user from login name. SP.Utilities.Utility has methods to work with a discussion board, which makes discussion board manipulations very easy.

4. When you search for ideas/examples, don’t just search specifically for SharePoint 2013 but instead use ‘SharePoint client object model.’ This will return items for SharePoint 2010 (which has been around for a while), and so far everything that works for SharePoint 2010 has worked for SharePoint 2013. Also don’t be afraid to use anything in Microsoft.SharePoint.Utilities namespace — just replace that with SP.Utilities.Utility.methodName in your code and most likely it will work.

5. Learn the promises pattern — because every call is Async and it gets ugly pretty quickly. We used jquery promises,  which also helps in integration with Durandal and Requirejs.

6. One of the major issues I faced was navigation — to lists, site settings with app web. There is no quick launch or site settings link directly on the home page. To view lists directly on the page, add XsltListViewWebPart web parts. For site settings I adopted the following pattern — go to home site collection, click on the site settings gear icon, click on any link (site columns, content types) you want to access. Copy the URL after the siteCollection Name and then come back to app web URL and paste the copied portion at the end of app web URL. Most of the time you will get where you want, but sometimes you do not have access and in those cases you might be reverted to site collection site settings page or will receive the access denied error.

Example:

  • Go to site columns of app web.
  • Site collection URL: http://siteCollection/_layouts/15/start.aspx#/_layouts/15/mngfield.aspx
  • App web URL: Paste _layouts/15/start.aspx#/_layouts/15/mngfield.aspx at the end of http://apps-4aac7d5ca2d4a0.sitecollapps.com/NameOfApp/ and it resolves to http://apps-4aac7d5ca2d4a0.sitecollapps.com/NameOfApp/_layouts/15/mngfield.aspx
  • You can now view site columns for the app web.

7. Use Qunit to test Async code. It helps validate your code. The idea of using QUnit for application testing was pushed by Vishwas Lele and initial setup of the QUnit was done by my colleague Praneeth Gadhamsetty. As we were using RequireJs for our application, we followed Johnny Reeves’s blog to set up Qunit for RequireJs. See the section titled “Configuring QUnit and RequireJS.”

7a. The HTML document we use is similar to one in the blog, with ours also including references to SharePoint, Knockout and AJAX JavaScript files.

7b. The testsuite.js is similar and yes, we did end up breaking our test files into multiple files as well. If you use multiple files (or specify module names for each set of tests) you can then filter and view your results for each file instead of all the tests displayed on single page. Say you had your test modules in test1.js, test2.js, test3.js. When you run the testRunner.html you can apply filtering to it, to display tests from only test3.js, like http://YourUrlToTheTestRunner.HTMLFile/EndtoEndTestRunner.html?filter=test3 where test3 is the module name given to the file.

7c. As all our main methods were asynchronous, we used QUnit’s asyncTest() method.

Example: Check if a file with same name exists in the document library. If we had an asynchronous JavaScript method named CheckForDuplicateFileName(), which returns true or false if file exists or not, then the test method we would write would be:

QUnit.asyncTest("asynchronous test: Check for duplicate file name in Document Library", function () {
expect(2);
service. CheckForDuplicateFileName (‘UseFileNameThatAlreadyExists’).then(function (response) {
QUnit.equals((response.FileExists === true), true, "Duplicate file exists.");
QUnit.equals((response. FileExists === false), true, "Duplicate file does not exist.");
start();
}, function (sender, args) {
QUnit.equals((sender.Status === "Failed when trying to get data out of document library"), false, "Failed when trying to get data out of document library. Message: " + args.get_message());
start();
});
});

Disclaimer: My intent for this blog is to simply overcome initial stumbling blocks a developer might face when starting with SharePoint 2013 apps and not to cover any topic completely.

Read more about what makes SharePoint a great application development platform here.