What is SharePoint APP?
We are all familiar with the App Model from Apple’s App Store and Google Play. Microsoft set out to create an extensibility point in SharePoint 2013 that would allow customers to build their own solutions for SharePoint without hurting the hosted model whenever a customer’s code was found to be ‘executionally challenged’. They came up with a model called a SharePoint App, which is simply a solution with no SharePoint server side code.
There is no server-side code that is executed by the SharePoint server. A SharePoint App is essentially a solution that can only include HTML, CSS, JavaScript, Silverlight XAP files, images, and any other static files. However, you can’t include an assembly with custom code because that would need to be executed on the server.
Developers will be able to publish their apps to a public marketplace for download & purchases. In addition organizations will be able to create a private corporate marketplace where the apps would be available to the organization.
Apps in SharePoint 2013 are simple web applications that are registered using app manifests for SharePoint. SharePoint apps bring a breadth of new features and usability to SharePoint 2013. The manifest is a simple XML file that declares properties of an app, and also includes, along with the basic properties, where the app will run and what the app has to do when it is started. App manifests are flexible and a lot can be done with them, such as using alternate authentication schemes (also known as app principals) declaring what permissions are required for the app to run, and other assorted tasks. There are certain strings in app manifests that are called “StandardTokens” which allow you to reference app and pass context. The “StandardTokens” are replaced at build/run time within the app as it runs.
Where does the App code run?
Besides what is listed above, the code for an APP can run in a few varied places, and that depends upon where you decide to host your apps. Apps can be hosted via SharePoint itself, on Provider-Hosted and auto-hosted apps on the cloud, or it can be a mix between SharePoint and Cloud-hosted. For SharePoint hosted apps, the code is simple JavaScript or HTML that is “hosted” by SharePoint itself. For auto-hosted apps, SharePoint will automatically deploy your app onto a Windows Azure or SQL Azure site, which runs on the cloud. If it’s provider-hosted, the app is run on dedicated servers or third-party hosted servers. The mixed component hosting runs all components hosted by SharePoint, and reaches out for components hosted on the cloud. This allows for flexibility in setup and ease of use.
How do APPS communicate with SharePoint?
SharePoint apps run on APIs that are used for integrating features into SharePoint. The APIs talk between the SharePoint servers and bring the features to you. SharePoint apps are capable of searching, adding posts, connecting with others, and much more. The potential for apps is nigh-limitless, and can even integrate with social networking. REST, JavaScript APIs and Managed APIs all integrate seamlessly with SharePoint. In order for the apps to run properly and call APIs to them, they simply need to be authenticated if you are not using HTML or JavaScript, and that requires client-side code or server-side code, only if the app is hosted on the cloud.
How are SharePoint Apps packaged?
SharePoint apps are distributed in “packages” which are hosted on servers. Depending upon where they are hosted, they can contain differing contents. For provider-hosted apps that either you or your IT department, it could include just the app manifest. For auto-hosted apps, the package may include other apps for deployment within the Windows Azure cloud. Apps hosted in SharePoint itself may contain components related to SharePoint as well as app manifests. The packages may also include additional components like apps for Office. If “Napa” Office 365 Development tools or Visual Studio 2012 are in use, you can build apps to directly deploy to them, allowing you to publish your app file with a .app file extension.
Following are the advantages of cloud -app model :
We are all familiar with the App Model from Apple’s App Store and Google Play. Microsoft set out to create an extensibility point in SharePoint 2013 that would allow customers to build their own solutions for SharePoint without hurting the hosted model whenever a customer’s code was found to be ‘executionally challenged’. They came up with a model called a SharePoint App, which is simply a solution with no SharePoint server side code.
There is no server-side code that is executed by the SharePoint server. A SharePoint App is essentially a solution that can only include HTML, CSS, JavaScript, Silverlight XAP files, images, and any other static files. However, you can’t include an assembly with custom code because that would need to be executed on the server.
Developers will be able to publish their apps to a public marketplace for download & purchases. In addition organizations will be able to create a private corporate marketplace where the apps would be available to the organization.
Apps in SharePoint 2013 are simple web applications that are registered using app manifests for SharePoint. SharePoint apps bring a breadth of new features and usability to SharePoint 2013. The manifest is a simple XML file that declares properties of an app, and also includes, along with the basic properties, where the app will run and what the app has to do when it is started. App manifests are flexible and a lot can be done with them, such as using alternate authentication schemes (also known as app principals) declaring what permissions are required for the app to run, and other assorted tasks. There are certain strings in app manifests that are called “StandardTokens” which allow you to reference app and pass context. The “StandardTokens” are replaced at build/run time within the app as it runs.
Where does the App code run?
Besides what is listed above, the code for an APP can run in a few varied places, and that depends upon where you decide to host your apps. Apps can be hosted via SharePoint itself, on Provider-Hosted and auto-hosted apps on the cloud, or it can be a mix between SharePoint and Cloud-hosted. For SharePoint hosted apps, the code is simple JavaScript or HTML that is “hosted” by SharePoint itself. For auto-hosted apps, SharePoint will automatically deploy your app onto a Windows Azure or SQL Azure site, which runs on the cloud. If it’s provider-hosted, the app is run on dedicated servers or third-party hosted servers. The mixed component hosting runs all components hosted by SharePoint, and reaches out for components hosted on the cloud. This allows for flexibility in setup and ease of use.
How do APPS communicate with SharePoint?
SharePoint apps run on APIs that are used for integrating features into SharePoint. The APIs talk between the SharePoint servers and bring the features to you. SharePoint apps are capable of searching, adding posts, connecting with others, and much more. The potential for apps is nigh-limitless, and can even integrate with social networking. REST, JavaScript APIs and Managed APIs all integrate seamlessly with SharePoint. In order for the apps to run properly and call APIs to them, they simply need to be authenticated if you are not using HTML or JavaScript, and that requires client-side code or server-side code, only if the app is hosted on the cloud.
How are SharePoint Apps packaged?
SharePoint apps are distributed in “packages” which are hosted on servers. Depending upon where they are hosted, they can contain differing contents. For provider-hosted apps that either you or your IT department, it could include just the app manifest. For auto-hosted apps, the package may include other apps for deployment within the Windows Azure cloud. Apps hosted in SharePoint itself may contain components related to SharePoint as well as app manifests. The packages may also include additional components like apps for Office. If “Napa” Office 365 Development tools or Visual Studio 2012 are in use, you can build apps to directly deploy to them, allowing you to publish your app file with a .app file extension.
Following are the advantages of cloud -app model :
1.) Stand-Alone Application : Apps for SharePoint are stand-alone applications that are easy to install, use, manage, upgrade and remove. Not only will cloud-based and hosted SharePoint 2013 environments take advantage of this, but so can on-premises ones.
Custom code will not be executed on server. So this can avoid, Application / Server outages.
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.
Server Object Model (SOM) code is replaced by Client side object model (CSOM) / Rest Services using which Apps can communicate with Server.
Installing / Updating / Uninstalling of apps can be done without affecting the SharePoint site.
2.) Uses Web Standards
The cloud app model supports modern web standards. HTML, Javascript, ASP.NET, C#, PHP and OAuth are some of the standards that are 100% supported with the new app model. The presentation, logic and data layers are now flexible enough to support many different skill sets. SharePoint developers are about to get a lot of competition.
3.) Isolated Apps
For those who are worried about security, the new app model uses isolation to separate the app from the main domain. Apps are literally deployed to their own web site in their own domain, which serves to further protect from unauthorized access of sensitive data. This helps drive adoption for on-premises environments looking to utilize the Public SharePoint Store. The key words in this point are to further protect from breaches, not fully prevent them from happening.
Authentication is done by OAuth.
4.) User-Friendly App Lifecycle
Just about everybody can relate to the ease-of-use of managing personal apps on a mobile device. If your organization utilizes the new app model, Public SharePoint Store or Internal App Catalog, you will be giving your users the ability to find, install, upgrade and even remove apps without ever calling someone from IT.
If you’re worried about this, IT still has control. You can choose to restrict access to the public SharePoint Store and create your own Internal App Catalog. Regardless of which you choose, the experience is the same. The user chooses which apps they want to install and work with, and they even have the choice of when to upgrade them when a developer makes a change.
Advantages of apps
- Various Hosted options.
- Multiple development platforms supported for creating apps
- Advantage is that the code is out of SharePoint
- SharePoint apps are capable enough to replace the most farm and sandbox solutions. Apps are mainly providing the more advantages for:
Users
Administrators
Third-party app Developers
Advantages to Users
- Users can easily add the new functionality to the SharePoint System
- More apps are available in the SharePoint App Store as compared with sandboxed solutions
- Upgrade supports are available to users
- Users can get the apps through the app catalog (within the organization) and App Store (outside organization).
- Apps provides the easiest installation to the users
- Users can also be reassured by the fact that all apps in the App Store have been approved by Microsoft to meet coding, interface and integrity standards
- The end-user process of installing is very simple
Advantages to Administrators
- Reduction of server outages and downtown
- Apps are executed outside the environment
- Apps are very less load and safer compared to the sandboxed solutions
- The single biggest advantage for administrators of SharePoint systems is control
- Admins can monitor apps
Advantages to Third parties
- The central store means a more effective use can be made of any marketing and advertising efforts
- The technical aspects of the app model also make life easier for many developers, allowing them to write apps in various languages
- Common web standards of HTML, JavaScript, CSS can be used to develop apps
- Visual Studio 2012 supports app project templates
- Microsoft also operates a revenue sharing model for the App Store
Disadvantages of apps
- The Apps infrastructure is very clunky and in some cases unrealistic to implement
- Apps are very primitive and rudimentary
- A corporate catalog is paid or needs to be purchased
- Apps will need to rely heavily on JavaScript and asynchronous REST API calls/client OM calls to interact with the associated SharePoint context
- The new App model brings many more cross-server communications with it. Will this impact the performance?
No comments:
Post a Comment