Corey Roth [MVP]

If you know me then you know I’ve been doing a lot of work with apps lately (SP2 – link, twitter).  I started developing primarily with an on-premises virtual machine running SharePoint 2013, but I have recently switched to using SharePoint Online (Office 365) more.

1. Free Office 365 Developer Site – The first benefit is that you can sign up for a free Office 365 Developer Site.  This is a great way to get your feet wet with SharePoint 2013 without having to worry about installation and configuration.  You can create a developer site collection and publish your apps here and get started very quickly.  Especially if you use the “Napa” Office 365 Development Tools.
2. Less setup – setting up SharePoint 2013 has a fair amount of complexity, but nothing that most of you can’t handle.  However, setting up apps is even harder as you have to set up a wildcard DNS entry to do it correctly.  Office 365 takes care of all of this for you.  Your subdomains are automatically provisioned for your apps, all you have to do is publish and you’re good to go.  If you plan on using provider hosted or auto-hosted apps, SharePoint Online is easier as well.
3. You don’t have to set up Workflow – Setting up workflow is hard.  I messed it up on my last attempt on my SharePoint 2013 virtual machine and I haven’t bothered to go back and fix it.  When I needed to build an app that used workflow, I started publishing to SharePoint Online.  It just works here and you don’t have to worry about installing Workflow manager and all of the related items.
4. Seller Dashboard team tests here – I discovered this when one of my apps was failed a while back and the issue only occurred on my SharePoint Online tenant.  The nice thing about apps is that once everything is configured they work in both on-premises and in the cloud (depending on the type of course).
5. You don’t need SharePoint 2013 installed – You can develop SharePoint apps without having SharePoint 2013 installed.  This means you can do the development directly from your host OS. 
6. Test Licensing App – If you are doing license validation (and you should), the Test Licensing App helps you test this much easier.  It allows you to generate a test license for free, paid, and trial apps.  I believe this app is self-hosted (or maybe auto-hosted) which means it is much easier to get running with SharePoint Online.  When you do install it, be sure and wait several minutes before trying it because it takes some time before it will work.  If you don’t use this app, you have to create XML files to represent the test license and install them with PowerShell.
7. Testing with latency – some of your users are likely to use SharePoint Online.  When running in the cloud, things have more latency than on-premises as you know.  As a result, some JavaScript that you write may perform greatly on-premises but not so well in the cloud.  This is a great way to test for this and see if you need to make any adjustments or add caching.

I have also found that publishing to SharePoint Online really doesn’t seem to take any more time that it does locally (most of the time).  The biggest drawback here is that you can’t debug workflows.  That may be a deal breaker at some point, but hasn’t been a problem for me yet.  You can debug your JavaScript using Visual Studio just fine though.

Follow me on twitter: @coreyroth.

Let’s face it.  In SharePoint 2010, creating ribbon custom actions was not a very pleasant experience.  You had to know the inner workings of the XML and the black-magic behind selecting the right Id in the CommandUIDefinition.  We had community tools like CKSDEV to help though.  Now, I am happy to see that a new Ribbon Custom Action SharePoint Project Item slipped into Preview 2 of the Office Developer Tools.  This new SPI provides a nice wizard interface to guide you through the process of creating an action.  Let’s take a look at it.

First, you’ll need to create a new SharePoint App project.  The downside of the tool is that it is only available for SharePoint apps.  It’s not in regular SharePoint 2013 projects.  In my example today, I am going to attach a custom action to a list item to take the user back to the default.aspx application page.  Of course, you can use traditional techniques as before to add JavaScript, pass parameters, and whatever else you need to do.  I just want to show you what the wizard looks like today.

In the Add New Item menu, you’ll see the new wizard here.  Choose Ribbon Custom Action and give it a name.

Note, that there is also a new Menu Item Custom Action template as well.  When you click Add, you will be taken to the next step in the Wizard.  Here you first need to choose whether you will apply this to the Host Web or the App Web.  Remember that the App Web that has all of the pieces of your app and the Host Web is the site that hosts an instance of your app.  One way you might use this new feature is that a user clicks on an item in the host web, uses the ribbon action and gets redirected to your app.

You have the ability to bind the custom action to a list template or a list instance.  If Host Web is selected, selecting List Instance will provide you with a list of all instance on the particular host web that your app is currently configured to publish to.  Otherwise, if you choose List Template, it will provide you a list of common templates.  I don’t think the Wizard will let you pick a custom template, so you would probably have to edit the XML manually when you are done.

In my case, I have chosen App Web and then a specific List Instance.  It knows to look through the List Instances you have in your project and put them in the list.

When you continue to the next step, it will allow you to specify the location of the ribbon, the text to display, and what page the user should be redirected to when clicking the link.  You can select any existing ASP.NET page in the project for the action to navigate to.  If you want to execute JavaScript instead, you would need to edit the XML once you complete the wizard.

It provides you with a list of locations that the control can be located at:

When you are finished, Visual Studio generates the XML that you need.  You can make edits as necessary.  However, at this point there is no going back to the Wizard and making changes.  If you want the Wizard again, you’ll have to delete the item and recreate it.

At this point we can run the project and go to the list that we set the action on.  Selecting the list item, will expose the action in the ribbon.

Clicking on the Ribbon Action, I then get redirected to my app home page.

I’m pretty excited about this feature since I have always struggled with creating custom actions.  I think this will make it much easier to create actions now.  This is important because this is one of the key ways to link between the host web and the app web.  Unfortunately, this action is only present in Apps, but you could always cut and paste it into another project.  You could also likely take the code it generates and use it in your SharePoint 2010 projects as well.

If you’ve followed me post, you have a good start on working with Client Web Parts with the new SharePoint 2013 app model.  In an app part, everything you do is inside an IFRAME.  You need to remember this whenever you create links inside your App Part.  This provides a small level of complexity but it’s not that bad when you think about it.  Let’s start by taking a look at what it will take to link to the default page of the app.  Typically this page is called default.aspx and is hosted at a URL like the one below.

http://app-4715ba34d5bfe2.apptest.local/sites/developer/HelloWorldApp/Pages/Default.aspx

Effectively this url, has a prefix (app), an Id, a subdomain hosting the apps, the current site I am running it on (developer site), followed by the app name and finally the Pages folder (which matches the name I have in Visual Studio).  The .aspx page hosting your Client Web Part also typically sits in this folder as well.  In my case it’s called HelloWorldClientWebPart.aspx.  That means, if I want to create a link in my Client Web part to the app’s default page, I should be able to do so with a relative link like this:

This will get me to the page, but unfortunately here is the result:

The link works but that page is designed to run in the full browser so it doesn’t have the AllowFraming tag.  Fixing this is simple though.  Just add target=”_top” to have the link navigate the parent frame instead of the IFRAME.  The link now looks like this:

Now the link will work. 

Another common scenario you might run into is linking to a related list.  In this case, I have a list called TestList with a relative URL of Lists/TestList.  We can get to this, but we need to use a relative path and go up one folder first since the page executes out of the Pages library.  Here is what that link would look like.

Lastly, there may be a time when you want to retrieve the URL to the app web from the client web part.  You can do this with some CSOM.  Start by getting a reference to the app web.

You then need to load the context for the web object and then execute a query. 

On the success method, you can read the URL.  I then get a reference to the link on the page I want to update and assign the href attribute.

This gives you some options for working with links.  It’s not entirely complicated, but I thought it was worth a quick write-up.