Apps in Sharepoint 2013

CodeProject
Why Apps? What's wrong with Solutions?
The world is getting smaller day by day, thanks to technology. Big desktops became Bulky laptops. Bulky laptops became Notebooks. Notebooks became Ultra books. Now the trend is moving towards Tablets and Smart phones.
So does our applications. Web applications becoming Apps.
"Apps" is not just a marketing strategy to increase use of SharePoint in wider markets, but also a complete replacement of sandbox approach with many other Pros for both Development, Deployment and Usage.

Do you know that sandbox solutions are deprecated in 2013?
Sandbox Solutions are introduced in SP 2010 and now they are off, to encourage the usage of Apps. May be we should understand the seriousness of Microsoft towards "Apps" in future.
Of- course the conventional SP solution approach is still there.

SP 2103 Development Options:
1. Full-trust SharePoint Solutions (WSP)
2. Apps

Main reasons for "Apps" development:
1. Custom code will not be executed on server. So this can avoid, Application / Server outages.
2. Custom code will be executed in Client-Browser or may be in some other scope like IIS or Windows Azure, which is completely out of SharePoint scope.
3. Server Object Model (SOM) code is replaced by Client side object model (CSOM) / Rest Services using which Apps can communicate with Server. Authentication is done by OAuth.
4. Installing / Updating / Uninstalling of apps can be done without  affecting the SharePoint site.
5. Better usability in Tablets and Mobile devices.
6. Taking SharePoint to next level in terms of  Usability, Development, Deployment  and  Hosting(cloud).
7. Finally, everything in SharePoint 2013 is an App.

I know, the next question is
"Most of these reasons are just sounding like reasons for Sandbox Solutions?"
Well I have a question for you, how many times we have chosen sandbox solution for real-time implementation?

1. No full object model . . .
2. Understanding of Sandbox architecture
3. Not an easy task to create proxies for execution of full trust code.

What ever may be the reason, real-time applications are tough to develop using a Sandbox solution.
That is why "Apps" are introduced in SharePoint 2013 for ease of development and deployment.

Hosting Options in Apps:

1. Provider-hosted
2. Hosted in the cloud (Windows Azure autohosted)
3. Hosted in a SharePoint environment
4. Several combinations of these options.

 

How Apps for Sharepoint Work:

In above case, App1 is a Provider-hosted or a Cloud-Hosted(Auto-Hosted) app and App2 is a SharePoint Hosted App. So anything related to App1 will be created/Maintained in respective locations, either on Provider or Azure servers. This makes App1 safe and secure in execution perspective.

Now we need to look at App2.
When you create/Imported/Added a SharePoint-Hosted App, it will create a separate sub-web under your SP Web application. This App will be executed in a separate App Domain different from Farm App Domain. So, as process runs under App Domains, any exceptions in Apps will not cause any Outage to SharePoint Farm.

We will see the creation of an SharePoint-Hosted App and issues involved in doing so, in our next post.