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.

Comments

• Anonymous
  February 24, 2013
  Thanks Mike for nice example. We as a developers need to understand more about this powerful concept called Apps. As you mentioned the possibilities are almost endless.

• Anonymous
  February 28, 2013
  The comment has been removed

• Anonymous
  February 28, 2013
  Hi Abe, I have not seen anywhere in our documentation that says "that an app should not work with custom lists that it did not install itself".  I have been working with an ISV that does mapping software.  Could you imagine if we told them their app could only interact with data in the app web?  The user would only be able to generate maps based on data they had in the app.  Which upon install would be nothing.  Let's say this data is for the customer's retail locations.  Would we really expect the user to copy this retail store data into every app?  Of course not, having your app interact with data in the host web is perfectly fine.  However, it should do so responsibly and fail gracefully if a list gets deleted.  "The list this app was configured to operate against "Tasks" is no longer available, would you like to select a new list?" I disagree that a farm solution is the right way to go, and sandboxed solutions have been deprecated in favor of the new app model.  A farm solution would introduce stability and performance risks that don't exist in the app model.  They would also have unlimited permissions, and could do even more damage than a tightly scoped app.  One thing our documentation does say is that SharePoint farm solutions should only be used for administrative applications.   This is from our documentation on choosing the right API. msdn.microsoft.com/.../jj164060.aspx ** If the functionality you want to offer customers is not oriented to SharePoint administration at a scope broader than site collection, we recommend that, instead of using the server object model, you create an app for SharePoint that includes a remote ASP.NET web application with custom Web Parts and user controls as needed.</I> ** Modifying a list would not fall within the recommended scope of a farm solution. The same documentation says:   ** Developing new sandboxed solutions against SharePoint 2013 is deprecated in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013. ** I think it's pretty clear that apps are the future, and in my experience so far, they offer way more power and flexibility than Sandboxed Solutions anyways.  As I  mentioned earlier, it would depend on the scenario, but accessing data in the host web is perfectly acceptable.  You just have to make sure it is the right approach for your app.  If your app doesn't need any data already existing in the site, than keep everything in the app web.  If your app does need data in the host web, by all means request permissions and do it.  If the user has to keep pulling documents out of the recycle bin because the app is deleting them, the reviews will reflect this and the app will quickly stop getting installed.

• Anonymous
  March 05, 2013
  The comment has been removed

• Anonymous
  March 05, 2013
  The comment has been removed

• Anonymous
  March 05, 2013
  Continued He should not try to mix these and create multiple apps that share custom lists on the host web. Let me throw 2 scenarios out there and what model I might recommend to my customer based on only the information below. I build 2 apps. Adventure Works Url Shrinker and  Adventure Works Url Validator. In this case I might have both apps add a custom action to the host web on the "item" content type so they get added to every list in the host web.  When they select an item and choose the url shrinker, I would scan every column against a regular expression to detect Urls.   Then ask them if they want me to update the Urls the app found with short urls.  I would also provide a function to reverse it.  In this case, the app has no data, it is just providing value add on data the user already has.  Perfectly valid.   Now 2 different apps. Contoso "Help Desk App" and Contoso "View My Open Help Desk Tickets App" In the main helpdesk app, all of the data the app will be interacting with is specific to the app.  Also, Contoso has tens of thousands of employees and I need something that scales beyond a SharePoint list.  Also I know ahead of time that future apps will need to integrate with this data.  I would choose SQL Azure, running MVC 4, ASP.NET 4.5 and both apps would talk to the same data source.  

• Anonymous
  March 06, 2013
  The comment has been removed