ngSydney, Office Add-ins and lots of AngularJS

I went to my first ngSydney meetup on Wednesday night, and presented a short session on Office-Addin with AngularJS (I also throw in Graph API) and ran over my allocated time to 40 minutes.

I probably should have asked for 1hr.


Here is the PowerPoint presentation.  Presentation: office-addin yo ngSydney

Also, check out all the examples on


Graph API has Excel endpoints "coming soon".  These REST endpoints will let your app reach inside a workbook/worksheet/range/cell and pull/push stuff in and out like JSON goodness.

Unfortunately, no Word REST API yet.


As I rushed through the demo some things perhaps wasn't as clear as I could explain.

1. There were two libraries/APIs - the Microsoft Graph REST API lets you talk to services across Office and eventually Microsoft space.  You need to register an Azure App so Graph knows what permissions you are after.  Your users need to authenticate and grant permission to your app to use the services that it is asking for.

2. The Office.js within a Office Add-In lets you talk to the current document, or mail within the Office App.  You need to register/deploy the manifest.xml file with your Office 365, or through network share or group policy for Desktop Apps.  The manifest describes what sort of permissions you are seeking on the current document, usually there is only Read or ReadWrite.

You can use Office.js and Graph API together as it was in my demo, or separately.

3. The 'app' I was running in the iframe for both Office 365 or Word 2013 is running out of https://localhost/ - I didn't stop to show this.

4. Authentication piece of the puzzle moves forward as well - next on the line is Progressive Permissions where an app can request more permissions on the spot and the user will be asked to allow additional permissions (write) on the go.

5. Office Addin is available in: Office 2013/2016, Office for Mac, Office for iOS.  Not yet available on Office for Android.  It also runs in Office Online (SharePoint Online, OneDrive, and within both Exchange Online (business) and (consumer).

Had a few awesome quotes:

Update on SharePoint and Office Development - 2016 Feb edition

We rotate through different topics and presenters in the Sydney SharePoint user group.  But I finally got my turn to present a developer topic, and I wanted to do a quick primer on all things Office Developer related.

This turned out to be a REALLY complex talk.  I wanted to cover ALL the cool new stuff in Office Dev.  But as it turns out every month (and now, every week) new things come out. 

I ended up with:

  • Brief Introduction to
  • Brief Introduction to PnP
  • Where we have been with SharePoint Add-Ins
  • Where we are going with Office Addins: 
  • NEW API: Microsoft Graph API
  • NEW AUTH: OAuth 2.0 and ADAL(js)
  • NEW TOOLS: New tools with Node, NPM, and Yeoman Generator (YO OFFICE)
  • Build a demo Office Addin that talks to both SharePoint Online and Microsoft Graph
  • Run on web and desktop

The presentation clocked in at 1 hour and 20mins - I started a bit earlier.  And kind of flopped off at the end as I run out of steam after the demo :-O

Then we gave out all the swag from so all is happy faces.

The PowerPoint presentation is here:

2015 February Presentation - Update on SharePoint and Office Development


Demo Fail

So at the end, the Office Add-In didn't load from the App Catalog on my desktop.  I went home and got it to work, here are screenshots to proof it.

Oh NO - no apps

Add SharePoint App catalog to trust center


Here it is.  The same addin working on desktop - talking to Microsoft Graph and showing Group Conversations


Convert SharePoint JSOM's ExecuteQueryAsync to Promise in the Prototype

Today's blog is about adding an additional method to SharePoint JavaScript Object Model (JSOM)'s ClientContext object, so we can use it directly like a promise.

I call it "executeQuery" (instead of executeQueryAsync)

Wrapper with jQuery's $.Deferred

SP.ClientContext.prototype.executeQuery = function() {
   var deferred = $.Deferred();
       function(){ deferred.resolve(arguments); },
       function(){ deferred.reject(arguments); }
   return deferred.promise();

Wrapper with AngularJS's $q

SP.ClientContext.prototype.executeQuery = function() {
   var deferred = $q.defer();
       function(){ deferred.resolve(arguments); },
       function(){ deferred.reject(arguments); }
   return deferred.promise;

How do you use this?

var ctx = SP.ClientContext.get_current();
var web = ctx.get_web();
var promise = ctx.executeQuery(); // look!  :-)

  //sArgs[0] == success callback sender
  //sArgs[1] == success callback args
}, function(fArgs){
  //fArgs[0] == fail callback sender
  //fArgs[1] == fail callback args.
  //in JSOM the callback args aren't used much - 
  //the only useful one is probably the get_message() 
  //on the fail callback
  var failmessage = fArgs[1].get_message();

This may seem to be just small syntactic sugar, but now you have JSOM returning a promise that you can chain, loop, combine and juggle to your heart's content!

Remember, jQuery.ajax, SPServices, AngularJS, and now JSOM all returns promise objects now.

Thinking with JS Promise and Promises


Here's a real life example of a quick design iteration that we went through with promises this week.

In AngularJS (but this applies to any JavaScript), we have a function that calls the server to do a long running process.

function longProcess() {
    // dataservice returns a promise and we return that to our caller.
    return dataservice.longservice();

As this could potentially take nearly a minute, we want to add a waiting dialog.

AngularJS UI provides a modal dialog service $modal

function longProcess() {
  // create dialog
  var dialog = ${ templateUrl: 'wait.html' });

  var promise = dataservice.longservice();

      // success
    function() {
      // fail
  return promise;


This works great.
But sometimes, the dialog flashes past too fast!  While the user is still trying to read it, it disappears.

Before we run off into code, let's stop a do a bit of thinking.

What we need is to combine the original promise, with a second new timer promise (of say 5seconds).  When both the service call has finished and the timer is up, we will resolve the promises.

So in pseudo code, it'd look like:

var p1 = service();
var p2 = $q.timer(5000);
var all = $q.all([p1,p2]);
all.then( /* resolve */ );

Note: $q is AngularJS' lightweight implementation of a Promise/A library Q.  The pseudo-code assumption was that $q would provide a timer-based promise that detonates once time is up.  In reality, $q doesn't provide such a method.  But the $timeout service in AngularJS returns a promise for exactly this scenario.


function longProcess() {
  var dialog = ${ templateUrl: 'wait.html' });

  var p1 = dataservice.longservice();
  var p2 = $timeout(angular.noop, 5000);
  var arrayOfPromises = [p1, p2];
  var promises = $q.all(arrayOfPromises);
      // success
    function() {
      // fail

  // returns a combined promise to our caller.
  return promises;



The dialog opens and shows wait.html - it closes when the service is complete and when the timer has hit 5 seconds.  



Racing to the Races - Putting our Office App out there

As I'm posting this blog entry, our (SharePoint Gurus) first Office App (Add-In) would be available on the store.

I might let you in on a secret - it has in fact been in the store in the last few days, but as it is our company's first Add-In, we had some hiccups and had to push out subsequent updates.  We are pleased with this version and we'll run with it to the actual Melbourne Cup race, which actually isn't all that far away.  It would be on November 3, 2015, and the horses list would be available on October 31 - a Saturday, yes that means our Add-In would prompt you to automatically update data on Monday morning.

Feedback through the week from our clients has been very supportive.  This could turn out great (or a great learning experience).  But either way, we have fun and we hope our clients and friends have fun with our App too.

The Team

We are all consultants and this Add-In is something we wanted to build for a long time, but never could tear ourselves away from our great clients to just stop and write this Add-In.

  • We learn AngularJS along the way
  • We became pros at JavaScript Promises... chaining promises, grouping promises, catching error promises and retrying them.
  • Everyone in the company got involved.  We are not a large company, but this one Add-In has 100% contribution from the entire team.
  • We had different people deploying to their own developer sites, both On-Premises and Office 365. 
  • We use TFS but had an open checkout policy (you have to merge any changes).  This turned out not as disastrous as we think, it gave us freedom to work on the project when we can, without having to wait for a certain colleague to check in first.
  • We started the journey a long time ago with Wiki pages, Task lists and Yammer discussion group.  We are now on Office 365 OneNote (available anywhere, offline, and synchronized) and Office 365 Groups for conversation.  We use the Outlook Groups app when we are on the run.  If Office 365 Planner had been available, I'm sure we would be all over it too.  We had a white-board with moving tasks and Post-It notes.

The Stack

The Add-In is a SharePoint-Hosted App. 

Sweepstake Horse says SAAI.  Also, horse is sorry he didn't say on-premise s

Sweepstake Horse says SAAI.  Also, horse is sorry he didn't say on-premises

The Learning (so far)

  • v2 will be provider hosted.  The complexity would lie in provisioning, and also not all our consultants are fluent with ASPNET MVC or C#
  • The benefits are to do with ease of updating the various components, and hiding core logic.
  • We may tackle NodeJS instead


You should download our Add-In and give it a whirl.  Come next Monday, hopefully we hear good things from you.

We already have people asking to do a Rugby World Cup one next year, which would have been fun, this weekend is finals between Australia vs. New Zealand.