Top 10 Things I learned when writing a SharePoint 2013 App

On January 21, 2014, in Apps, Sharepoint, Speaking, by admin

The SharePoint 2013 app store is rife with possibilities. While the number of apps in the store is constantly growing, there is a lot of opportunity for all sorts of apps to be put into the store. TCSC recently made the jump into the App Store with our very first app, Profile Jumpstarter.

The idea for the app came from a recent push to get all of our employees to fill out their profile in SharePoint. They had some basics but for the most part they were pretty blank. We needed something to encourage them to fill it out and see at a glance how far away they were from completing everything. We looked in the store and couldn’t find exactly what we were looking for. So we thought, “Hey, we have some pretty darn good developers in house. Let’s write our own!” So we did.

I presented this topic at the Virginia Beach SharePoint Saturday on Jan 11, 2013. And here is a full list of my slides, in case you want to check those out.

And without further ado, here are my Top 10 things learned when creating a SharePoint App:

  1. Writing an App is a lot different than writing a traditional farm solution.

    When writing traditional SharePoint solutions you have access to pretty much everything. When writing an App you have a limited set of things you can have access to (even more so if you are writing a SharePoint solution).

  2. There are a ton of options when starting an app.

    When creating your app there are a lot of options. SharePoint Hosted, Auto-Hosted or Provider-Hosted? Web Forms or MVC? Do you want to use Azure Access Control Service or supply your own certificate? There is a lot to consider with each option, and can be a little overwhelming.

  3. Give yourself plenty of time to get into the store.

    When getting the first app in the store make sure that you give yourself plenty of time to go through the approval process. You may find some surprises. They told us that our company (that has been around for over 30 years) was out of business.

  4. The good people reviewing your app are actually quite helpful and give detailed errors/issues.

    The people who are reviewing your app will give you a PDF of all the issues they uncovered when testing your app. This PDF may contain screenshots of exactly what they saw, what requirement you failed on, and possibly some remediation steps if they can. Very helpful.

  5. You have to support IE8.

    SharePoint 2013 supports Windows 7 and therefore IE8 which shipped by default on Windows 7. If you don’t support IE8 you simply have to mention that in your description of your app.

  6. There are some pretty specific and rather esoteric size requirements for app icons and screenshots when submitting to the store.

    I think this bothered me more than it really should have, but the size requirements of the screenshots and the app icon you are required to upload when submitting your app are really strange. Your app icon must be 96×96, and the screenshots you upload have to be 512×384. The app icon I can see more, the 96 is a strange number, but you had to pick something and you want to everything to look uniform. Sure, makes sense. But the 512×384 is just odd. It isn’t a normal screen resolution, and seems just out of the blue.

  7. You can develop in any language and on any platform when creating apps.

    If you wanted to create a SharePoint app on a LAMP (Linux, Apache, MySQL, PHP) stack you absolutely could. Obviously this would have to be provider hosted, but the point is that you can do it.

  8. You have to be language and region specific when submitting to the store. Just English was not enough. We had to specify English-US.

    You have to be very explicit when defining your languages. I was unable to just say English. I had to say US English. While my app should work perfectly well for our friends across the pond, I only listed English-US as a supported language.

  9. You cannot auto-host an app and put into the app Store.

    While auto-hosting your SharePoint app is an awesome idea and is a great option in many cases, you cannot auto-host an app and put it into the SharePoint Store. Which I suppose makes sense—this would open up a lot of security holes.

And the number 1 lesson learned when writing a SharePoint 2013 App is…

  1. Creating apps is relatively easy and painless. You can do it! Or of course we do have some pretty darn good developers in house…but I am a little partial.

This post is also posted on my company site

Tagged with:  

Getting Some REST with SharePoint 2013

On March 25, 2013, in Sharepoint, Web Services, by admin

There are many options out there for programming against the SharePoint object model. You can use all sever side code using the server side object model, everything client side using JavaScript and the CSOM (client side object model). You can even use Silverlight to access your SharePoint objects. One of the newest methods, and one that I’m excited about, is using the new SharePoint REST API. Making RESTful service calls is now available using SharePoint 2013, which makes creating pages and web parts very simple.

You can access most of your SharePoint objects via REST, but I am just going to look at lists for the moment. I will show you how to first read something from a list and then how to insert an item into that list.

The Model

For this example we are going to have a list already created named ‘Employees’ that has 5 fields.

  1. Title (I changed the display Name to Name)
  2. Address
  3. Department
  4. Salary
  5. Manager

Selecting From a List

The whole basis for RESTful queries is the URL and SharePoint makes this very easy for you. In this example let’s assume that our employees list is at the root of our site. In order to select all items from this list we would simply query the following URI:


The ‘_api’ tells SharePoint that this is going to be a REST query, and the rest of the string tells it where to find this list. A normal REST query would look like this:


But since this is SharePoint things are always a little bit different. Instead of referencing the list directly in the URI you must find the list by title. There is also an option to find by GUID, but using the title is a bit simpler to read in my opinion.

That query will give you every property of every item in your list. Sometimes this might by OK, but I would assume that most of the time this is going to be overkill. I queried my list with Fiddler and this is the first entry of the result set that came back.

full query set

You can see all of my custom properties in there, but the rest of the stuff I really don’t care about. Let’s trim this list a little bit by adding a query string to the end of my URI I can tell SharePoint to only give me back certain items.


simplified query

This is the same record that I selected from above and obviously this is a lot lighter than my first query, so you would want to make sure you trim down the items you are returning to only the items you actually need. Also note that in the Model section above that I renamed the default Title field to Name, however that is just a display name. So when you are querying the list you must give the static name which is Title in this case. You can use most of the ODATA protocol in order to page through the list or do some filtering but I will leave that as an exercise for you.

Inserting a List Item

Inserting an item is just as easy as selecting an item and in fact we are going to be using the same URI and just change our HTTP verb from GET to POST.
We start with https://mysite.com/_api/web/lists/getByTitle(‘employees’)/items just like before, but this time we are going to need a payload to send along with this query so SharePoint knows to insert it. My payload data looks like the following.

 { '__metadata': { 'type': 'SP.Data.EmployeesListItem' }, 
    'Title':  'Tony Stark',
    'Department' : 'Research', 
    'Salary':  '2,000,000', 
    'Manager':  'Pepper Potts',
    'Address':  '23 Ironman Way, New York, NY'

We are telling SharePoint what type of object we are inserting, in this case SP.Data.EmployeesListItem. Then we just pass along as a JSON string representation of everything that we want to fill out about the item. Just that simple.

We POST against this URL and SharePoint takes care of the rest.


  • SharePoint 2013 exposes a RESTful service to access lists and other elements
  • RESTful queries are quickly becoming the standard for web services instead of the older SOAP standard
  • Using RESTful queries in SP 2013 allows developers to access SharePoint elements without having to write any complex code

This post is also over on my company site

Tagged with:  

SharePoint Saturday Richmond

On March 5, 2013, in Sharepoint, Speaking, by admin

I will be speaking at SharePoint Saturday in Richmond on March 23rd.  There are a lot of great speakers and topics lined up, so I would encourage you to go out and sign up today.

The name of my speech is “Giving SharePoint 2013 the SPA treatment.”    I will be covering how to use Office 365 and NAPA to create Single Page Application (SPA) in SharePoint 2013, using the JSOM (JavaScript Object Model).

Hope to see ya’ll out there

Tagged with: