Building list view SharePoint hosted app part

Building a SharePoint hosted app is a simple thing, thanks to Napa.

The whole thing can take less than a day (if you know you client side API) even, but filling those gaps that Napa does not cover can be a bit tricky, and remember: once you go visual studio, I can never go back!

So, I thought I would write about a few things I found Napa was missing and I had to spend some time trying to figure out how to make them work:

1. Set the app part gallery icon:

As much as I tried and wanted, it turns out changing the app part icon is not currently supported! Only Microsoft built-in app parts can have different icons for now. This comes directly from Microsoft, so I stopped researching this issue and gave up…

2. Custom web part properties:

A vary basic need in deed, adding customizable parameters to app parts so that the user can configure it further. Apparently this was not supported in Napa, so I had to take my app to visual studio to add them.

Adding parameters is not very difficult, and since you app part is running in an iframe, all parameters will eventually be sent to your app part as query string parameters.

In order to add the parameters to the tool part, all you have to do is add them to the ClientWebPart elements file, like so:

<Elements>
    <ClientWebPart ….>
        <Content … />
        <Properties>
            <Property Name=”PropName” Type=”string” WebBrowsable=”true” WebDisplayName=”Prop Name” WebDescription=”Property description (tooltip)” WebCategory="Prop Category" DefaultValue="" RequiresDesignerPermission="true" />
       <Properties>
    </ClientWebPart>
</Elements>

Property “Type” can be string, enum, int or boolean.
For enum types a dropdown will be rendered. You can add the available options inline in the XML like so:

…
<Property …>
    <EnumItems>
        <EnumItem Value=”Val1” WebDisplayName=”Value 1” />
        <EnumItem Value=”Val2” WebDisplayName=”Value 2” />
        <EnumItem Value=”Val3” WebDisplayName=”Value 3” />
    </EnumItems>
</Property>
…

3. Accessing information from the current site, and not from the app sub site

You may know this already, but apps are deployed to their own sub site, that runs off a different web application than the site the app was deployed to.

Well, I wanted to display information from the user’s site, not from the app site. Which means I had to get the parent web in client object model to work on. not too difficult, but here is the code examples just for quick reference (if you have a better way of doing it – leave a comment I’d love to hear!):

First run this code:
this.context = new SP.ClientContext.get_current();
this.webInfo = this.context.get_web().get_parentWeb();//return SP.WebInformation not SP.Web
this.context.load(this.webInfo);
this.context.executeQueryAsync …

On load success, run this code:
this.web = this.context.get_site().openWebById(this.webInfo.get_id());
this.lists = this.web.get_lists();
…

then you can start using this.web to get the parent web and get information from it’s lists.

4. Auto-complete for SharePoint objects stops working for members

One last annoying thing I learned: although in most cases visual studio can auto-complete members and functions for javascript types, when I set the object to a member in javascript (this.web = xxx) and try to use it later in a different function it loses the auto-complete for this object.

This was rather simple to fix, when defining the member in my javascript class I had to add an attribute to it defining its expected type:

/// <field name="webInfo" type="SP.WebInformation">Parent web info hosting hte app</field>
webInfo: null,

This seemed to do the trick.

I’ll post back once I have more tips,

Shai.