Sharepoint 2013 : Developing Integrated Apps for Office and Sharepoint Solutions - The New App Model for Office

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.

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.

TRY IT OUT: Building Your First App for Office (FirstApp.zip)

Imagine extending Office by merely composing and using standard web technologies with no programming environment except a text editor! This exercise shows the simplicity of the new Office app model where an app can be broken down into a simple equation: Office = 1 manifest file + 1 HTML page + 1 Office client. To create one just follow these steps:

1. Create a new folder on your local disk and name it AppManifests.

2. Right-click on the folder and select Share with ⇒ Specific people. Type Everyone in the text box, click the Add button, and then click Share.

3. Create another new folder on your local disk and name it FirstApp.

4. Create the following markup document in your text editor, and save the document as FirstApp.html in the FirstApp folder:

<!DOCTYPE html>
<html >
    <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>

5. Create the following CSS document in your text editor, and save the CSS document in the same folder where you saved the previous HTML document, as Program.css:

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;
}

6. Using Microsoft Paint or any application that can create a .PNG file, create a 32×32 pixel image, and save the file in the same folder where you saved the previous CSS document, as FirstApp.png.

7. Enter the following XML in your text editor to create a manifest document, and save this file in the AppManifests folder with the name FirstApp.xml: be sure to replace [YourDriveLetter] in the following XML with the actual letter of your local drive where you saved the FirstApp folder.

<?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]:\FirstApp\FirstApp.png" />
  <Capabilities>
    <Capability Name="Workbook" />
    <Capability Name="Document" />
  </Capabilities>
  <DefaultSettings>
    <SourceLocation DefaultValue="[YourDriveLetter]:\FirstApp\FirstApp.html" />
  </DefaultSettings>
  <Permissions>ReadWriteDocument</Permissions>
</OfficeApp>

Now that you have the files created for your first app for Office, you need to wire up the Office client so it knows where to look for app manifests.

To set the Trusted Catalog Location, follow these steps in either Word or Excel:

8. From the File menu, select Options ⇒ Trust Center.

9. On the Trust Center page, click the Trust Center Settings button.

10. In Trust Center, click Trusted App Catalogs and in the Catalog URL type:\\[YourMachineName]\AppManifests\ and click the Add Catalog button. Click the check box beside the newly added item so it will show up in the menu, and then click OK on the screen, again when prompted, and a third time on the Options dialog. Then close Word or Excel.

Now you can use your first app for Office by following these steps:

11. Open Word or Excel. From the Insert menu, select Apps for Office ⇒ See All.

12. Click Shared Folder and then click Refresh.

13. Click My First App and then click the Insert button.

Your first app for Office should resemble Figure 1 in Word 2013.

FIGURE 1

How It Works

In this exercise you first created a network share as a trusted catalog location for storing Apps for Office manifest files. This is essentially an easy way for an enterprise to make Apps for Office available to employees, although it is not the only way. Alternatively, if an organization has a SharePoint 2013 site or Office 365 SharePoint Online site, it can make Apps for Office available by setting up SharePoint to be the trusted catalog location for manifest files. For apps purchased directly from the Office Store by individuals, Office.com serves as the trusted catalog location for these manifests. Also, because the apps are purchased using a Microsoft LiveID, they roam with the user. If users log in to Office with that same LiveID on any machine, all their Apps for Office will be available to them!

Following the creation of the network share, you created four very simple files. For an app for Office, only three of them are actually required: the manifest .xml, .icon, and .html file. The .css file is optional. In this Try It Out you simply used a text editor so you could see the core components without having any tooling overhead. But as you will see, using a tool like Visual Studio helps make this much easier and provides structure and validation while building you Apps for Office.

---

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:

• The element OfficeApp has an attribute xsi:type set to TaskPaneApp. The xsi:type is used to identify how the app for Office is to render within the Office client. In the preceding activity you chose the TaskPaneApp. Other valid types are ContentApp and MailApp. A task pane app renders in the Office clients in the same way that you traditionally see with various add-ins. Task pane apps are docked by default on the right-hand side of the client, but can be undocked so they float, too. Alternatively, content apps are inserted onto the document itself. Essentially, think of these like you would a chart or picture that the user has complete control over. Content apps for Office are printed and saved with the document just like any other inline object associated with a document. MailApp renders in the Office mail clients only when specific patterns for app activation are met within the mail item. You will see how this works in the mailbox app example later.
• The id element must contain a globally unique value. In the preceding example you simply used a GUID provided and this sufficed for an example on your local machine. However, for your real-world app for Office, you use a tool to generate a GUID. This unique id value identifies your app for Office in the Office Store or in your corporation trusted catalog location.
• Each xsi:type called out earlier has a specific set of Capabilities that designate the contexts within which it can be rendered. The Capabilities element is the location where you identify Capability elements. For instance, the TaskPaneApp has the capability to only render in a client that supports a workbook, document, or project. Here in the manifest you designate these. Sometimes your app for Office might only target a workbook whereas other times your app can be used in one or more of the other options. By listing each Capability here, when a user clicks the Insert ⇒ Apps for Office button on the ribbon in a client, if that Office client supports the xsi:type/Capability combination, then your app for Office will show as one of the available apps for that client. Table 1 shows the mapping between xsi:type and Capabilities. You can anticipate these to broaden and deepen over time across more Office clients.

  TABLE 1: XSI:TYPE to Capability Mapping

  

• As mentioned previously, the beauty of Apps for Office is that there is no install on the Office client. Also, the SourceLocation element is where the magic of your app for Office meets with the power of the new Office clients. You simply designate the URL or location where you want Office to retrieve your web application, and the user can then begin to interact with Office and your productivity solution.
• Lastly, security and protection for the user is of utmost importance. The manifest file is where the Permissions element defines what type of permissions your app for Office will need to interact with the Office client. You’ll see these permissions described in detail later, but knowing that the manifest file is where you’ll identify the permissions for your app for Office is important.

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.