The new app model for Office 2013 works in a similar manner as the new app model for SharePoint 2013 to mitigate many of the challenges developers have faced in the past. The result has become a better platform for developers to include a broader set of technologies in their solutions while not having the risk of impacting the core runtime environments of SharePoint and the Office clients. In Chapter 2, “Overview of the SharePoint 2013 App Model,” you learned how the new app model for SharePoint 2013 helps to improve some problem areas that SharePoint 2010 had around full-trust deployments that could impact server and end-user performance if code misbehaved. It also allows developers to move beyond the restrictions imposed by sandboxed solutions. In the same way, the new app model for Office 2013 addresses a number of challenges developers and IT have faced historically in Office with add-in installations, but it also is forward-looking in its adoption of web-based standards such as HTML5, CSS, JavaScript, and so on, which can now better facilitate web developers in surfacing valued cloud-based assets inside of Office.
The new app model for Office can be considered an evolutionary and logical step in the programmability/extensibility model for the Office clients. As the desktop, laptop, and other device form factors have evolved, so have the underlying hardware architectures. For instance, Office now runs on Windows RT which utilizes the ARM architecture that thin, lightweight tablet and PC devices are built on. However, the ARM architecture does not support the traditional extensibility models for Office: VBA and VSTO. Therefore, solutions that developers have built using VBA and VSTO are lost to users of these devices. The new app model for Office is the extensibility model that bridges this hardware/software divide. It now brings a new class of developer solutions to both the platforms that Office traditionally ran on as well as ARM devices and even the services layer to include the Office Web Apps where a version of Excel, Word, PowerPoint and Outlook run in the browser.
The new app model addresses a few other typical challenges for the developer and for IT. Take VBA solutions and VSTO add-ins for example: these are written to provide powerful business solutions, and VBA and VSTO developers write code specific to each Office client. The deep object model is not the same for Word as for Excel or PowerPoint, so a developer codes and maintains a different solution for each client. Additionally, with the advent of the Office Web Apps available in SharePoint 2010, the VBA code and COM-based add-ins became incompatible with the Web server environment. Essentially, a VBA solution or add-in developed for the rich client had no future with respect to being deployed to run within the Office server-side services on SharePoint.
Identifying the add-ins installed throughout the enterprise has been a challenge for IT, but due to the add-ins’ tight coupling with the Office client, a need exists to fully test add-ins with each new version release of Office. Historically, these challenges have made rolling out a new version of Office across the enterprise difficult.
The new app model for Office nicely mitigates the challenges for both the developer and IT. For the developer, the object model and unified JSOM for Office is consistent across the clients. The intent is that with the unified JSOM, the app can run across the desktop applications that support Apps for Office without any changes — something that could not be done with VSTO add-ins. Also, because the app is essentially running in a browser inside Office, the added benefit is that the app can run equally well in the Office Web App under SharePoint. Although all the Office Web Apps don’t yet have this functionality in the Office 2013 release, this is the direction for the new app model. Therefore a developer’s solution written with the new app model is intended to run anywhere the Office client runs as well as in the server environment where the Office Web Apps run. The solution will not need to be altered to run in any of the locations. It’s just going to take some time to attain parity across all the platforms.
IT benefits from the new application model because by its nature, there is no footprint on the Office client itself: Apps for Office do not require an install. IT chooses how Apps for Office are made available within the enterprise, providing central management and governance. As apps are made available in the enterprise, users can discover and access them from within the Office client. The client understands how to instantiate an app for Office, monitor the app’s behavior, and provide telemetry information to IT for reporting and decision making. For more information on telemetry, monitoring, and reporting of Apps for Office, please see the recommended reading list at the end of this chapter.
Now that you have access to all these benefits that the new Office app model brings forth, it is worth taking a look at how simple it is to build your first app for Office. The following activity walks you through this process.
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta charset="UTF-8" /> <meta http-equiv="X-UA-Compatible" content="IE=9"/> <link rel="stylesheet" type="text/css" href="Program.css" /> </head> <body> <p>My First app for Office!</p> </body> </html>
body { position:relative; } li :hover { text-decoration: underline; cursor:pointer; } h1,h3,h4,p,a,li { font-family: "Segoe UI Light","Segoe UI",Tahoma,sans-serif; text-decoration-color:#4ec724; }
<?xml version="1.0" encoding="UTF-8"?> <OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="TaskPaneApp"> <Id>c6ec2456-9fca-4f27-85c3-4623b25ef0ae</Id> <Version>1.0</Version> <ProviderName>Microsoft</ProviderName> <DefaultLocale>en-US</DefaultLocale> <DisplayName DefaultValue="My First App" /> <Description DefaultValue="My first app for Office."/> <IconUrl DefaultValue="[YourDriveLetter]:FirstAppFirstApp.png" /> <Capabilities> <Capability Name="Workbook" /> <Capability Name="Document" /> </Capabilities> <DefaultSettings> <SourceLocation DefaultValue="[YourDriveLetter]:FirstAppFirstApp.html" /> </DefaultSettings> <Permissions>ReadWriteDocument</Permissions> </OfficeApp>
Because an app for Office is simply a web page being rendered inside of Office, you can build your web pages using any web technology that will render in Internet Explorer version 9.0 (or later) or an equivalent browser. Therefore, Apps for Office can use any features supported by HTML5 and JavaScript. What is not supported in the Office clients are ActiveX controls embedded in web pages. ActiveX controls are blocked from rendering in the Office clients for security purposes.
You’ll notice the manifest file is an extremely lightweight .xml file that serves to identify the app for Office to the host Office client applications. Although some of the XML elements in the manifest file are quite self-explanatory, there are a few worth highlighting:
Before the Office clients start “looking” for Apps for Office available to users within an organization on SharePoint, either on premises, in Office 365, or on a network fileshare, you must first set up the Trusted App Catalog location in at least one of the Office clients installed on the user’s machine. After you designate this location, all the other client applications that support Apps for Office will use this setting and render the appropriate selections for apps that target that specific Office client. In the preceding activity you set this location manually through the Trust Center; however, in an enterprise it can be pushed out via Active Directory Group Policy. In this way IT can maintain control and governance over the Apps for Office allowed within the enterprise and can completely turn off the ability for employees to browse the Office Store if that’s the restriction IT wants to enforce. After the Trusted App Catalog designation is set, the Office client applications are ready to render any Apps for Office that a user has available to select!
Now that you have the fundamental components identified for building an app for Office, check out the following introduction to the JavaScript object model and how Visual Studio helps enable developing integrated solutions using the new app model for Office.