SharePoint, Office 365 & Mobile Apps

Bill Ayers (@SPDoctor, )

In an earlier article (/blog/2014/2/18/sharepoint-mobile-web-site,-native-app,-or-something-in-between) I discussed SharePoint Mobile and the range of options for developing mobile SharePoint solutions ranging from responsive web design to building native apps for each platform. Here’s another update, and this time we’re going to focus just on apps. But it’s still an enormous topic which is constantly and rapidly changing as new products, tools and frameworks come out on an almost weekly basis. Mobile is the next big thing for business now that the Bring Your Own Device genie is out of the bottle, and they probably don’t just want a web site – they want an app!

SharePoint, Office 365 & Mobile AppsThe big development challenge is the diversity of platforms and devices we have to support with iOS and Android fighting over top spot and Windows (in smartphone and tablet versions – soon to become one OS) currently a distant third in the consumer market but still a significant player in the business world. And then there is a bewildering array of development technologies to choose from. It has become a huge headache to decide which approach to choose. So here’s my attempt at a crude decision support tool to help you find your way through the maze and highlight a few tools you may find useful on the way.

Native or Hybrid?

By far the most expensive option is to choose native development for each platform. Unless you only need to support a particular device, you will need a team of specialist developers for each of iOS, Android and Windows and you will have to build your applications three times. Unless you are building a consumer application that has to integrate tightly with the hardware or you require the ultimate in performance, such as a game, then this option is just too costly for most software projects, particularly where there is the additional complexity of interacting with SharePoint or Office 365.

There is still the “almost native” option of a tool that can do cross-platform development and that can trans-compile to native code on each platform. There are a few of these but the one that is getting all the attention at the moment is Xamarin. This allows you to use C# as your development language and uses the Mono implementation of the CLR to allow your .NET code to run on iOS or Android, although you still have to know the native APIs for each platform. For developers who are familiar with WPF or Silverlight they also have Xamarin Forms, a fairly new technology which allows you to use XAML. Unfortunately the UI objects are not the same as WPF or Silverlight and don’t yet have the richness of those frameworks, so you can’t re-use existing mark-up or use the Visual Studio or Blend design tools. But it is still a big help if you are already familiar with XAML in .NET and you are able to use the same UI code on multiple platforms.

Xamarin have some amazing technology and if you have an existing Windows Phone or Windows Store app and want to port it to iOS or Android it makes a lot of sense, although to developers coming from a different direction the benefits are less obvious. Microsoft Open Technology also supports Xamarin projects with their Office 365 API tools. To learn more I recommend reviewing the Microsoft Virtual Academy course segment: Xamarin Development in Visual Studio with Office 365 APIs.

The Hybrid Option

If you are coming from a SharePoint background you are probably already doing client-side web development, and if you are not then you probably should be! I’m going to guess that you are more familiar with technologies like HTML, CSS and JavaScript than WPF and XAML as tools for building user interfaces. You are probably also building business applications where delivering a reliable solution as quickly as possible is more important than raw UI performance. In that case the various HTML5 Hybrid options will look very attractive.

The idea behind HTML Hybrid is that you write your code once using HTML5, CSS and JavaScript. This code then runs inside a web control. A number of frameworks are available that create the web control for you but most of them are based on Apache Cordova (which used to be known as PhoneGap). Cordova provides a shell for each platform which creates the web control when your app runs and also provides a number of standard APIs that give you access to the native capabilities of the device that are not yet available directly in HTML5 (the “gap” that PhoneGap bridges).

It’s worth considering that HTML5 and CSS become your declarative UI, and JavaScript will be your procedural code, and this is analogous to the XAML and the C# code-behind in Silverlight or WPF, or the ASPX page and the C# code-behind in ASP.NET. This is significant because you are probably going to want to use the same composite design patterns to give your code that professional look. You can use the MVVM pattern, for example, by adopting a JavaScript library such as Knockout for your data-binding along with the SPA (Single Page App) framework of your choice. If you want something more extensive you could opt for one of the more comprehensive frameworks such as the currently very popular Angular.js. It’s yet another choice you have to make.

SharePoint, Office 365 & Mobile AppsA very useful Visual Studio template has come out of Microsoft Open Technology called the Multi-device Hybrid App. This not only gives you a solution that supports all three platforms using Cordova, but it can build the Android project as well as the Windows ones and comes with a number of other useful tools. It is a huge time saver when compared to assembling a Cordova project based on downloads from the Cordova site. To build for iOS you unfortunately need actual Apple hardware to act as a build server. I’m sorry to say that’s a step too far for me but fortunately it is possible to use one of a number of cloud build services to achieve the same thing. The Multi-device Hybrid App doesn’t go very far in setting up the user interface of your app so you will need to add these components yourself.

When choosing a SPA framework you probably want one that gives you a bit of help in styling your app to be consistent with the platform otherwise the look and feel of your controls will be at odds with the other apps that it sits alongside. Both jQuery Mobile and Telerik’s KendoUI do a reasonable job at this, and also support older devices that lack full HTML5 support in their browser engines. You may need to download a special “theme” to get jQuery Mobile to look right on Windows Phone.

Better still, in my view, is to use WinJS as your JavaScript framework for your Windows and Windows Phone apps. If you use the Windows Phone 8.1 JavaScript template you will get a WinJS 2.1 app that uses some of the native controls at runtime and is almost indistinguishable from a native Windows Phone app. You can also download WinJS 3.0 which is now open source and theoretically you could use it for all platforms but you would have some work to do to style it for non-Windows devices. My current preference is to use WinJS for Windows Phone and Windows Store apps, and use jQuery Mobile or KendoUI Mobile for iOS and Android.

Both KendoUI and WinJS have their own built-in data-binding but it is relatively easy to replace it with Knockout. With the same data-binding library across all platforms (including web) I can then re-use my view-model everywhere. On simpler projects the view-model and model tend to be merged into one JavaScript file so this effectively contains all my business logic. You have to be realistic and expect to re-do the UI on each platform. Sometimes you can re-use some or all of the UI as well, and that is a bonus.

One of the problems with the HTML5 Hybrid approach is that even if you manage to replicate the native look of a platform you may have problems with performance. This may manifest as UI lag which can severely interfere with the user experience – if a transition is not smooth it is worse than no transition at all. A lot of this was due to the performance of the JavaScript engines inside the web browser controls and on some platforms the manufacturers intentionally and rather cynically throttled the JavaScript performance inside the web control. Fortunately they seem to have stopped doing that and in the meantime the CPU and graphics performance of Smartphones generally has improved so this is much less of a problem. But you do need to make careful choices about frameworks and use features like two-way data-binding intelligently. That may mean that the more comprehensive frameworks like Angular or Durandal are not the ideal choice for mobile development. However, if you already have Angular experience or an existing Angular solution then I would recommend trying it first – the performance may turn out to be perfectly acceptable on your target devices.

Talking to SharePoint and Office 365

Your app will need to interact with SharePoint and you have a number of choices. You could use the SharePoint and Office 365 REST APIs directly and this gives you maximum control and can make use of the jQuery AJAX methods or a more sophisticated AJAX library that might have built-in caching or entity models such as breeze.js.

One of the disadvantages of using the REST API is that it requires you to write code to manage authentication tokens and access tokens as well as building the sometimes complex URLs for the REST endpoints. Handling authentication is particularly tedious and difficult to get right. The new Office 365 APIs recently released by Microsoft provide a lot of this plumbing for you and can help simplify your code, while still using the REST APIs under the covers. These libraries are available for .NET and JavaScript and can be used with the Multi-device Hybrid Application template in Visual Studio. Once you have installed the toolkit you just use “Add Connected Service” from the project context menu and follow the wizard. At the time of writing it is not yet supported in all the project templates but you could probably get it to work in other project types by copying or linking files.

In order to talk to SharePoint itself you can use the SharePoint client-side JavaScript Object Model (JSOM). This was introduced with SharePoint 2010 and gives you a number of advantages such as batching of requests. Behind the scenes the JSOM makes XML requests and receives JSON (JavaScript Object Notation) responses.

These client libraries are very good, and in the case of the new Office 365 API the documentation is outstanding, making it particularly useful if you are getting started. But we can expect that the REST APIs themselves will always be one step ahead of the client APIs, and in many cases the development teams at Microsoft are using the REST services metadata to code-gen these APIs. If you are using JavaScript then the REST/JSON API are not that difficult to use directly and this has the advantage of being standards-based so that you can use the same techniques to talk to Office 365, SharePoint and also any other third-party services that support the OData standard. You also have one less dependency to worry about.
The SharePoint REST API now supports OData 3.0 and JSON Light which means you can get more efficient network usage. This works in Office 365 and also for on-premise SharePoint 2013 if you do a bit of configuration (see article referenced below).

Treating JavaScript as First-class Code

A lot of developers seem to regard JavaScript as somehow “just” a scripting language. Sometimes people even talk about “no code solutions” when they mean JavaScript! Part of the problem is that we have tended to use JavaScript in the past for client-side hacks without fully understanding it as a programming language with its own structure, and this probably even applies to some “front-end” developers.

But JavaScript has its limitations (e.g. problems with variable scoping), many of which will be resolved with ECMAScript 6 or can be worked around by using a number of patterns as described in Douglas Crockford’s book referenced below. As with any programming language it takes a bit of extra work to be able to produce “professional” quality code.
In the meantime if you are a C# developer and can’t deal with JavaScript’s loose typing you could consider using TypeScript. This gives you a more C#-like language that is then compiled to JavaScript and is actually a superset of the language. For multi-platform solutions you can put TypeScript into one project and then add links to the generated JavaScript file in the others.

Getting Moving

Mobile computing is fast-changing to the point of volatility. Companies and their products can appear, dominate the market, and then rapidly decline, all over the course of a few years. With so many options, and with more frameworks and tooling appearing all the time, long term planning to find the perfect development strategy is probably not going to be that useful. It probably makes more sense to find something that delivers business value today, as quickly as possible, and in the knowledge that you may replace it with something else in the relatively near future as the technology continues to evolve.

You might say that in order to be mobile you need to be agile!

If you have any questions or feedback on Bill’s article please leave a comment below. We would love to hear from you.

Office Development Center,

Developing on the Office 365 platform,

Introduction to Office 365 development,

Deep Dive: Integrate Office 365 APIs in Your Mobile Device Apps,

Multi-Device Hybrid Apps,

Microsoft Open Technologies,
“JavaScript: The Good Parts”, Douglas Crockford, O’Reilly


SharePoint, Office 365 & Mobile Apps

Bill Ayers

Bill Ayers is a consultant developer and software architect who has been working on SharePoint since the 2003 version of the product, and is a Microsoft Certified Master and MCSM, SharePoint. He specializes in web content management and Intranet portals. He has over 20 years’ experience in the software industry, and speaks regularly at international conferences and user groups.

Share this on...

Rate this Post: