Monday, September 22, 2014

Making a REST call to the Files API

In this post, I'll show how to make a REST call to the Files API.

Note: There is a good article written by Matthias Leibmann, Program Manager in the Exchange team, on using OAuth to access Calendar, Contact and Mail API in Office 365.

It's not as easy as doing a "GET" request to a single endpoint. You first have to go through the Oauth flow, of course, because you want to get meaningful user data.

I'm using Advanced REST client, an app for Chrome that you can obtain in the Chrome Web Store.

It seems that lots of folks use Fiddler, but I find it overly complicated and too heavy for this purpose. Advanced REST client is really lightweight and focuses on making REST requests and seeing responses. If you want more, check out Fiddler.

1. Assuming you have already registered your application with Azure (a post on how to do this will be coming up soon), you can use Advanced REST Client to make a GET authorization request:



Resource looks like "", client id looks like "08632ea7-3847-48b8-b43a-b99568e3a2c4", state is some unique string used to prevent CSRF (you can put something like "12345" for demo purposes), redirect URI is the URL that you registered in AAD for where your users will be sent after authorization. Note that for the purposes of this demo, you don't actually have to point to something valid that is own your domain. You can just put "", as long as it matches with what you registered in Azure AD.

Press Send and you get a response that looks like this:

See that ?code= query parameter after That contains the authorization code. Copy that.

2. Make another request to obtain an access token so you can actually make calls to the resource. The POST request looks like this:


In the body of the request, 


Client ID is from Azure AD, Client Secret is the same as "Key" and is also from Azure AD. Code is the authorization code you obtained in Step 1. Grant type is authorization code because that is the information you are sending over. Redirect URI is what you registered on Azure AD.

The screenshot above shows what you should send and what you'd receive. Notice you get an access token. Copy that.

3. Make a request to get files from the user's OneDrive for Business. The GET request looks like this:


In the header of the request, put:

Authorization: Bearer {YOUR_ACCESS_TOKEN_FROM_STEP_2_HERE}

You'll be able to figure out what to put before /_api/files from the discovery service. A blog post on that will come soon. You'll get what looks like this:

Voila! The response contains your files!

As promised, posts on Azure AD app registration and Discovery Service will come soon. Check this blog regularly for updates!

Friday, September 5, 2014

Running the Mail Sample Project for Office 365 Android SDK

My previous post covered setting up the Office 365 Android SDK and configuring it within Eclipse/ADT. I also wrote about the import errors that you may see, and how to fix those. 

Now let's actually run the sample projects to see what the new Office 365 APIs can do!

Note: As of writing, the APIs are still in Preview. They shouldn't be used in production as we may make breaking changes before they are released. Expect irregularities, and teething problems as we work hard to make them ready for use in your production code. Send feedback to the team through our page on UserVoice.

Which sample do you run? Well, the Office 365 Android SDK Github repository contains 7 Android projects (excluding the Tests, which shouldn't matter to you much):
  • office365-base-sdk
  • office365-files-sdk
  • office365-lists-sdk
  • discovery-files-sample
  • exchange-sample
  • read-sp-list-sample
  • read-write-sp-list-sample
The intention of having 3 different SDK projects is so that you don't have to pick between all, or nothing. You can just bundle whichever is appropriate for your project, and cut out the other functionality you won't be using, thus keeping your app as lightweight as possible.

The intention of having 4 samples is that each one focuses on a different end-to-end scenario which might be useful to you. If you're writing a mail app, for example, you probably wouldn't want to worry too much about OneDrive for Business files.

Let's just scope our attention to the Mail sample project (i.e. exchange-sample) for this blog post.

All the import errors should have been solved if you've followed my previous post.

1. Register the app in Azure.

2. Go to the Constants class. Change the value of the CLIENT_ID string to your app's client ID in Azure. (Coming soon: A post on how to register your app on Azure). It should look something like this:

3. Run it on either the emulator or your device.


If so, it's because the SDK hasn't been updated yet to reflect the new naming structure of the updated Azure Active Directory Library for Android. Remember how we added .aad in the import statements for all the classes that use the ADAL? We also need to update AndroidManifest.xml. Make sure the reference to the AuthenticationActivity in adal looks like this:

4. Try running it again. The app should launch, and you'll see this:

Sign in with your organization ID, e.g., or You cannot sign in with a Microsoft Account (MSA). An MSA would look something like or

After signing in, you'll see a view asking you to approve granting certain permissions to the app:

Note: Don't be unduly worried by the long list of permissions you see above. That's because in my Azure Active Directory, I registered the app and gave it all the available permissions in the drop-down. You don't have to do that; you can probably get away with just giving the app a limited subset of permissions.

After you approve those permissions, you'll see your inbox:

Ta-da! The app pulls in email from the Exchange server and displays them to you. You can click on each email to see the entirety of the message.

Wednesday, September 3, 2014

Setting up the Office 365 SDK for Eclipse/ADT

Office 365 APIs is a set of APIs that allow you to consume and interact with Office 365 services like SharePoint, OneDrive for Business, and Exchange. As of September 2014, the APIs are currently in Preview. While it's not encouraged that you use the APIs in production because changes that break your code may be pushed anytime as the APIs get fully fleshed out and kinks get ironed out, it makes sense to start building applications that integrate these APIs so that you can hit the ground running once they are released.

Besides the .NET SDK for developers used to the Microsoft stack, the team has also released an Android SDK. Like the REST APIs it is based on, the Android SDK is also in preview.

Let's look at how to set up the Office 365 SDK for Android development. I'm going to assume you're using Eclipse ADT.

1. Head over to the GitHub repository and download the SDK. You can either Download ZIP or Clone in Desktop.

2. In Eclipse, go to File > Import > Existing Android Code into Workspace. Browse to the location where you cloned the SDK, or where you unzipped the files that you downloaded. Select all the Android projects except the Test projects.

3. You'll see a bunch of scary-looking exclamation marks and import errors after you've imported the Office 365 SDK android projects. Let's find out what's causing these import errors and try to solve them one-by-one.

Nothing scares me more than 589 errors... but I'll show you that these are actually relatively easy to fix and will disappear in no time at all!

4. The reference to the Azure Active Directory Library is broken. The Office 365 Android SDK requires this library for authentication using Active Directory. This allows users whose organizations subscribe to Office 365 to sign in with their organizational accounts (e.g. "").

Let's fix it by selecting the ADAL library project in our current workspace. If you haven't yet configured and imported the ADAL, I've written a step-by-step guide on how to do that here.

Do this for all the projects, since all of them have references to ADAL.

Tip: When you're trying to fix errors that come with importing a new project into Eclipse, I'd highly recommend that you regularly clean the project you are trying to import. Many times I thought I'd already fixed something but the warning message still shows, and I realized it's because I forgot to clean and recompile the project. Clean the project by going to Project > Clean in the menu bar in Eclipse.

5. If you go to the office365-base-sdk project, and you select libs >, you'll see the script for what appears to be a call to get the Google Guava library.

Let's just grab it off the Guava library page.

Download the jar file and simply paste it into the libs folder of office365-base-sdk.

6. This pretty much fixes the errors in office365-base-sdk, office365-files-sdk and office365-lists-sdk. Now let's see what's ailing the sample projects discover-Onedrive-files-sample, exchange-sample, read-sp-list-sample and read-write-sp-list-sample.

It seems that some of them have incorrect references to the Office 365 base/files/lists SDK. Fix them by removing the references to the libraries, and adding them in again (this error occurred because the path is no longer the same after you import the SDKs into Eclipse).

7. If you still get errors, especially in the import statements, add in "aad" before ".adal" as shown below. This is because the path you import from must correspond to the name of the package in Eclipse (you can open the package of the Azure AD library to see its name and make sure it corresponds)

That's it - you should be good to go! In a future post I will aim to cover how to run the samples and what they do.