Why the SharePoint 2013 App Model is better than sliced bread

+

>

I was responding to a post on the Apps for SharePoint forum, and it ended up being so long that I decided to make it a blog post.  If you want some additional context you can go check it out.

From a SharePoint app if you want to read to and write to a custom list that your app didn't create, you can.  If other app developers want to read from and write to the same list they can.  Your app just needs to request a high enough permission level to do it.  In addition the user needs to have rights to do it.  You could also do it using the app only policy in a SharePoint hosted app, but would need to use the REST API for that.  In that case you would be able to write to the list even if the user didn't have permissions to do it. 

Apps are intended to be self-contained where applicable, so if the data only pertains to your app then you should keep the data in the app. Either remote or in the app web.  This way if your app is uninstalled there won't be a bunch of stuff left behind in SharePoint that the user has to delete because it was only relevant to the app.  This is actually a common scenario in 2010. Developers love to use the OnFeatureActivated event, but not so much with the OnFeatureDeactivating event. Meaning they make a lot of changes when the solution is installed, but leave the stuff behind when it’s deactivated.

However, there are plenty of times when it is perfectly legitimate to reach out to the host web, or even other site collections. 

In the forum post, the original poster, mentions a scenario where multiple apps might communicate with the same list. If the list is going to be leveraged by multiple apps, the list should probably live in the host web. 

Here is an example:

I might create an app that hooks up a remote event receiver so I know when an item in the list has been updated.  My app could then read the list and pull back an address.  It could then get the longitude and latitude for the address and write it back to the list.

Your app might be running in an azure worker role and check every 30 minutes to see if there are any potential spelling mistakes contained in the list and if so update a column to flag it for review.  This would happen without a user at the keyboard.

Let's say your spell checking app only notifies the user who added the item and a developer for the company who owns the farm/tenant needs to also notify the site owner in case the person who updated the item never fixes their mistake.  So they write an internal app that checks the list’s column named "SpellingMistakeFound" that this developer knows is used by the spell checking app as the column that gets updated.  The internal app could extend the functionality with a notification system that lets the site owner notify additional people when the app finds a list item with this flag set to yes.

Rickee (from the forum thread) is right about not reinventing the wheel.  There is already a custom web part to show the list on the SharePoint site.  If the data is going to live in the host web, then just use the out of the box web part.  If the out of the box web part doesn't provide what you need you can extend it using Client-Side Rendering (CSR).

A video demonstrating Client-Side Rendering of a list in SharePoint 2013

The SharePoint Product Group did an amazing job with the new app model.  However, we now have the opposite problem in 2013 that we have in 2010.  In 2010, it is often difficult to make the functionality work within the tight constraints of a sandboxed solution.  In 2013, we have so many options that it's often difficult to figure out the best option to go with.

There is so much flexibility in fact, that you are not limited to only a SharePoint hosted vs. Cloud hosted app.  You could have a hybrid app.  Your app could have some assets in the app web, and some in the cloud.  But that's not all.  Want to throw in a native Windows Phone app that is actually just an extension of your SharePoint app?  Done.  Android and IPhone native apps?  Done.  Surface? Kindle Fire?  Yup.  Can it make a web service call?  If the answer is yes, it can be an app.

The possibilities are almost endless.