As a developer there are times I want to quickly throw something together to see if an idea I have is workable. I don’t need to go through all the ceremony of creating a project with necessary dependencies, good architecture, etc. if all I want to know is if I can access some service. For most things I can fire up a quick test project using either Console or Web project templates and have my answer in a few minutes. For SharePoint though, this has never been very easy.
Introducing Napa Tools
“Napa is a great way to get started building Office Add-Ins right in a browser window. You don’t need to install any tools such as Visual Studio. All you need is an Office 365 account and a supported browser.”
With previous versions of SharePoint, server-side code was really the only way to go to create custom SharePoint solutions. Developing for SharePoint was tricky as it required a local install in order to build and package solutions. This made throwing together test harnesses very slow to prove out a concept. With the introduction of client side libraries and services, extending SharePoint with custom code has become much easier.
Even though developing for SharePoint doesn’t mean server side code, it still has packaging requirements. That’s where Napa comes into play. Using an online editor which resembles lightweight editors like Sublime and Visual Studio Code, anyone with a modern browser can throw together a quick test or demo without a local install of SharePoint or even worrying about manifests and elements files. The editor provides syntax highlighting, jump to definition, basic Intellisense capabilities, and saves your work automatically.
Quick Note on Terminology
In this post I mix the use of “app” and “add-in” a few times. This is mostly because the terms have been used interchangeably as the official names have changed. If you used the Napa tools recently you may have noticed the menu for creating a SharePoint add-in still said “App for SharePoint” though this has been renamed “SharePoint Add-in” now. MSDN documentation and even the Napa store app still contain references to the old “app” name. I try to use “add-in” when I’m specifically referencing the technology and limit “app” to referring to a general concept of a self-contained collection of things that do stuff.
There’s not a lot required to start using Napa. If you have a modern browser and SharePoint Online, you have everything you need to get started. No, seriously, that’s it. Don’t have access to SharePoint Online? Sign up for a free year of Office 365 with a developer account.
Once you have these two basic requirements, all you need is to install the Napa add-in.
Note on URL Protocols
You’ll notice all the Napa examples are using HTTPS everywhere. SharePoint Online pretty much requires HTTPS protocol for everything so this is generally seen as safe. While you can modify a package and deploy it to an on-premises install of SharePoint using HTTP, external references that are available via HTTPS should still be requested explicitly using HTTPS. You can use protocol-relative URLs but there is a possible security vulnerability doing that.
Deploying Your Add-in
Now that you have the basic parts of an add-in, all you have to do is hit the Run Project button. Your add-in will be uploaded to SharePoint Online but if you look at the URL you’ll notice the domain is different from the one in which you created your project. This is a really important piece of information if you expect to interact with your SharePoint data inside your add-in. If you’re just creating a content piece that displays data from external sites then this won’t matter to you at all. You’ll notice that even though the domain is different, the site URL from which you launched Napa is still part of the full URL.
With you add-in deployed, you can now interact with it and use your standard browser debugging tools to test out whatever you were hoping to test. In mere minutes, you have an app running on SharePoint with access to SharePoint client services and libraries and, with a bit more effort, you can even access data from your SharePoint lists.
Add-ins created with Napa can also access and interact with your tenant data. You can download the source code for inclusion in your source control system, modifying for more powerful features or just to use your preferred editor offline. In a future post I’ll explore accessing your data via a Napa add-in using the SharePoint REST services. Spoiler: reading data is a lot easier than writing it. But I bet you knew that already if you’ve worked with SharePoint client side programming.
So far I’ve only run into two problems, both of them leading to a failure to publish an add-in. The first seems to happen when a new project is created. If you can’t seem to publish your new add-in, take a moment to visit each of the menus in the settings. You generally don’t have to change anything, just visit them. Try publishing again and it usually succeeds.
The second publish failure usually shows an error message indicating the add-in is already deployed with the same version number. This is (easily?) remedied by going to the site and deleting the app and making sure it’s not in the recycle bin. If this is still happening, check your parent site as well. If it comes down to it, visit all your sites hunting for it and make sure to remove and delete from recycle bin. I haven’t figured out what causes this problem but it might be related to having multiple tabs open. I tend to open a lot of tabs to make it quick to switch between contexts, copy code, etc. but I’ve only had this publish error happen twice.
- “Napa” Office 365 Tools on the Office Store
- Create a basic SharePoint-hosted add-in using Napa Office 365 Development Tools
- Slightly older reference; examples use CSOM
- Get to know the SharePoint 2013 REST service
- General info about SharePoint REST services; not Napa specific