Why the SharePoint 2013 App Model is better than sliced bread

Why the SharePoint 2013 App Model is better than sliced bread

Rate This
  • Comments 7

+

>


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.

Leave a Comment
  • Please add 5 and 3 and type the answer here:
  • Post
  • 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.

  • "From a SharePoint app if you want to read to and write to a custom list that your app didn't create, you can."

    Maybe you "can" but you probably shouldn't. As a couple of posters on that thread pointed out, the MSDN docs for SP 2013 say that an app should not work with custom lists that it did not install itself. That goes double if the list is on the host web. In fact, it is not a good practice for an app to have a dependency on even a custom column on an in-the-box list on the host web, because end users can delete those columns.

    You might get away with multiple apps using the same custom list on a host web in an "in house" project where you can be reasonably certain that the lists will exist when your app is installed and reasonably certain that users won't mess with the lists, but that kind of "in house" situation is precisely the kind of situation where a SharePoint farm solution or sandboxed solution is probably better than an app.

  • 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.

  • @Mike

    Thanks for the thoughtful response, but I did not say that multiple apps cannot use the same *data*!  That company can have a DB table with the retail locations and multiple apps can access that data. But that table doesn't have to be a SharePoint list. Also, I didn't say that multiple apps can't access data on the host web. Again, they can access in-the-box lists on the host web (preferably accessing only in-the-box columns). But those are not *custom* lists. Finally, I did not say that apps can't install custom lists. They can, but these should be on the *app web* which gets deleted when the app is deleted and are not accessed from any other app.

    Which gets me to what I actually did say: SP apps should not share a *custom* SharePoint list (*list*, not *data*) on the *host* web. The SharePoint product team has been making this point since at least the SharePoint developer kitchens (for SharePoint 2013) back in 2011. Here's an MSDN quotation that makes a similar point:

    "Apps for SharePoint are self-contained pieces of ... . An app has few or no dependencies on any other software on the device or platform where it is installed, other than what is built into the platform."

    That quote is from the MSDN topic "What’s new for developers in SharePoint 2013" at msdn.microsoft.com/.../jj163091.aspx

    Your suggestion of an error message saying "that list has been deleted" is contrary to the design philosophy of apps that the SP product team has been pushing since 2011. They emphasize that apps should not have dependencies that would require messages like that: *Data that is shared in any way outside the app should be remote or an in-the-box SharePoint list, not in a custom SP list.*

    I'll concede that I shouldn't have mentioned sandboxes solutions, since they are deprecated, but the scenario in the forum post -- custom lists being shared by multiple groups of people for multiple purposes on an "in house" SP farm -- is a classic SharePoint scenario. And IMHO, it should be implemented with a farm solution with custom lists and custom web parts holding the functionality. I don't think your other quotation contradicts what I'm saying. MS certainly wants to push the app model [and, not incidentally, MS's cloud data centers ;-) ], but apps do not work for every scenario. There is a MSDN topic specifically about apps vs. solutions (msdn.microsoft.com/.../jj163114.aspx), where they concede that "solutions are for admins" is not an absolute rule.

    The options for the person who started that forum thread are

    1. use a farm solution that installs custom lists and web parts

    2. use apps with shared data as remote DB tables  

    He should not try to mix these and create multiple apps that share custom lists on the host web. ("Remote" BTW doesn't have to mean in the cloud. It only means remote to the SP farm. It can be a SQL Server DB within the intranet. It can even be on the same SQL Server instance that's hosting the SP content database.)

  • So what about street addresses on custom lists?  The ISV tells their customer to pull all of the data out of SharePoint and put it in SQL so they can use maps on that data?  That’s not very user friendly.

    Why would the Product Group allow you to request permissions to write to lists in a host web, if they didn't intend for you to write to a list in the host web?  Better yet, when you request permissions to write to a list, why would we ask the person installing the app which list (including custom lists) in the host web they would like the app to have permissions to modify?

    Database vs. Custom List vs Out of the Box List doesn't matter.  If your app needs to write to the list, request permissions and write to the list.  

    *An app has few or no dependencies on any other software on the device or platform where it is installed, other than what is built into the platform.*

    This is poorly worded in my opinion.  I will try to contact the author.  Are they saying my app shouldn't pull movie data from Netflix or another remote service?  Then why do we provide sample code showing you how to pull data from a remote web service like Netflix?  Why did we demo it at SPC?

    Either way a custom list in the host web is not a dependency “on other software on the device or platform where it is installed”.

    *Data that is shared in any way outside the app should be remote or an in-the-box SharePoint list, not in a custom SP list.*

    Shared data is irrelevant.  5 different apps with 5 different custom actions can all run against the same list and that could be a perfectly valid scenario.

    *Your suggestion of an error message saying "that list has been deleted" is contrary to the design philosophy of apps that the SP product team has been pushing since 2011.*

    I have not seen any recommendations on how to handle app's error messages.  I would just use good design as you would for any app.  Telling the user that a list the user previously told your app to use is missing seems perfectly valid to me.

    *the scenario in the forum post -- custom lists being shared by multiple groups of people for multiple purposes on an "in house" SP farm -- is a classic SharePoint scenario.*

    Just because it's a classic scenario doesn't mean it requires a classic solution.  The app model is perfectly suited to handle this, and there is no reason to use a farm solution.  It's like using an axe when all you need is a steak knife.  They will both cut your food, but only one of them runs the risk of breaking the entire table that other people are currently using to eat.

  • **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.  

  • @Mike

    A couple of things you said make me think there *might* be more agreement between us than appears. You mentioned the URL validator apps that work on URLs in any list. And earlier you referred to an error message that prompts the use to choose another list. You are thinking of an app that can work with any kind of list. That isn't the kind of app that the product team has a problem with. The problem is with an app that depends on some particular custom host web list, with a particular custom content type (either explicitly defined or implied). If that list, or a column the app depends on, is deleted by an end user, then the app just breaks completely. It can't simply be  used on another list. No other list has the needed schema. It is this second kind of app that the forum question seems to be about.

    >There is no reason to use a farm solution. [axe and steak knife] both cut your food, but only one of them runs the risk of breaking the entire table ...

    Logic in a farm solution doesn't HAVE to use server-side code. You can use JavaScript for all your logic if bringing down the server is a concern. A farm solution CAN be an ax, but it can also be a steak knife or a butter knife, as needed.

    >So what about street addresses on custom lists?  The ISV tells their customer to pull all of the data out of SharePoint and put it in SQL so they can use maps on that data?  

    The ISV would only have to do this IF IT INSISTED ON CREATING AN APP. Adding functionality to an existing custom list is a good case where web parts are better than apps. The logic of the web parts can be in JavaScript.

    >Why would the Product Group allow you to request permissions to write to lists in a host web, if they didn't intend for you to write to a list in the host web?

    I didn't say apps shouldn't write to host web lists. I said they shouldn't have a dependency on a CUSTOM list on the host web.

    >... why would we ask ... which list (including custom lists) in the host web they would like the app to have permissions to modify?

    We don't! An app can't ask for permissions to a particular list. The closest it can come is to ask permissions for all lists having a specific base list type.

    >Are they saying my app shouldn't pull movie data from Netflix ... ?

    No. Remote APIs are platforms, not customizations of a platform. It's OK to have a dependency on them.

    >a custom list in the host web is not a dependency “on other software on the device or platform where it is installed”.

    Great minds can disagree, but I do agree with you that the statement I quoted from the SDK is too brief and imprecise.

    Also, about error messages: No one is objecting to having error messages in apps. The design philosophy of the product team is "don't have an app with a dependency (on a custom host web list) and an error message when the dependency is missing, instead design the app so that that dependency is not there to begin with."

Page 1 of 1 (7 items)